Ban the Bombby Alan CooperWhen users see an error message box it is like another person telling them "Fatal error, buddy. That input really sucked!" in a loud and condescending voice. Users hate this! Putting interaction like this in your program is extremely bad human interface design. Despite this, most programmers just shrug their shoulders and put error message boxes in anyway. They don't know how else to create reliable software. The first computers were undersized, underpowered, expensive, and didn't lend themselves easily to software sensitivity. The operators of these machines were white-lab-coated scientists who were sympathetic to the needs of the CPU and weren't offended when they were handed an error message. They knew how hard the computer was working. They didn't mind getting a bomb, an "Abort, Retry, Fail?" or the infamous "FU" message. This is how the tradition of software treating people like CPUs began. Ever since the early days of computing, programmers have accepted that the proper way for software to interact with humans was to demand input and to barf when the human failed to achieve the same perfection level as the CPU. I call this attitude silicon sanctimony. Examples of silicon sanctimony exist wherever software demands that the user do things its way instead of adapting to the needs of the human. Nowhere is it more prevalent, though, than in the omnipresence of error messages. Silicon sanctimony is a negative feedback loop, ignoring users when they do what the software wants, but squawking at the slightest deviation from what they expect. Silicon sanctimony is a requirement for actions within software. Every good programmer knows that if module A hands invalid data to module B, module B should clearly and immediately reject the input with a suitable error code. Not doing this would be a great failure in the design of the interface between the modules. But human users are not modules of code. Not only should software not reject the input with an error message, but the software designer must reevaluate the entire concept of what "invalid data" is. When it comes from a human, the software must assume that the input is correct because the human is more important than the code. Instead of software rejecting input, it must work harder to understand and reconcile confusing input. Software can prevent problems from arising by assuring that the user can't enter invalid data. Humans have emotions and feelings: computers don't. When one chunk of code rejects the input of another, the sending code doesn't care; it doesn't scowl, get hurt, seek counseling, or whine for a Macintosh.. The processor doesn't even care if you flip the Big Red Switch. On the other hand, humans, (even programmers), have emotions, and they are raging out of control compared to anything happening in silicon. When you offer some information to a colleague and she says "Shut up, that's stupid", your feelings get hurt, your ego crushed. You search for mistaken meanings in what you said. You look in the mirror, checking your teeth for bits of spinach. All of these actions are part of human nature. Humans, however, respond favorably to positive feedback. Whenever the software can adapt to the input and accept it, the software replies with some indication of success. If the software cannot make sense of the input it makes no reply at all-silence indicates failure. Just like Mom taught you when you were a tot: "If you can't say anything nice, don't say anything at all." Good advice, Mom, for software interaction with users. The interaction I have with a hammer is illustrative of healthy interaction between a human user and a tool. When I use a hammer incorrectly it doesn't give me an error message. It doesn't attempt to correct my behavior. It doesn't point out my failings as a carpenter. It just doesn't put nails in very well. The hammer rewards good use with good results and rewards poor use with bad results. The simplicity, appropriateness and human scale of the interaction between human and hammer is proven by the lack of professional societies devoted to hammer design and by the lack of Opinion columns in carpentry magazines on how toolmakers can create more harmonious relations with hammer users. One of the big reasons why software is so hard to learn is that it so rarely gives positive feedback. People learn better from positive feedback than they do with negative feedback. People want to use their software correctly and effectively, and possess the motivation to learn how to make the software work for them. They don't need to be slapped on the wrist when they fail. They do need to be rewarded, or at least acknowledged, when they do succeed. They will feel better about themselves if they get approval and that good feeling will be reflected back on the product. Advocates of negative feedback can cite numerous examples of its effectiveness in guiding people's behavior. This evidence is true, but almost universally, the context of effective punitive feedback is getting people to refrain from doing things they want to do but shouldn't. Things like not driving over 55 mph, not cheating on their spouses and not chiseling on their income taxes. But when it comes to doing what people want to do, positive feedback is best. Imagine a hired ski instructor who yells at you or a restaurant host who loudly announces to other patrons that your credit card was rejected. Keep in mind that we are talking about the drawbacks of negative feedback from a computer. To be given negative feedback by another person, although unpleasant, can be justified in certain circumstances. One can say that the drill sergeant is at least training you how to save your life in combat, and the imperious professor is at least preparing you for the vicissitudes of the real-world. But to be given negative feedback by software-any software-is an insult. The drill sergeant and professor are at least human and have bona fide experience and merit. The program is doo-doo, pond scum. It is less than zero. To be told by software that you have failed is humiliating and degrading. Users, quite justifiably, hate to be humiliated and degraded. There is nothing that takes place inside a computer that is so important that it can justify humiliating or degrading a human user. Nothing. I don't care how important you think your precious database integrity is, it isn't worth insulting a person. If data integrity is a big deal for you, you need to work on methods of maintaining it without pissing off the user. There are plenty of good ways to do this. We resort to the negative feedback ways of silicon sanctimony out of habit. There are three fundamental ways to eliminate error messages:
1. Make errors impossible Making it impossible for the user to make errors is the best way to eliminate error messages. Instead of forcing the user to key in their selection, present the user with a list of possible selections from which they can choose. Instead of making the user type in a state code, for example, let them choose from a list of valid state codes or even from a picture of a map. Make it impossible for the user to enter a bad state. Another excellent way to eliminate error messages is to making the program smart enough so it eliminates the need to ask the user questions. Many error messages say things like "Invalid input. User must type xxxx." Why can't the program, if it knows what the user must type, enter xxxx by itself and save the user the tongue lashing? Instead of demanding that the user find a file on disk, introducing the chance that the user will select the wrong file, have the program remember which files it has accessed in the past and allow a selection from that list. Another example is designing a system that gets the date from the internal clock instead of asking for input from the user. While error messages as feedback should be eliminated, feedback of a positive nature is a great way to reward the user for correct program usage. The best way to give positive feedback to users is with sound. Unfortunately, for years error message boxes were accompanied by those loud, shrill, tinny little "beeps" and sound has become strongly associated them. That beep is a public stigmata of the user's failure. It coldly announces to all within earshot that you have done something execrably stupid. It is such hateful silicon sanctimony that it has created an unquestioned belief in the minds of most software developers that sound is bad and should never again be considered as a part of interface design. Nothing could be further from the truth. With the exception of computer software, almost every object and system offers sound as positive feedback rather than as negative. When we close the door, we know that it is latched when we hear the click but silence tells us that it is not secure yet. When we are talking with someone and they say "Yes" or "Uh-huh" we know that we have gotten through to them. When they are silent we know our arguments have slipped off the track somehow. When we turn the key in the ignition and get silence, we know we've got a problem. When we flip the switch on the copier and it stays coldly silent instead of humming loudly we know that there is trouble. Even things we consider silent make noise: Turning on the stovetop gets a gratifying hiss of gas. Electric ranges are less friendly and harder to use because they lack that sound-they have to have indicator lights to provide the positive feedback. Our software should give us constant small audible cues in exactly the way that good keyboards click softly when we successfully press their keys. Our programs would be much friendlier and easy to use if they issued barely audible but easily identifiable sounds when user actions were correct. The program could issue a soft "coo" every time the user entered valid input to a field. If the program didn't understand the input, it would remain silent. The user would immediately be able to correct their input, and they could do so without embarrassment or ego bruising. Whenever the user started to drag an icon, the computer could issue a short "toot-toot," then a sibilant hiss as the object was dragged. When it was dragged over non-droppable areas, the hiss would change tone to something more dissonant. When the user finally released the mouse button, she would be rewarded with a nearly silent "Yeah!" from the speakers if successful or frigid silence if the drop wasn't meaningful. People frequently counter this argument by telling me how people don't like audible feedback, how they are offended by the sounds that computers make and how they don't like to have their computer beeping and booping at them. To this I say "Bunk!" People are conditioned by two things about sound and computers: 1. Computers have always made noises when the program issued error messages
Given the choice of no noise versus noise for negative feedback, people will choose the former. Given the choice of no noise versus unpleasant noises for positive feedback, people will choose either based on their personal situation and taste. Given the choice of no noise versus soft and pleasant noises for positive feedback, people will almost universally choose the audio. We have never given our users a chance by putting high-quality audible positive feedback in our programs, so it's no wonder that people associate sound with bad interfaces. The audible feedback must be very quiet, no louder than the sound of the keyclicks on a notebook computer. The program should make some sound every time the user directs the program correctly or every time the user enters information that the program understands. The user will quickly come to depend on these sounds and their ability to work more quickly and efficiently will increase. Undoubtedly all of these solutions will cause more work for programmers. This doesn't bother me a bit. I don't want programmers to have to work harder but given the choice between programmers working harder and users working harder, I'll put the programmers to work in an instant. It is the programmer's job to satisfy the user and not vice versa. If the programmer thinks of the user as just another input device, it is easy to forget the proper pecking order in the world of software design. Another method of eliminating error messages is for the program, when it receives bad input, to assume that maybe it is unintelligible because the program, not the user, is ill-informed. Information that is entered in an unfamiliar sequence usually is considered an error by software, but people don't have a hard time with the concept. Humans know how to wait, to bide their time until the story is complete. Software usually jumps to the erroneous conclusion that out of sequence means wrong, and issues the evil error message box. If, for example, the user enters an invoice for an invalid customer number, the program could accept the transaction and make a special notation to itself that indicates that the user must eventually validate it. The program would then watch to make sure the user entered the necessary information to make that customer number valid before the end of the month book-closing. In fact, this is the way most humans actually work. They don't usually enter "bad" codes. Usually, they just enter codes in a sequence that the software isn't prepared to accept. We make the assumption that a customer account must be established before an invoice credited to that account can be valid, but nowhere is this carved in stone. Why can't software accept invoices independently of account information and merely assume that things will be explained to it in due course? If the human forgets to fully explain things to the computer by month end, the program can dump irreconcilable transactions into a suspense account. The program doesn't have to bring the proceedings to a halt with an error message. After all, the transactions in the suspense account will almost certainly amount to only a tiny fraction of the total sales and so will not be a significant factor in the business reporting cycle. Why stop the entire process because something inconsequential is missing? Why ground the airplane because the bar is short one little bottle of Scotch? But if you insist on pressing me, I will admit there is one situation where an error message is acceptable: When your printer is fully engulfed in flames. Copyright © 1996, Alan Cooper |