"People Propose, Science Studies, Technology Conforms"
-- Don Norman's person-centered motto for the 21st century.
This is exactly what Donald Norman, a widely recognized expert on design, have been trying to teach for the past 27 years. He strongly believes that the things we use in our everyday lives should be easy to use and it should be more than obvious how to use them. There could hardy be anyone that disagrees with this statement. Yet, why simple devices like doors, sinks, showers, telephones, cars, and computers are designed in such a way as to cause confusion and frustration. These are the kind of things that Norman examines in his books The Design of Everyday Things and Information Appliances, and in his numerous articles.
Nowadays we have technology that can do pretty much everything for its users if they know how to use it. However, this task has proven almost impossible even for everyday things like VCRs and washing machines. Many people are afraid to use their appliances simply because they do not know how to operate them and are afraid not to damage them. Norman refers to this as technophobia which seem to be fairly wide spread "disease". However, he blames the designers of the appliances and not the users. If these devices were designed right the people would not be afraid to use them.
We cannot expect complex things like power plants and airplanes to be easy to use; these will always require trained personnel and user manuals. However, why we still have doors that come with a "push" or "pull" sign on them. This one-word user manual, as Norman puts it, testifies to a significant design flaw.
In his writings Donald Norman suggests several design principles that
ideally should be met for every device and appliance: visibility, feedback,
natural mapping, constraints, and design for error. Let's take a closer
look at each one of them.
Visibility and feedback
The visibility principle states that designers should make visible the important aspects of a system. Ideally, the actions that a user can perform on a device should be obvious by just looking at the device itself. The feedback principle states that the effect of all user actions should be immediately obvious through some kind of system feedback (audio or visual cues, or any other form that is easy to detect).
Natural mapping
There should be a clear relation or mapping between intentions and possible actions and between actions and their effect on a system or device. Norman used to start his first lecture on design by asking a student to turn off a given set of lights in the classroom. Usually there are many lights and many switches in a classroom. Finding out which switch corresponds to a given set of lights can be rather hard. Several tries are usually enough, but isn't it possible to know the mapping instantly?
One possible, solution is to arrange the light switches in the same pattern as the lights on the ceiling. We can have a small plate with the room layout printed on top of it, and we can put the light switches in places that directly correspond to the physical location of the lights that they control. In essence this is what Norman has in his house. It is true that every house has different layout and will need a different switch layout thus making the initial installation difficult. However, the task is not impossible. If we think of how many times we hit the wrong switch and spend time correcting the error afterwards, probably it might be worth the effort of getting the mapping straight from the beginning.
The problem of mapping gets even worse as the complexity of the device increases. Even the simplest electronic watch has about a dozen functions (tell date and time, stopwatch, set date and time, etc.). At the same time it comes with about 4 buttons. It is not at all obvious what the mapping is by just looking at the watch.
Constraints
There are several kinds of constraints: physical, semantic, logical, and cultural. Ideally some or all of these should be used to prevent unwanted actions or sequences of actions that should never be executed on a system or device. For example, one should not put metal plates in a microwave oven. This action is difficult to prevent unless the oven has a metal detector inside which will increase its price. Thus, the only preventive mechanism that the designers can use is a warning label: "Do not put metal objects in the microwave".
There are other actions, however, that can be prevented easily if the power of constraints is utilized. For example, a car door should not be locked if we left our keys inside the car. The designers must make sure that when the keys are inside the ignition switch the door cannot be locked. The army uses physical constraints to increase security of weapons. It is not possible to launch a nuclear missile unless two keys are turned on at the same time. The keyholes for these keys are physically separated so that it is impossible for a single person to perform the launch.
Design for error
Every now and then we hear about an accident which was caused by a "human error". One example that Norman gives is the Soviet Union's Phobos 1 satellite which was lost on its way to Mars not long after launch. Later it was found that the cause for the error was an operator who sent a sequence of digital commands to the satellite but mistyped a single character. Unfortunately, this triggered a test sequence stored in ROM which was supposed to be executed only when the spacecraft was on the ground. The wrong sequence set he satellite in rotation and it was no longer possible to resume control over it; it was lost in space. Science magazine classified the accident as "malignant bad luck" [5].
This report is really strange and Norman rightly so critiques that it should not be called bad luck but rather bad design. What kind of design is that, that allows for a single mistyped character to trigger a completely different action which was not supposed to be executed while the satellite was in space anyway [3]. The designers of the satellite probably invested a lot of time to make sure that the communication systems are safe from external interference and that the spacecraft is free form mechanical problems. However, they never bothered to look into what kind of errors can be caused by humans.
Norman argues that the behavior "human error" is far easier to predict than some other kinds of errors like mechanical and electrical. There are certain models and patterns in the way people make errors and if they are accounted for in the initial design the number of "human errors" will be dramatically decreased. Probably we should even change our whole attitude towards errors. We should say that they occur because the design is bad and not because the users are not careful and made an error.
In a well designed system there should be a way to undo an erroneous interaction and in the rare cases when the action cannot be reversed there should be a warning which is not easy to ignore. Also, if the result of an irreversible action can be potentially disastrous it should not be easy to perform this action in the first place. For example, in computer systems it should be relatively harder to remove a file than to rename it. The user should be forced to do something different and usually harder than normal.
Even if we do our best in designing for error people will still continue to make errors. Certain type of errors, called slips, are almost impossible to prevent. Slips occur when we have a clear idea of what we want to achieve but for some reason we use the wrong tool or perform a different action. Slips are done at a subconscious level and happen almost automatically. Even the most experienced people make slips. Therefore, designers should make error discovery possible. This can be done with appropriate observable feedback to the users so that they can, at a later time, discover their error and correct it by using the undo functions.
Here is a brief summary of the 4 most important design for error principles that Norman suggests:
2. Make it possible to reverse actions - to "undo" them - or to make it harder to do what cannot be reversed.
3. Make it easier to discover the errors that do occur, and make them easier to correct.
4. Change the attitude toward errors. Think of an object's user as attempting to do a task, getting there by imperfect approximations. Don't think of the user as making errors; think of the actions as approximations of what is desired.
Let's see how the design principles that we just looked at are violated in the single most commonly used (office) device today: the personal computer.
In his new book, Information appliances, Don Norman describes the PC as one of the worst devices that we are using today. The problem is that the PC is expected to be able to do almost everything and to be used by almost everybody on this planet. Having such device may seem like a good idea but having a common interface to it is not a good idea at all. Today we have a keyboard, display, and a pointing device; no matter what we are trying to do with the PC we have to use one or more of these. In other to have a do-all device we have to make a big compromise and sacrifice simplicity, ease of use, and stability in order to have a common interface [2, Ch. 6].
To make this statement more obvious Norman brings the example of a Swiss army knife that has a dozen functions (knife, scissors, screwdriver, fork, spoon, etc, etc.) However, neither of these is easy or efficient to use. If we are given the choice of using a regular screwdriver and the screwdriver that comes with the Swiss army knife we will always prefer to use the former because it is much more convenient. It is more convenient simply because it is designed to do only one think and does it really well. The Swiss army knife can do many things but it does neither of them well. Also, it is always hard to find the right tool when you need to use it; you usually open at lest two others before you find the right one.
The same analogy can be applied to the PC. We clearly have an observation problem because we don't know in advance what the PC can do for us. The early operating systems displayed a command prompt on a blank screen and the users had to figure out what commands are available to them, usually by reading lengthy manuals. This is still true for UNIX.
Modern Graphical User Interfaces (GUI) have tried to hide away the complexity of the system and the underlying hardware, and associate commands with fancy menus or icons. Norman argues, however, that the GUI's worked well in the early 80's when the idea of direct manipulation made sense because computers did not hold too much information and people did not have more than few things on their desktops [2, Ch. 6]. Nowadays things have changed. The number of application and the number if information available to the user (mainly due to the expansion of the Internet) has increased tremendously. Now our desktops are cluttered with applications and icons that we have never used nor do we know how to use. All this adds to the complexity of our daily interaction with the computers.
The mapping problem is even worse than the visibility problem. A simple application like a text editor can have several different modes of operation. Different modes associate one and the same key with different actions. To make things worse software companies keep adding new modes and commands to their products. For, example Microsoft word had 331 different commands in 1992 and in 1997 it already has 1033 [2, Ch.6]. This is what Norman calls creeping featurism. Users are offered more and more features even though they don't really need them. The advertisement however, makes them believe that they cannot do their work productively without the new features. And so on till the next version of the software, which will be even more complicated and everything will starts over again.
To avoid all these problems Norman proposes a new approach to computing Activity Based Computing (ABC). In other words, we should build computers and software to support a specific kind of activity only. However, the emphasis should be on the activity and not on the application. For example, we should not do word processing, we should write letters and memos.
This idea can be generalized to all everyday appliances. They should
be designed with a specific task in mind. Thus, learning how to use a device
will be the same as learning how to do the task. The classical computer
example is the first spread sheet program, VisiCalc. It was extremely useful
and people had no problems leaning how to use it because they were working
on their accounting problem and not struggling with their computer. [1,
p.180]
Conclusion
Although it seems that Norman is being over critical at times he is right in most of the cases. It seems that today bad design predominates in all products. People are wasting valuable time trying to figure out how to operate otherwise simple thing. If we can improve the design of the simple things that we use everyday, then the frustration that we are getting by using those devices will be gone. This will probably make our lives a lot easier and happier.
We should not accept new technology unless it is designed to be usable.
After all technology changes over time and it is far easier to change the
technology than to change the social, organizational and cultural aspects
that it carries. [2, ch.1] In the concluding remarks to The Design of
Everyday Things Normal advises us to boycott unusable design by not
buying products that are badly designed. He hopes that this will give a
warning sign to the companies that produce unusable things and they will
finally improve the design of their products.
References:
[1] Norman, D. A., the Design of Everyday Things, 1988; New York, Doubleday Publishing Group.
[2] Norman, D. A. (in press: Fall, 1998). Information Appliances. Cambridge, MA: MIT Press. Excerpts are available here.
[3] Norman, D. A. (1990). Commentary: Human error and the design of computer systems. Communications of the ACM, 33, 4-7.
[4] Norman, D. A. (1995). Designing the future. Scientific American, 271 (9, September), 186-7
[5] Waldrop, M. M. Phobos at Mars: A dramatic view -- and then failure.
Science, 245 (1989), 1044-5.