By Scott Berkun, September 2000

Nothing says more about what you think of your users than error messages. The moment things go wrong is the moment users need you most. Software products, including some Microsoft products, have developed bad reputations for cryptic error messages that are hard to understand or resolve. What’s alarming is that Web site user interfaces are just as bad, or worse, in their handling of problem situations. We’ve taken a step backward in the baseline for acceptable treatment of our customers. Here’s a short guide for handling errors well, on the Web or in Windows.

Software Engineering and Error Handling

An engineer who designs the superstructure for a bridge or the frame of an automobile invests time in understanding how things will break. That’s part of what defines real engineers: the ability to see the potential flaws in any design, and build objects with additional support for those flaws in mind. Similarly, writing code for a feature must include understanding the most important error cases and engineering code to support those cases robustly. Particular importance should be placed on the errors that users experience, and how they will experience them. A small memory leak or a two-second server delay may mean a lot to you, but having to retype information or click Refresh several times impacts the user directly, and should be more important. Error messages and handling should be thought of as a required part of any feature, and proper engineering time for error support should be budgeted into any development estimates or project schedules.

Letting Users Down or Saving the Day

When a user sees your error message, the Web site or product has let them down. They’re trying to read their e-mail, or publish their Web page, and for some reason it’s not working. If the user is late for a meeting, or working under pressure, the inability to complete a task could be disastrous. Like 911 operators or emergency room doctors, you have a chance to deliver a solution to an urgent problem. Error UI should be conceived just like other parts of the UIódesigned with the intent to shorten the distance between the user’s goal and the completion of that goal.

What follows is a simple system for categorizing the quality of error messages and error support. It’s inclusive, meaning that level 4, the highest level of quality, includes all of the attributes of the levels beneath it. (This is based on work by Walter Smith and Piero Sierra from the Microsoft WindowsÆ UI team.) It should help you in thinking about the quality of your current error support and give you some metrics for measuring success. Just like any other UI, you never know where you’re at unless you’re regularly usability-testing your designs as you develop parts of the project. So don’t rely on this alone.

Level 1: Make Errors Uniquely Identifiable

If you can’t do anything else, at least make your error cases unique. When your support staff receives a complaint or a request for help, they can determine precisely what is causing the problem and develop a specific remedy for it. Generic errors, or different error situations that return identical messages to users, are easier to implement, but generally useless. Unique ID codes allow for better tracking of issues and overall product quality. Then, when you plan your next release, you’ll have data about the number of times a given error occurred and you’ll be able to confidently decide which ones to eliminate or improve. But remember that error codes are meaningless to users. They should be visible, but not prominent in the error message. With unique identifiers in place, you’re setting the stage for a more robust error API or error-handling system.

Level 2: Keep Data Safe and Keep Users Calm

Web sites use different techniques for storing user data when navigating to different pages. Regardless of the technology used, always make sure that any information a user has typed in is saved so they don’t have to type it in again. If a user leaves out a field, or mistypes their area code, don’t treat it as a catastrophe: Subtle errors deserve subtle messages. Indicate on the form itself where the problem was, and keep everything else intact. This is especially important for long, tedious forms that require a lot of effort and mouse movement to fill out. In the case of registration information, requiring users to type in stuff twice may be enough to make them go somewhere else.

Level 3: Good Errors Are Clear and Have Paths to Remedies

When a user is interrupted from a task by an error, you have to set the right tone. The way they are thinking about the error is always very different from the way you, as the developer, think about the error. They may know almost nothing about how things work, are not expecting an error to occur, and are probably concerned about whatever it was they were trying to accomplish. You should always come at UI design from the user’s perspective, especially in error or crisis situations. Here are the four attributes of good error messages:

1. Describe the problem in consumer terms and language.
2. Give directions for how to complete the task and resolve the problem.
3. If possible, explain how to prevent the situation next time.
4. Avoid obscure technical jargon, abbreviations, or acronyms.

Errors should always carry a tone of responsibility. If the user couldn’t figure out your UI without making a mistake, it’s your fault, not theirs. Choose language that is supportive and polite, like a good waiter or salesperson would do. If there are underlying concepts that are relevant, provide links to them (but don’t obscure the simple solutions to the immediate problem). When giving solutions, provide clear instructions for how to resolve the problem. Be as direct and specific as possible, without assuming too many concepts. If possible, go beyond instructions and actually provide a link or a button that does the action. If it’s a severe problemófor example, the Web site is undergoing maintenance or is overloadedóprovide some mechanism for the user to report the problem to you, so you at least have a record of how many people suffered the problem and can use that in planning for the next release.

Level 4: The Best Errors Are Never Seen by Users

If you write solid code, and build robust support for error handling, the most common or severe errors are never even encountered by the user. This can be achieved by automating parts of the user interaction, intelligently offering alternatives to common mistakes users make, or by refining the UI to reduce the frequency with which users get into certain error-prone situations. Great engineers forgo the error messages, and just solve the problems directly. It’s often impossible to do this for all cases, but if you have information from your support team for the top ten most common errors, you can invest your time there.

---

Scott’s first book, the art of project management, will be published by O’Reilly in April of 2005.