To Err Is Human – A Two-Sided Issue...

By Gerd Waloszek

When searching for new quotes to publish on the SAP Design Guild, I scanned Don Norman's book, The Design of Everyday Things, that I had just read – and I was successful. I found two interesting quotes in the chapter To Err is Human:

"Of course, people do make errors. Complex devices will always require some instruction, and someone using them without instruction should expect to make errors and to be confused. But designers should take special pains to make errors as cost-free as possible."
"If an error is possible, someone will make it. The designer must assume that all possible errors will occur and design so as to minimize the chance of the error in the first place, or its effect once it gets made. Errors should be easy to detect, they should have minimal consequences, and, if possible, their effects should be reversible."

Admittedly, the two quotes are somewhat redundant. They highlight the fact that people make errors, and that, if there is a chance of an error being made, someone will eventually make this error. Therefore, Norman encourages designers to minimize the possibility of errors, and if they cannot be prevented altogether, to make them at least as cost-free as possible. And rightly so, because I am convinced that errors are still the number one cost factor in computing, far ahead of viruses and spam e-mails.

On the other hand, I felt somewhat uneasy with Norman's statements. After a while, I knew why: Norman's view of errors is – at least with respect to these two statements – incomplete. He deals only with the errors that users make – probably because he is a cognitive psychologist. But where computers are concerned, user errors are not the only errors that can occur – many more are possible: We call them system errors, program(ming) errors, and the like. These errors can cause blue/black screens (depending on your operating system), frozen screens, disappearing application windows (with or without notice...), visual garbage, strange behaviors of applications, wrong results – and often lost data, which amounts to lost work and wasted time.

You might, of course, argue that these are two different pairs of shoes. In the first case, designers and developers need to take the sloppy, error-prone human behavior, or "misbehavior," of users into account and make allowances for it. In the second case, the sloppy, error-prone behavior of developers is responsible for the errors. Developers are also humans and therefore often not diligent enough. Moreover, they are driven by tight schedules and are sometimes simply a victim of the complexity of their own applications. But as we all know, there is a simple and effective remedy for this problem: Let the users find the errors. This strategy is also known as "banana software."

Bananas

Figure 1 : A complex piece of banana hardware (from www.murdoch.edu.au)

So, yes, I agree that this distinction is valid. But I would like to point out one important issue: For users, the cause of an error is usually not evident: "Was it me or the system?" they wonder. Many users lack the knowledge to identify the cause of the problem. Rarely, they look at the error message – if there was one – or can make head or tail of it... As a result, users typically blame themselves, not the system. This (often wrong) attribution may sometimes lead to hysterical behavior: Users hesitate to touch the keyboard again because they fear they could crash the computer completely or even destroy it. Of course, mostly inexperienced and casual users have these problems – proficient users might laugh at such behavior. But for "stigmatized" users, the fear of errors can become a barrier between them and the computer, effectively preventing them from gaining confidence in using the computer and becoming more proficient. To help these users, developers and designers urgently need to minimize the number of system errors as well as make them less severe (instead of "lethal"). This will definitely be welcomed by proficient users as well...

Conclusion

To sum up, the two statements of Norman's quoted above are right but incomplete. From a user's perspective, system or program errors matter as much as user errors because many users cannot correctly attribute errors to their causes. As a result, users are worried by their tools instead of gaining confidence in them. It is our obligation as developers and designers to help users build confidence.

Originally Published: 02/12/2007 - Last Revision: 01/31/2009 • Also published as SAP Design Guild editorial