, RIACS/NASA Ames Research Center
Pages: pp. 4-6
Last week I tried to reserve an auto rental over the Web. The site asked me where and when I wanted to rent, presented choices of possible cars, went through a long dialogue to get personal data such as addresses and credit-card numbers, and then told me that the car I had selected was unavailable. I iterated the process through several different types of cars, always with the same result. I eventually retreated to an albeit-more-expensive-but-nevertheless-willing-to-actually-rent-me-something competitor. I'm not sure what the original rental company thought this activity's purpose was, unless it hoped to catch me failing to uncheck the "send me email offers" box, thereby providing a "requesting" spam recipient into perpetuity.
At last month's European Conference on Object-Oriented Programming (ECOOP), I met a student contemplating a dissertation on graphical tools for program understanding. She expressed the belief that the best tools maximized the amount of information presented to users. I was surprised, after 20 years of Tufte 1–3 and work on the theory and practice of interface design, that a student building a system with a major interface component would start from such an assumption.
These experiences lead me to believe that a discussion on the design of usable systems might be appropriate.
I told the student that maximizing the amount of information a system conveys to a user isn't a good idea. Rather, the designer should keep in mind what the user is trying to accomplish and figure out how to minimize the effort (physical and intellectual) the user must expend to get that task done. For example, if a user is seeking a single value, it's better to present a screen with just that value than a screen that includes that data along with a lot of additional, superfluous information. Separating the grain of edible data from the screen full of chaff can be painful. It also implies that a Web page cluttered with advertisements is not as simple to use as one without — a moral likely lost on advertisement-supported Web page designers — and that there's no point in getting details about the purchase of a product you can't sell. Raskin's book, The Human Interface, contains a wonderful illustration of these points, showing how attention to the user's task and the costs of different activities can be combined to produce more usable systems. 4
Interface design is complicated, both in the complexity of the design space and the pragmatics of usable systems. The user-interface designer can choose from a large variety of mechanisms, including (to name a few) command languages, character languages, natural languages, direct-manipulation graphics, forms, and menus. We can indicate our choices to systems via switches, dials, keyboards, mice, tablets, joysticks, touchpads, and touchscreens — or perhaps by pushing foot pedals, speaking, whistling, or grunting rhythmically. The machine can respond with a display that ranges from lighting a single point to presenting a high-resolution, color animation. It can simultaneously squeak, flash, and speak. For blind programmers, there is even a device that converts ASCII to Braille, invoking the sense of touch. (For the moment, proprioception has been employed only in certain flight simulators and games, and designers have made little use of the sense of smell — surely serious oversights.) These controls can be organized into command sequences, dialogs, macros, forms, menus, direct-manipulation systems, and so forth.
The simplicity of an artifact varies depending on who is doing the evaluation. My favorite example of this comes from cooking.
"When Carl Sonthemimer launched Cuisinart in this country more than a decade ago, he had to do a bit of everything at the fledgling enterprise, including writing the instruction manuals for the newfangled food processor. So the MIT engineering PhD was particularly flattered when he received two letters from customers praising the depth and thoroughness of his instructions…But 'when I called up to thank them, I found out they were (also) engineering PhDs from MIT.'" 5
This begs the question of what we want from a good user interface? Many conflicting things.
A user interface's primary goal is to reduce the mental load (the cognitive overload) on the user. People have trouble remembering things, solving problems, and planning and expressing goals. To the extent that a device makes them do these things, they suffer. To the extent that a device saves them these mental actions, they appreciate it. Thus, systems reduce the user's mental load when designed to achieve goals that match the user's — systems that present a coherent and comprehensible picture of their internal behavior, that understand the natural, conversational idiom of the user's task, and that understand, if not the natural task idiom, at least the natural idiom of the device. (This goal excludes, of course, artifacts designed precisely to exercise one or more of these factors — games, puzzles, and teaching machines come to mind.) In general, interfaces mediate complexity. To the extent that the interface reduces a device's complexity (without subverting its utility) it will be successful.
People are not all the same. Good interfaces recognize this fact and adjust (or at least can be adjusted) for such differences.
People differ in what they're trying to accomplish. Often, these differences are driven by using the same system to perform different jobs. For example, the ideal word processor for someone composing a document is not ideal for someone editing a document someone else has written. (Naïvely, the composer needs to easily insert and move text and to obtain an overview of the document.
The editor is likely to be processing the document serially and to be more concerned with search and localized alteration than insertion and overview. The editor's changes ought to be marked; tracks of the author's changes are likely to get in the way.) The receptionist interacts with the email system almost exclusively by sending short messages to specific individuals; the manager likely reads more (and longer) emails, sends messages to groups, and files and organizes messages.
Users differ in their knowledge of the task at hand. Good interfaces give guidance to task novices; poor interfaces obstruct experts with unnecessary kibitzing.
Similarly, users differ in their knowledge of the device they're using. Again, an ideal interface teaches as much of the system as desired to novices, while not interfering with experts' actions.
Some people prefer to do things a certain way. On one hand, it's better if the machine can do it their way, rather than forcing users to think its way. For example, I remember a program editor that required the user to specify an operation's arguments before the operation itself (that is, "tell me what you want to insert, and then tell me where to insert it"). I found this difficult because I usually decide I want to do an insertion before I've composed what it is I'm going to add. Forced to compose first, I forget where it was going to go and what I was going to do with it there. However, I know at least one other person who assured me that he couldn't imagine editing any other way.
On the other hand, it has been argued that individual customization is a barrier to interpersonal interaction — with customization, you can't work effectively on a device with another person, easily guide them through debugging a problem, or walk up to another system and have it behave in a predictable fashion.
Not everyone thinks like a computer-science geek. Systems should therefore present and accept information in the manner that matches the user's mental orientation.
Just as people have individual differences, there are also some human universals. I often feel that the WIMP (windows, icons, menus, and pointing device) interface style has been optimized for people with three hands. Similarly, to err is human, though too many systems deal poorly with allowing users to recover from their mistakes.
The user should feel good about interacting with the system. This includes augmenting positive feelings such as curiosity and interactivity, and reducing negative feelings such as frustration and boredom.
Acting in opposition to good interface design is the reality of engineering projects. Good interfaces are expensive. They require extra effort to design and develop and place greater demands on the underlying hardware than naïve interfaces. Quality is often refined only through extensive user testing. A similar conflict rages within the interface for any given system — the desire to expand functionality can conflict with reducing complexity just as assigning a particular action to a given command or key limits the use of that command or key for other actions.
Next issue, I'll build on this brief sketch of the goals of good interface design. We'll consider in more detail the elements of the problem space that interface designers should recognize in doing their work.