Error messages are displayed by applications in response to unusual or exceptional conditions that can’t be rectified within the application itself.
The need for “useful error messages” can be defined, in the simplistic case, to be a need for some form of error handling and reporting that enables the user to understand what has happened in the case of an error and what must be done to remedy the situation.
Most testers are no doubt familiar with the feeling of reluctance to log usability issues, fearing that they could be misunderstanding the functionality or they are “wasting valuable time reporting trivial bugs”. The project team can further drive this feeling by tending to postpone or ignore such issues under the premise that “at least there is some feedback isn’t there?”, or “there isn’t going to be time to address those kind of issues”, and besides “the user wouldn’t do that.”
Issues with Error Messages
“Error messages are often less than helpful or useful because they’re written by people who have an intimate knowledge of the program. Those people often fail to recognize that the program will be run by other people, who don’t have that knowledge.” Michael Bolton, 1999.
Furthermore, Byron Reeves and Clifford Nass suggest in ‘The Media Equation’, that even text-only interfaces are felt by users as having some “personality” and that “people respond socially and naturally to media.”
As noted by Julianne Chatelaine in ‘Polite, Personable Error Messages’, Byron Reeves and Clifford Nass determined that if the application does not have the ability to assess each user’s personality and adapt to it, the next best thing is to select one personality or tone and be consistent to avoid contributing to confusion and even dislike. The published TME findings were underscored by Nass’ remarks at UPA ’97 where he said that when an application’s textual messages were written by a variety of different people, using different styles and degrees of strength or dominance, it made the product seem “psychotic.”
Guidelines for Error Messages
“You may design the perfect system but eventually, your system will fail. How it does so, however, can make all the difference in the world in terms of usability.” Tristan Louis, ‘Usability 101: Errors’.
“The guidelines for creating effective error messages have been the same for 20 years.” Jakob Nielsen, ‘Error Message Guidelines’.
The following checklist, compiled from several of the referenced sources, will help you confirm that your application meets basic usability requirements with respect to error messages.
- Message Exists: the problem with an error is often that no message is actually attached to it. Notify the user when the error happens, every time it happens. The error may be due to a flaw in the software or a flaw in the way the user is using the software but if the user doesn’t know of the error, they will assume that the problem is with the software.
- Polite Phrasing: the message should not blame users or imply that they are either stupid or doing something wrong, such as “illegal command.”
- Visible and Human-readable: the message should be highly noticeable and expressed clearly in plain language using words, phrases, and concepts familiar to the user rather than in system-related terms.
- Precise Descriptions: the message should identify the application that is posting the error and alert the user to the specific problem, rather than a vague generality such as “syntax error”.
- Clear Next Steps: error messages should provide clear solution steps and/or exit points. An application should never capture users in situations that have no visible or reasonable escape.
- Consistent: users should not have to wonder whether words, icons, colours, or choices mean the same thing or not in different instances.
- Helpful: the message should provide some specific indications as to how the problem may be resolved and if possible let users pick from a small list of possible solutions. Links can also be used to connect a concise error message to a page with additional background material or a detailed explanation of the problem and possible solutions. Finally the message should provide extra information, such as an identifying code, so that if technical support is helping the end-user they can better analyze and remedy the problem.
Error Message Presentation
When deciding on the style your error messages will adhere to, you should consider the presentation of your error message:
- Tone: be firm and authoritative, stating the facts of the situation in a neutral and business-like manner.
- Colour: an error message printed in red may call attention to itself, but to use colour solely as the way to present an error message is generally a poor idea. People that are colour blind for example will not read the text with any additional meaning attached to it.
- Language: if your application is used by people in different countries, consider that your error messages will have to be translated and need to be presented in a format flexible enough to accommodate the translated text.
- Icons: if you use icons to present your error messages make sure they are intuitive to the end-users and that they are appropriate to the circumstance of the error message.
To highlight how careful you should be when considering icons, Tristan Louis cites in ‘Usability 101: Errors’, the case of when an Apple Macintosh crashed, it used to show an icon presenting a little bomb with a burning fuse along with the message in the error dialog. He comments that users in many countries were terrified by this icon and would not touch the computer for fear that it would actually explode.
Summary
Remember that errors will happen but what will make all the difference is if they are handled properly. Unclear and unhelpful error messages tend to mean that errors will recur, or take longer to resolve. The resultant frustration can lead users to mistrust the interface or even abort the task in question.
Your error message must convey useful information — useful information saves time and for more than just the end-user. The message will also need to be understood by and useful to the technical support person who handles the call, the quality assurance analyst who helps to track down or replicate the problem, and the maintenance programmer who is charged with fixing the problem in the code. Each person in this process represents a cost to your company, cost that could be greatly mitigated by a small investment made now.
