Writing Effective Error Messages
- Reconsider the need for the message
The vast majority of user errors occur because the programmer allowed the error to occur. Most error messages therefore, can be eliminated by reducing the possibility of errors:
- make sure that number fields only accept numbers
- provide lists wherever possible
- provide file selection dialogs rather than asking users to type filenames
- provide default values wherever possible; they not only speed the user's task, they let the user know the expected form of the input
Prevention of errors requires that the designer anticipate the potential mistakes the user is likely to make. This is often the most difficult aspect of designing an effective user interface, since the designer's familiarity and knowledge of the program interferes with his or her ability to view the program as a novice might.
Before you decide to interrupt the user and demand a response, make sure you have exhausted all methods of preventing the error from occurring.
Never assume that the user has the same knowledge of computers that you do. While you may be comfortable with such expressions as "File Specification Error", and "Unable to establish network connection", it is less likely that new users will understand such terms.
Try to write you messages in terms that will assist the new user in understanding the problem. One method that helps us write effective messages is to imagine that they are going to be read by our mothers or grandmothers. For some programmers, it might also help to imagine that the message needs to be understood by the president of your company. If the president of your company and your grandmother can both understand the message, then it's likely that your users will also.
Your application is supposed to cooperate with the user, helping him or her to complete some task. Using exclamation points in your messages, either in the title, the message, or the message icon, transforms your program from a cooperative partner to a pompous, arrogant ass.
The exclamation point icon should never be used in a message. It is instantly interpreted as shouting. It is the desktop equivalent of posting a forum or usenet message in all capitals. While your intent might be to alert the user that an error has occurred, the fact that a message is displayed at all has already alerted the user. The question icon or the information icon can enhance the visual quality of the message, without making your program appear arrogant.
The term 'error message' is relevant only to the programmer; it has no equivalent in our day-to-day interactions with other people. If you have forgotten to endorse a check, the bank teller does not shout, "Fatal Error! You've made a mistake." He or she simply asks you to endorse the check.
'Error' has strong negative connotations, usually because it has erroneously come to mean that the user has done something wrong. It adds nothing to the interaction between the computer and user, and can only decrease the spirit of cooperation between the user and the computer.
One method to reduce ambiguity in error messages is to phrase the message as a question that can be answered with a simple 'Yes' or 'No'. Compare the following messages:
Years of computer experience tend to make it difficult for programmers to understand that new users would have difficulty understanding the choices provided by the first message. The second message provides choices that are more readily understood by new users: 'Yes, allow me to select a different printer', and 'No, don't print the document.'
The title of the message box should be the name of the application that produced the message. As engaging as your program may be, it is likely that the user will have other programs running at the same time. By providing the application's title, the user is instantly aware of which program caused the error.
© 1996-2000 Isys Information Architects Inc. All rights reserved.
Reproduction in whole or in part in any form or medium without express written permission is prohibited.
GP designpartners provide this mirror — for educational purposes only — as the interface hall of shame is no longer maintained or available at its original home, www.iarchitect.com [a domain apparently abandoned and taken over by a search spammer ...].
you can view this file in its original layout: hterror.htm.
please drop us a line if you happen to know anything about the whereabouts of brian c hayes of isys information architects, the author of this »interface hall of shame« [and fame].