Published: 1988
Publisher: Basic Books Inc. New York
ISBN: 0-465-06709-3
Donald Norman provides an excellent treatise in the design issues surrounding usability. He focuses most of his effort on the design of physical products such as automobiles, home appliances and building components, however his attention to computer interaction design is very prescient considering the year of this book’s publishing.
VISIBILITY
One of the primary themes of the book is “visibility”… making known to users what actions are available as well as what effect those actions have. One side of visibility is the mapping of intended actions to actual operations. Designers need to keep in mind that users of their products are generally not intending to use their product. Instead, users are intending to perform some task and are using the product to accomplish this task. Thus the user has an image in their mind of what they are trying to accomplish. When they approach a product or computer program, the designer should present them with visual and / or audible cues to suggest which actions can be taken to accomplish the desired task.
On the flip side of the visibility spectrum is what is commonly known as feedback. When a user takes an action, either on a physical product or on a computer program, immediate and visible feedback should occur. This feedback should map back to the users intended action, not necessarily the designers view of the world.
PRINCIPLES
Some principles of good design that Donald Norman offers are:
1) Provide a good conceptual model
2) Make things visible
3) Good mappings between the model and what is visible
4) Feedback to the user
Some other general ideas offered are:
- It takes 6 tries to get a design right. (Don’t get emotionally attached to your first design)
- You should removed unused or unnecessary functions to simplify the interface
- Asking users for feedback is not enough. Users tend to blame themselves for problems rather than the product. You must OBSERVE them using the product.
ERRORS
Handling errors is an important matter in product design. There is an entire psychology of error that Norman explores. For many errors that occur during product or program usage, the user will tend to blame themselves, leading to the need for observation noted above. On the flip side, users who end up with many errors while using a product will blame the product quickly and it will be difficult to overcome this aversion to the technology later on.
For these reasons, Donald Norman believes that errors should be:
1) Easy to detect
2) Have minimal consequences
3) Effects should be reversible
One type of error that humans commit is called the “slip”. A “mistake” is when someone chooses the wrong goal. A slip on the other hand is when someone chooses the right goal, but chooses the wrong action to get there. These are the type of errors that designers can help with. Some types of slips are:
1) Capture errors (something else captures your attention)
2) Description errors (you mistake one thing for another)
3) Data driven errors (you are looking at something green and tell someone you have green eyes even though you don’t)
4) Associative activation (think Freud)
5) Loss of activation (forgetfulness)
6) Mode errors (you thought the program was in “edit” mode but it was in “play” mode)
To design for errors you should think of user errors as an attempt to do a task via actions that approximate the desired results.
FORCING FUNCTIONS
Forcing functions are times where you force the user to take an action or sequence of actions in order to keep them from making an error. Often users will find these annoying and will disable them because they don’t think they need them (I tend to disable UAC on Vista!) Forcing actions have a cost to the user that should be taken into account but they can be very useful in the right situation. Forcing actions take the following forms:
1) Interlock (force correct sequence)
2) Lock in (keep an operation going)
3) Lock out (keep a user from performing an action)
EASIER IS NOT ALWAYS BETTER
Keyboard layouts have an interesting history. Norman goes into detail about this history but the highlights are that the QWERTY keyboard layout was originally derived from the mechanical limitations of the typewriter. It was necessary to keep the bars that lifted the typefaces to the paper from interfering with common letter combinations being typed too quickly. Interestingly, even though the physical limitations no longer apply, the QWERTY layout has proven to be one of the best for touch typists since the same letter combinations make it possible for one hand to prepare to type a letter even while the other hand is still typing the last one.
There is a keyboard layout that has been discovered to be better for touch typists than the QWERTY layout. The Dvorak keyboard layout is better (by about 10% for expert users) for speed and accuracy. Unfortunately, for behavior that must be learned (such as touch typing) easier is not always better. There is not enough benefit in switching to the new layout to justify the enormous amount of relearning that must be done by the millions of touch typists who are already familiar with the QWERTY keyboard.
DESIGNERS ARE NOT TYPICAL USERS
One thing that Norman stresses very strongly is that designers are NOT typical users. Designers should remember that just because something makes sense to them, it may not make sense to the typical user. One way to look at this dichotomy is as follows:
- Designers are experts at the device (knowledge of the product is in their head)
- Users are experts at the task (knowledge of the product is in the world)
7 STAGES OF ACTION
An interesting diagram that Norman uses to explain the cycle of user interaction starts with the user choosing a Goal. The goal is then translated into Intentions. These Intentions must be mapped onto possible Actions which are then Executed. After Execution, the nebulous concept of the The World (which represents the system the user is operating on) takes over and the user tries to get feedback. This feedback starts with the users Perception of the system state which is then Interpreted by the user. After Interpreting their Perception of the system state, the user Evaluates the feedback to see if what they did, got them closer to their Goal or not.
This leads to two Gulfs that designers need to bridge:
Gulf of Execution – is there an action available that maps to my intentions?
Gulf of Evaluation – Does the system provide mapping from the feedback to my intentions?
EASE OF USE
Answering these questions can lead towards better ease of use:
How easily can you…
- Determine functions
- Tell possible actions
- Map intentions to actions
- Perform an action
- Tell if the system is in the right state
- Map system state to the interpretation
- Tell the system state
Easy looking interfaces can make programs easier to use.
- Too many controls make it look complex
- Too few controls increase the mapping problem (what are the available actions?)
Solution: Group related controls and hide unused controls.
LEVERAGE
Designers can leverage several concepts to create better usability. One such concept is the notion of Power of Constraint. Norman uses and interesting exercise to demonstrate this one. Think of a word that describes a building material. You might come up with any number of words that match this one. Now come up with a word that rhymes with “eel”. You might think of a large number of words here as well. But if I ask you to think of a building material that rhymes with “eel” you will almost certainly think of the word “steel”. By constraining the available options on a two dimensional scale, you can greatly improve the mapping of a users intentions to available actions.
Another concept that Norman refers to is the Power of Knowledge in the world. There are two places that usable knowledge can live. It can live in your memory (either short term or long term) or it can live “in the world” (i.e. in a help manual, the user interface, a sign or on a label.) Putting the knowledge necessary to use your product in the right place is critical to making it easy to use. A general rule that Norman points out is that if a design relies on labels, it may well be a faulty design.
Ultimately, relying on memory, particularly for complex operations is not a good choice. In these cases, designing systems that can be logically figured out is the way to go. Even here though, you need to design systems with either a narrow or a shallow decision tree. If you have a decision tree that is both wide and deep, it will be very difficult for the average user to figure it out.
Making computer systems explorable is a key concept. In order to do this:
1) Each states available actions should be visible
2) Effects of actions should be immediate and visible
3) Actions should be reversible
CREEPING FEATURISM
In order to keep products and programs from being too complex to be usable, Norman guards against what he calls “creeping featurism”. Just because you CAN do something with a product or program doesn’t mean you SHOULD do it. Just because a user asks for a feature doesn’t mean it should be added. Adding too many features adds complexity to a product that may or may not need to be there.
Many programmers try to use program settings to make their program be “all things to all people.” Unfortunately this bypasses the power of using affordances (signals of available actions) and constraints (signals of what is possible to do) to limit the complexity of a program.
7 PRINCIPLES OF SIMPLIFYING TASKS
1) Use knowledge both in the world and in the head (in the right place!)
2) Simplify structure
3) Visibility!
4) Get mapping right
5) Exploit constraints
6) Design for error
7) Standardize (as a last resort!)