Jakob Nielsen's Alertbox, June 24, 2001:

Error Message Guidelines

Summary:
Established wisdom holds that good error messages are polite, precise, and constructive. The Web brings a few new guidelines: Make error messages clearly visible, reduce the work required to fix the problem, and educate users along the way.

The guidelines for creating effective error messages have been the same for 20 years. Good error message should include:

• Explicit indication that something has gone wrong. The very worst error messages are those that don't exist. When users make mistakes and get no feedback, they're completely lost. Email, for example, offers several situations where explicit indication would be useful. Such as: When you send a message that gets eaten by the system and never reaches the recipient. Another good example? When you state in an email that you'll include an attachment, but forget to do so. Finally a job for that annoying paperclip: "You seem to want to attach a file to this message, but you have not done so. Would you like to attach one now?"
• Human-readable language, instead of obscure codes or abbreviations such as "an error of type 2 has occurred."
• Polite phrasing that doesn't blame users or imply that they are either stupid or doing something wrong, as in "illegal command."
• Precise descriptions of exact problems, rather than vague generalities such as "syntax error."
• Constructive advice on how to fix the problem. For example, instead of saying "out of stock," your error message should either tell users when the product will be available or provide a way for users to ask to be notified when the product is restocked.

The Web's most common error message, 404, violates most of these guidelines. I recommend that you write a custom 404 error message instead of relying on the server's built-in "page not found" message.

New Guidelines

The complexity of Web pages has introduced the need for a guideline that wasn't required in the old days. With a DOS interface, users type a command and the error message is displayed on the next line of the TTY. In modern GUIs, users click a command and the error message is displayed in a big dialog box in the middle of the screen, and it doesn't go away until users acknowledge it. On the Web, however, error messages are often hidden as modest text on an overloaded page, leading to a new guideline: Error messages should be

• Visible and highly noticeable, both in terms of the message itself and how it indicates which dialogue element users must repair.

I have frequently observed users make a mistake in a Web form, only to get exactly the same form back from the server with no visible indication of what went wrong. Often, a small error message appeared on the top of the page, but since users look at the page's actionable part first (i.e., the area with the form fields), they don't typically notice the error.

A related design flaw is to indicate an error state solely by turning the field label red. This violates one of the oldest and simplest rules for making technology accessible to users with disabilities: Never use color as the only encoding mechanism; always include redundant cues that color-blind users can see.

Two other guidelines can make the error situation less unpleasant for users:

• Preserve as much as the user's work as possible. Let users correct errors by editing their original action instead of having to do everything over again. For example, in presenting search results, show a search box with the user's original query terms to facilitate revisions. If no hits were found, let users search a wider scope with a single click.
• Reduce the work of correcting the error. If possible, guess the correct action and let users pick it from a small list of fixes. For example, instead of just saying "city and zip code don't match," let users click on a button for the city that matches the zip code they entered.

Opportunity to Educate Users

Finally, you probably already know Nielsen's First Law of Computer Documentation: people don't read it. This finding is even stronger for websites, where users truly shy away from any reading that is not essential to their task. Click on Help? Never.

Users read system documentation only when they are in trouble (that's the Second Law). They are particularly attentive when they want to recover from an error. Given this, you can use error messages as an educational resource to impart a small amount of knowledge to users. Of course, error messages should be brief and to the point, as should all Web content. However, error messages can still teach users a bit about how the system works and give them information they need to use it better. To further that end, the Web's underlying technology makes another guideline possible:

• Hypertext links can be used to connect a concise error message to a page with additional background material or an explanation of the problem. (Don't overdo this, though.)

Learn More

Full-day tutorials with much more detailed guidelines for application design at the Usability Week 2008 conference in New York, San Francisco, London, and Melbourne:

• Application Usability 1: Page-Level Building Blocks for Feature Design
• Application Usability 2: Dialogue and Workflow Design