The IA of Things: Twenty Years Of Lessons Learned

James Leftwich, IDSA
Principal, Orbit Interaction
Palo Alto, California, USA
http://www.orbitnet.com
jleft(at)orbitnet(dot)com

Presented at
IA Summit 2005
Crossing Boundaries

March 3 - 7, 2005
Fairmont The Queen Elizabeth Hotel

Montréal, Québec, Canad
a

Abstract

It's the dawn of an age where interactive functionality and information is available and intertwined everywhere.  The past two decades have been a pre-dawn period where products, software, environments, functionality, and interaction with information have gradually converged.  What lessons have been learned within a single consulting design career during this period, pursuing from the beginning, convergence in these areas?

What are some examples of these design disciplines overlapping in past projects?  How do the constraints of limited physical affordances computing power, and small displays affect the user experience of devices, and what are some strategies for designing them to be more successful? How can a rewarding balance between efficiency, friendliness, flexibility, and inevitably expandability, be achieved when designing in these areas?  What design strategies can help devices, their software, information architectures, and network infrastructures leverage each other for greater rewards?

While by no means exhaustive, or inclusive of all the many projects I've encountered during my career, this presentation cuts across a representative sample of my design work.  I will use examples from a wide range of projects as a context in which to discuss issues related to the above questions, all of which are increasingly important in today's design challenges.  As a designer that has been among few working in the field of product and system user experience for this length of time, it is my goal to offer up some of the diverse ground I have covered and subsequent lessons this experience has taught me.

Earliest Exposures to User Experiences and Interaction Design

 

Interestingly enough I remember very well the first time I was aware of the User Interface and what I felt were clever and whimsical ways to communicate function.  It was the rabbit and turtle symbols near the throttle control of a farm tractor.  I grew up on a farm in west-central Missouri, in a small rural community where the highest technology was generally mechanical and agricultural in nature.  The rabbit symbol, used for fast, and the turtle symbol, used for slow, struck me as a youngster as very clever and communicative.  At the time I didn't fully grasp that such cognitive affordances were not simply graphically clever, but also cognitively simpler to grasp immediately and more broadly understandable across languages, and at least cultures where fast rabbits and slow turtles were common.

 

Iconic Alphabet - 1967

In 1967 I designed my first set of icons, each representing a letter of the alphabet.  I'm happy that I still have the drawing, and am somewhat impressed by the cleverness and simplicity of many of the symbols I drew.  This would be a harbinger of things to come.

During the 1960s I watched some television, but our set only brought in two or three channels on a good day, so many evenings consisted of sitting down with a volume from the Worldbook Encyclopedia and randomly perusing and reading.  This instilled both a love of informational surfing and a growing appreciation for the concise manner in which information was organized and presented, both textually and graphically.  The experience of growing up on a farm where it was necessary to use very different, yet integrated types of knowledge, skills, and thinking, laid an important foundation for my generalist career as a design consultant.  From early on I saw the integration of information, technology, and experience "wearing different hats" as crucial to long-term success.  Holistic or systems thinking didn't seem very unusual to me, having been born into a family that had been farming for many generations.  To the contrary, it was specialization that was a much more unfamiliar concept.

Throughout the 1960s I picked up various images and impressions of computers.  They were very mysterious, as I'd never had any opportunity to see one close up.  My notion of computers was a hazy mishmash of images from the media - giant mainframes with blinking lights and spinning tape reels in movies such as Desk Set, space-age computers in Batman's Batcave, and even the cartoon character, Mr. Peabody's Wayback Machine.  One common image that made an impression on me was the "readout."  Usually a tickertape that was issued from a computer with the answer to whatever problem had been posed to it.  I had no idea how a question was transformed into an answer inside a computer.

 

Lesson Learned:  Symbols have the power to communicate concepts

 

Homemade computer and interaction design drawings - 1971

In August 1971, just as I turned ten years old, I could wait no longer and decided that I would design and build my very own computer.  Though no photographs of the "working" cardboard prototype survive, I still have my initial drawings.  As my understanding about computers at the time wasn't about number-crunching, but about question asking and answer retrieval, I pursued a design that would accomplish that.  It's ironic how closely the drawings resemble the format of many of my later interaction documents, showing sequential operation, and tying together as many elements as I could to make the computer's operation simple for people to understand and use.

It was capable of answering six questions.  Each question was written on a "punchcard" (I didn't know what the punched holes were for, but I included them along with the written question).  Each punchcard was marked with a circle with a number inside it.  That was to symbolize one of the six corresponding round, numbered buttons on the front of the computer.  The card was deposited into an "Input Slot" at the top of the computer (whereupon it was unceremoniously dropped out the back.  Then the user punched the correct button, which was connected to a push-rod.  The push-rod pushed the answer slip out of a compartment inside the computer, whereupon it would fall out an "Output Slot" near the bottom of the computer's front.  Voila!  My computer!

I was actually very disappointed.  My computer wasn't magical.  It was fake!  I had to set it up first!

I had an uncle that was an electrical engineer, and who worked for the FAA in Oklahoma City working with communication electronics and doing radio frequency engineering for antennas.  He happened to visit shortly after I'd made my computer.  I told him that it wasn't a very good computer, because it had to be rigged to work.  He then told me that all computers have to be programmed, and began to explain how computers really worked.  I was fascinated.  This was one of the transformative experiences of my young life.

Another time he showed me how to enter a 49-line program into his Hewlett-Packard HP35 calculator in order to play an artillery game.  The game's goal was to zero in on a target, entering an angle for the artillery round to be fired, and getting back a positive or negative number indicating having either shot beyond or in front of the virtual target.  You had a limited number of times before you'd be hit yourself.  I was hooked!  I became a programmable calculator geek all through junior high and high school.

 

Lesson Learned:  Computers and Information Systems are not magic!

 

 

            My broad-based education as an designer and career goals upon graduation in 1983

 

All through high school, I had studied with the intention of becoming an engineer.  I loved lab work and word problems, especially drawing elaborate illustrations and diagrams to accompany my exercises.  But I loathed the monotony of abstract mathematics.  I studied until I grasped the underlying concepts, but being a visual thinker, I could only love mathematics and physics in their visual, preferably real life, forms.  After a year of college, I took a 180-degree turn and went into painting, art history, psychology, and economics, with a goal of becoming a fine artist.  While studying these domains I came upon a book on The Bauhaus, the famous German design school of the 1920s and early 1930s.  What impressed me most was the curriculum as printed in this book.  Mathematics, materials, typography, dance, fiber, and on and on.  Such a broad and diverse range of things, all important to pursuing highly-integrated and holistic design solutions.  This was what I was looking for - industrial design.

I discovered that the nearby Kansas City Art Institute had a very strong School of Design.  It had been chaired by the well-known designer and architect, Victor Papanek, who wrote the influential books, "Design For The Real World" and "How Things Don't Work."  He brought a real sense of critical thinking to design, prompting young designers to ask important questions, such as of for whom were they were designing, and what kind of value did designs and solutions bring to the larger world.

While at the Kansas City Art Institute I spent a great deal of time using and hacking around on the School of Design's Apple ][+, which sat in a small room near the professors' offices.  I managed to use the program Graforth to build simple 3D wireframes that I used to establish dimensional perspectives for product marker renderings.

I graduated in December 1983, and just one month later a product appeared that would bring all of my design ambitions and goals into a clear path that I've followed to the present - the Apple Macintosh.  For nearly a year I hung around the store that sold Apple computers.  I was getting freelance design here and there, but all I could think about was how empowered I would be with a Macintosh.

I managed to get a loan, using my car as collateral, and purchase a 128k Macintosh and an Imagewriter dot-matrix printer.  The Macintosh represented to me a most amazing combination of physical device design tightly integrated with an equally revolutionary onscreen user interface.  I was less interested in the software GUI by itself as I was the amazing power unleashed by the GUI with the mouse input device.  To me at the time it was clear that this was the domain that I wanted to pursue in design - the combination of physical, visual, and informational interaction.  Only trouble was, this was now early 1985 and I was a long way from anywhere where there was work doing user interfaces.

So again, I decided to design my own computer.  But this time it would become part of my portfolio as I sought out design work.

 

Lesson Learned:  Designing across boundaries requires a very broad education and benefits from generalist experience.

 

 

            Flat-panel Computer, physical interaction and software design - 1985

 

In early 1985 I began developing a concept for a computer with a positionable flat-panel display.  The design encompassed both the exploration of an alternative physical user interface, the form of the computer itself, and a software system designed to manage a smart office building.

After an exploration phase with numerous configuration sketches, the physical interface was essentially the functionality of the mouse divided into two devices, one for positioning, and one for action commands, which would be located on either side of the computer's  detached keyboard.  Both plugged into the keyboard and could be moved from side to side, depending on the user's dominant handedness.

The goal was to speed up the interaction.  In observing user playing video arcade games, I had become fascinated with the speed and efficiency of their physical interfaces.  I was trying to reproduce that intense, fast, and efficient physical interaction with this design configuration.

The software portion of the project was developed using MacPaint, with the screens iteratively developed and arranged into a sequential storyboarding of the interactional flow.  The software covered a range of features and activities pertinent to monitoring and managing the various infrastructural services of an office building, including electricity, lighting, plumbing, temperature, and elevators, as well as the building's telephone switchboard and directory.

In observing the receptionists of corporate office buildings, I thought that speed and efficiency could be increased by placing all of these functions in a centralized console-style arrangement.  Access and interaction would be minimized to short, direct navigation to a function and rapid sequential operation.  A hands-free headset would allow the user to use both hands, quickly shifting from monitoring, to managing, to providing telephone receptionist functions.

 

Lesson Learned:  The deepest, most impacting user experience design involves designing the physical controls, visual interface, and overall interactional architecture together, as a tightly integrated whole system

 

 

            Interaction Design and Information Architecture design consulting work from 1985 - 1989

 

Throughout the last half of the 1980s I lived in Dallas, Texas, and worked on a wide range of products and systems, large and small.  I often worked as a subcontracting co-consultant along with older and more experienced designers.  Not only did they help me gain experience across a wide range of devices and systems, but also taught me the skills of the consulting business.

I did quite a lot of prototyping, including electronics such as calculators, toys,  computer monitors and medical devices.  I also worked on some military projects through contracts with Texas Instruments, such as an early wearable GPS device for the Army and a cockpit control trainer for the Navy.  But I also worked with others to build even larger things, such as a full-scale trailer-mounted prototype of a Gulfstream G-IV business jet.  These experiences helped me develop a deeper understanding of hardware design and manufacturing.

For industrial design projects such as a Federal Reserve bill-sorting system, which I worked on for Recognition Equipment Incorporated, and an automated blood analyzer that I worked on for Abbott Laboratories, I conducted extensive design research. I studied the target users' goals and created full-scale foamcore mockups on which I did link-analysis and ergonomic studies to examine various configurations and their benefits.

 

Lesson Learned:  The best design education is hands-on experience in all the various aspects of development and working alongside older, more experienced and mentoring designers.

 

 

            Development of the Open Lookª GUI for Sun Microsystems - 1988 - 1989

 

In 1988 I teamed up with Norm Cox and Alan Mandler to develop Sun Microsystem's Open Lookª GUI.  Norm was a graphic designer, who had been the original icon designer for the Xerox Star computer, developed at PARC in the 1970s.  I'd been working with Tom Noonan, and industrial designer that had designed the mouse for that system.  I was getting to work with some of the pioneers of the field.

At the time it was a big decision to work on a project that was completely software, but I knew that opportunities to design anything as fundamental as an entire OS GUI just didn't come along very often.  It was an enormous learning experience.  My role was to take the basic components and interactions as Alan and Norm were developing, and refine and document them, developing all the layout and behavioral rules.

We were also working on IBM's OS/2 Presentation Manager GUI at this time, which allowed me to meet a number of interesting people also consulting on that project, such as Edward Tufte.  This was an era when several OS GUIs were being developed - the Next GUI, Hewlett-Packard's OSF Motif.

At the time I thought that these were all well and good, but they just weren't fundamentally breaking any new ground.  I still remembered the giant leap that the basic GUI user experience had been over the former command-line experience.  I wanted to know what lay beyond the current desktop experience.

 

Lesson Learned:  The disappointing fact that the majority of design is not in groundbreaking innovation, but in variations on something successful.

 

 

            InfoSpace, the whitepaper and information strategy - 1988 - 1993

 

Again I would develop my own concepts to explore a wide range of ideas I was having.  The result was the InfoSpace project, which I began in late 1988 and worked on through 1991.  I presented the paper and interface concepts in 1993 at 3CyberConf - The Third International Conference on Cyberspace - held at the University of Texas, Austin.

My experiences with Open Look and growing interest in what constitutes revolutionary innovation (i.e.: innovation that was capable of opening up entire new worlds where many types of embodiments could emerge) prompted me to explore several ideas and approaches in the InfoSpace model:

1) A network browser model.

2) Integration of the browser into the OS GUI itself

3) Expansion of the 2D desktop into a "space" which supported large amounts of interactively visualized data and elements.  The model described the use of metadata (what I termed "metainformation") of both objective (filesize, date of creation, owner, etc.) and subjective (3 out of 5 rating, categorical placement) that could be mapped to visual, spatial, and/or behavioral attributes within the visualization. In subsequent models I extended the metadata concept to blend both metadata that an informational object carried with itself, or which was produced by the object's creator(s) to the idea of metadata being able to be gathered from distributed third parties in a "secondary query" (e.g.: issue a primary query, which brings back a number of hits, then issue a secondary query, that brings back distributed metadata associated with the initially returned data objects, by specific object or associated classes).

One of the primary goals of the InfoSpace project was to explore and develop data retrieval methods that would utilize active exploration and interaction, and leverage the powerful human visual cortex to spot and examine interrelationships in large, dense data sets.  Even today the predominant approach to search appears to have as its goal the return of a reduced set of hits.  I term this the "finding the needle in a haystack" approach.  Conversely, InfoSpace was "pro-hay," and sought to develop ways to interactively visualize thousands of returned hits in simple, yet powerful ways with the goal of being able to tease out salient interrelationships and spot candidate hits scattered amongst the returned group that might not otherwise be easily reachable by a simple hit lists, which could require tediously wading through hundreds of pages.

My reasoning, which I still find completely valid and underexplored in the information architecture and user experience design fields, is that leveraging the human visual cortex with interactive visualization will be many times more powerful than using artificial intelligence, agents, or simple schemes such as "page rank" to pre-digest large data sets and return a few suggested hits.  I suggest that this is particularly true when it comes to exploring the interrelationships that are inherent in large data sets by interactively controlling the visualization of different metadata attributes and their associated aspect that's part of the aggregate visualization.

In the late 1990s I created a series of illustrations to demonstrate these ideas and user interface widgets that would support them.  While such methodologies have not yet emerged to become part of the general part of the computing experience, let alone be built into the very desktop/space itself, I feel that eventually the field will come to realize the inherent power in leveraging interactive human visualization in addition to the reductionist list methods that are dominant today.

 

Lesson Learned:  Technologies that enhance, exploit, or leverage existing and powerful human capabilities are often overlooked in favor of those that promise that machines will do the "heavy lifting" and provide us with an "answer."

 

 

            Device, software, and system design projects from the Early 1990s

 

In 1989 I moved from Dallas, Texas to Palo Alto, California in order to join the Silicon Valley community where I felt I would have the greatest opportunities to design both devices, software, and integrated combinations of both.  This turned out to be a very good strategy, as I quickly discovered many different type of projects that fit the goals of my design consultancy.

 

            The Acuson Sequoia Ultrasound System, physical control design strategy and display

interface - 1990

One of the first Bay Area design groups I met and developed a co-consulting relationship with was Lunar Design in Palo Alto.  Lunar was just beginning a large-scale industrial design project with Acuson Computed Sonography in Mountain View, California to design their next generation Sequoia Ultrasound System.

I had shown up at a very fortuitous moment, as they were just being confronted with the design problem of developing the new ultrasound system's user interface.  Like many projects then, and even today, the user interface was seen as two separate parts - the physical controls and the visual software display interface.  The physical controls interface fell into the hardware/industrial design category, so it was in this area that I began my work, conscious that I would have to discover a way to design both in an integrated manner if the whole user experience were to be successful to the degree I felt was achievable.

After observational studies of users and their operation of previous generation ultrasound systems, I noted that most of the functional modality, rather than being integrated together and accessible in an organized and consistent manner, was implemented in a manner that insured it would be difficult to learn and access.  Many separate modal functions were accessible only by second- and third-level functions via the system's keyboard keys.  Once invoked, their use was often the crudest implementation of the raw underlying program operations, as opposed to approaches that were designed to be the most easy for an operator to learn and use efficiently.  Ironically, in interviews with experienced users, I often found an attitude that defended this difficult-to-learn system.  After all, they had already scaled that nearly vertical learning curve, and so saw any attempt to simply its usage as an impediment to their learned skills and power-user speed. I was determined to serve both these needs with a good design solution.

Link analysis studies revealed a great deal of physical movement between widely-placed controls, and operational sequences that required far too many tedious steps.  Through iterative design and modeling, this led to a concept I dubbed "centralized interaction," which meant that the physical controls would be brought together in a centralized place, and create a user experience that was more of a "driving experience" than one where every operation had its own idiosyncratic interaction strategy.

Since this was to be a long project (it took over six years), and I and Lunar both wanted to demonstrate some of the interaction concepts that were being developed, we jointly created a conceptual project dubbed "Modus Operandi," which consisted of a well-designed centralized interaction device along with an associated, and more user-friendly software approach.  Instead of sonography, I chose the example of a PET scanner, as I wanted to stay within the realm of medical visualization.

Concurrent with the Modus Operandi project, I and Jeff Smith, one of Lunar's co-founders, co-wrote an article for the April 1991 issue of Medical Design & Materials entitled, "Applying The Interaction Design Approach to Medical Devices."  In it were presented the basic concepts and methodologies that we were developing in order to tightly integrate industrial design with the overall user experience, involving hardware, software, and information.

The centralized interaction model was adopted for the Sequoia Ultrasound System, and years later in 1999 when the Sequoia system was awarded a Silver in Business Week/IDSA's Designs of the Decade competition, one of the jurors, Dr. Lorraine Justice, IDSA from the Georgia Institute of Technology made the following statement:  "The well-designed product interface was a major contributor to the success and usability of this product.  It has helped to set the design standard for medical products for the latter half of the decade."

 

Lesson Learned:  It is worth taking measured design risks and pushing beyond normal development practices in order to achieve new levels of integration and usability.

 

 

            Syntex Laboratories Gestural slate-device virtual office software for pharmaceutical

salesforce - 1991

In 1991 I was hired by Syntex Laboratories to design a gestural pad-style-computer interface to support the various needs of their large pharmaceutical sales force.  The lead consultant had been Alan Mandler, with whom I'd worked on Sun Microsystem's Open Look GUI a few years earlier.  Mandler had proposed a very unique, and yet incredibly easy to learn and use "virtual office" design.  Rather than foist a complex command-line, or early Windows version software application on these users, which ranged from recent college graduates to older salespeople with limited computer experience, we set out to create a simple virtual office capable of handing their tasks in ways more familiar and accessible.

In addition to design research, where we discovered the range of computer skills and learned about the functions that needed to be addressed, I began iteratively diagramming the system's interactional architecture and mapping functions to elements in the virtual office environment.  This occurred during the period when gestural slate computing was emerging as a possible alternative to the desktop GUI model.  It was also prior to Microsoft's introduction of PenWindows. Many believed that PenWindows was introduced primarily to drive other slate-style efforts out of business, as they represented a threat to Microsoft's growing hegemony in the business computing world.  Whether this was true or not, after the demise of companies such as Slate and Go, PenWindows did not go on to become a major system.

The approach we were taking with the Syntex salesforce project was truly unique, however.  It may have become a great success, had it made it to the finish line, but another business reality intervened and changed everything.  The patent Syntex had on their anti-inflammatory drug, Naprosyn (naproxyn sodium), was due to expire.  This drug brought in over a billion dollars a year, but upon expiration of the patents, and introduction of over-the-counter versions (Aleveª), Syntex was rushing to get past the remaining FDA hurdles to launch a new drug.  Just before their patent expired, their new drug failed to achieve FDA approval, and Syntex was sold to Roche Biosciences.  The project was canceled.

 

Lesson Learned:  Information architectures can be embodied in a wide range of interactional architectures, including virtual representations of real world environments.

Lesson Learned:  Sometimes, even promising design efforts can be done in by external business forces

 

 

            Axcis Pocket Information Systems Trackmasterª -  1992 - 1993

 

Trackmasterª was horseracing betting and statistical management software, implemented on an early palmtop device the Hewlett-Packard HP65.  I was connectable, via dialup modem, to a horseracing database and information network maintained by Axcis, then a startup company.

The challenges were formidable.  The functionality was deep, the visual and physical interface small and highly constrained.  Added to this was a user demographic with an average age (in 1992) of 56 years old.  Granted, this was a highly motivated demographic.  Statistical information, and the means to easily and portably access it, provided an edge to those betting and so they were willing to go to great lengths to learn, if it meant an advantage at the track.

This didn't mean that the interface couldn't be improved, however.  When this client first called me, like many others before and since, the conversation began with the familiar, "Everything's finished.  We only need the user interface."  This often indicates a doomed project, though after examining it I determined that good design would convince them that this could not be a superficial fix atop their current system.

What they envisioned as a quick two or three week project turned out to require about seven months of intense work.  Like many interfaces on devices of this era, the interface graphics had to be broken up to be implemented as character cells.  As such, it was extremely tedious to create the graphical aspects of the interface, but the majority of the program was implemented as navigable spreadsheets and lists.

This device was, at the time, the smallest and most constrained environment in which I needed to provide both a general interactional architecture as well as an information architecture where a wide range of dynamically-changing data was easily accessible and usefully interactive.

The TrackMaster device, which could've easily failed from sheer unusability, proved intuitive and powerful and helped to establish Axcis as a leader in the field of horseracing handicapping databases.

 

Lesson Learned:  Significant hardware and software constraints are not insurmountable barriers to successful usability

 

 

            Apple Computer Home Computers of the Future for Disneyworld's Epcot Center

Innovations exhibit - 1994

In early 1994 I was approached by Apple's Director of Design to conceive and develop two conceptual OS GUIs for home computers Apple was contributing to the Magic House, part of the larger Innoventions exhibit at Disneyworld's Epcot Center.  Both were flat-panel displays, with one hanging beneath kitchen cabinets, and one was a desktop model that represented a home office computer.  The physical computer models were designed and prototyped by Lunar Design.

The first version was a canned demo that synchronized with a Disney character that moved between video monitors stationed along the tour path.  Later on, I and my team turned the interfaces into interactive, touch-screen enabled demos that visitors could actually operate themselves.

Working with a graphic production designer, I designed two embodiments of essentially the same OS GUI model.  These demonstrated several applications apiece.  The kitchen-based computer featured applications such as email, video post-it notes, home energy monitoring and control, an interactive cookbook, online grocery shopping, an Internet browser and concepts for weather and traffic conditions, maps, and driving directions.  The home office computer featured some of the same applications, such as email and Internet browsing, but also financial management and desktop publishing.

Though the web was only in its early infancy at the time, the applications conceived and embodied in these two prototypes were fairly prescient, and accurately predicted the kinds of services that eventually emerged, both on the web and as personal applications.

The singlemost feature that these two models portrayed that eventually emerged almost identically however, was what we now know in OSX as the Dock.  In the two models, there were large icons parked at the bottom of the screen, representing applications that the user most frequently accessed.  When invoked, they would "morph" open, just as the modern OSX Dock icons do today.

While this was a complex project, it did not have a large budget, nor the amount of time necessary to conduct extensive research beforehand.  This was a project that required successfully extrapolating  past knowledge and familiarity with where then-current trends and technologies would lead, and then creating a bold conceptual vision.  It turns out that my concepts were very accurate.

 

Lesson Learned:  It is very definitely possible to perceive and extrapolate user needs and develop successful interfaces without extensive user research, if one is adept at understanding generalized patterns.

 

 

            Starsight Telecast Electronic Programming Guide System  - 1994 - 1997

 

The Starsight Telecast project was an important turning point in my design consulting career.  It marked the first opportunity I had to expand my design consultation to the development of strategic intellectual property, covering a television electronic programming guide GUI, a remote control strategy, and the data model that enabled much of the interactive functionality.

On previous projects I had sometimes been asked to review patent applications, and this made me realize that much patent work was done after a design had been done and often missed strategic opportunities.  By exposure to patent documents I taught myself enough about how claims were constructed to begin offering this as an addition to my design work.  I began telling prospective clients that I would not only design, but design in such a manner as to maximize the product or system's strategic positioning in the marketplace.  This was a rather audacious claim on my part, but I felt that such an approach was not only possible, but potentially more valuable as a consulting service, were it possible to do it successfully and then use that to do more of the same.

The project stretched over two and a half years, with major iterations being developed on roughly six-month cycles.  the industry buzz at this time was centered around concepts such as virtual shopping malls that a user was supposedly going to be navigating around in, or even more unlikely scenarios, such as being able to click on the clothing of an actor and then being able to order it.

I looked at such ideas as intriguing, but highly dubious and missing the opportunities that lay in exploiting some of the features already in contemporary onscreen guides.  Rather than try to design past the grid-based guide, I embraced it as an elegant and compact manner of accessing program information.  My strategy began by attacking the remote control, which was a button-laden monster that had many of the same drawbacks of the medical equipment interfaces that I'd encountered previously.  My goal was to create a "steering wheel for the thumb" as opposed to a button for every individual function.  This would then work seamlessly and efficiently with an interactional architecture developed for the program guide's GUI.

The first thing I did was constrain navigational movement to primarily an up-and-down vertical scrolling.  The result was a remote control that had a clickable thumb-roller, surrounded by directional stepper buttons for moving around areas on the screen.  This eliminated the majority of unnecessarily tedious interactions, such as the act of moving a free cursor around a screen and trying to target objects.  This also fit into a viewpoint I had regarding information in general, which was that it could always be reduced down into scrollable lists, which could be interacted with much more quickly and efficiently.  I wanted a system that was much faster to interact with, and based on much simpler and fewer types of interaction.

Next instead of abandoning the Grid Guide, I dived into it with a concept we later patented and which I called "Contextual Linking."  Put simply, this meant that as one moved about on the grid guide, or up and down a compiled list, from program cell to program cell, clicking would bring up another list that contained both actions that could be performed (Tune to This Program, Record This Program, Remind Me, plus, listings of links, purchasable items, or as many other associated things as could be linked in to that program or its parent channel).

The Contextual Linking concept then required a data model behind the system that allowed for this linking to be added to the raw flat files that constituted the basic channel guide information.  Starsight Telecast had been simply buying this raw information and distributing it to their settop boxes, with no additional information being added.

A series of prototypes were built from this project's iterative cycles, and numerous patents were filed.  In 1997 the company was acquired by Gemstar, and the project development was halted.  The intellectual property was folded into Gemstar's immense patent chest, and to this day remains unbuilt, which is unfortunate.  The goal had been to bring an entirely new level of power and interaction to the television-based environment.

 

Lesson Learned:  The most powerful design solutions do not always involve abandoning current methods and embodiments.

Lesson Learned:  While strategic design and intellectual property development is a smart approach to development, it can sometimes lead to good ideas being stored away unimplemented in patent warchests.

 

 

            Nike Triaxª Series of Runners' Watches, development work on the physical and visual

interface - 1996

In 1996 I was asked by my friends at Astro Product Design in Palo Alto to consult on the development of the interactional aspects of the line of runners' watches they were designing for Nike.  I was excited about this project, as I could see that the watches were going to be incredibly cool and the obvious visibility of the project would be an excellent showcase for good user experience integrated with good industrial design.

Over the course of two or three months, I and my associate, Linda Pomerantz, analyzed the required functionality, and developed a screen layout and general pattern for interaction.  As simple as the resulting system was, the process by which we iteratively developed the interactional patterns was very hard work.

As with many products, the interface's physical buttons had been established prior to the visual interface, and so it was a constraint to map the necessary functional interactions to the existing number of buttons.  Luckily, these turned out to be a good configuration, and it was possible to order the functional modes and their associated interactions in consistent patterns and sequences.

In the end, the product was extremely successful.  It was named by Business Week and IDSA as Consumer Product of the Decade in 1999.  At the time I was very disappointed, as the industrial design and designers were celebrated widely, but the effort that went into the development of the user experience was not recognized or credited.  As I struggled to get exposure for interaction design beyond the familiar media, web, and software interfaces, this felt like a terrible missed opportunity for exposure to these ideas and their value in whole product design.

 

Lesson Learned:  Good interaction design is a discoverable quality, unlike product aesthetics and styling which are instantly visually evident.

Lesson Learned:  Good interaction design is not nearly as noticeable as bad interaction design or the lack thereof altogether.

 

 

            Coherent UltraPulse Encore Surgical Laser Touchscreen Interface - 1998

 

This project entailed the research and development of a touchscreen user interface for a surgical laser system.  Yet again, this was a project where a significant effort had already taken place on the system's industrial design, and the user interface was considered a separate effort to be done afterward.  In this case, however, the interface was entirely restricted to a touchscreen display, and so didn't involve mapping functions to a set of physical controls that had been established without regard to the whole user experience strategy.

This project was also an example of how companies can understand the importance of industrial design, while not recognizing the inherently interrelated importance of a product's user interface.  This was a project that I had to sell pretty hard to get the chance to do.  The client was more than willing to release the product with a very crude and poorly thought out interface, which could very well have seriously hurt the product's overall usability, performance, and overall success.

The first step, after extensive analysis of the product's functionality and general operation, was to observe surgeons using lasers in the operating room.  This device was used primarily in cosmetic surgery, and had two primary modes of operation:  1) Continuous Wave, which was a focused beam used to cut like a scalpel, and 2) UltraPulse, which delivered the laser in pulses, and configurable as different patterns with variable sizes and densities.  UltraPulse was used to ablate the surface of the skin.  A common procedure, and one I and my associate, David Tu observed, was cosmetic surgery around the eyes.  The Continuous Wave mode was used to cut into the inside of the lower eyelid to remove the fat globule beneath the eye.  And the UltraPulse mode was then used to tighten up the skin and smooth out the wrinkles around the eyes.  Different patterns were chosen to, essentially, anti-alias around the eyes.  This was a fascinating procedure to observe.

We also noted in detail the type of interaction between the surgeon and assistants in before and during the procedure.  This led to some important insights about how the device was reconfigured throughout the procedure and how the settings were viewable by the surgeon and assistants.

The design strategy centered around discovering the important information about the device settings, and how these could most easily be seen and understood.  There were also important interrelationships between certain settings such as Power (in joules) and Pulse Rate (in Hertz, or pulses per second).  These two settings, though independently configurable, were also interrelated in that at higher powers, pulse rate was limited, and vice versa.  In earlier models, this relationship was not visually apparent.

In our final design, these two settings were embodied as two segmented meters, with bright segments indicating the level currently set, and a secondary, darker segments indicating what was possible given the other related settings current setting.  So for example, as the Power was raised, the display for Pulse Rate would show the darker segments decreasing.