Covering every aspect of dealing well with error conditions could take a whole book. What I want to talk about specifically is the information that you pass on to your user when an error occurs. Here are some rules you should follow for error pages and dialogs:

• Never show your users error codes - ever
• Pass error information to technical support without user involvement - when acceptable, solve errors proactively. Make it so you can easily correlate the error with the human user that was affected
• Exceptions, stack traces and HTTP error statuses are just another form of error code - keep them tucked away
• Take care in crafting your error messages - not too much or too little information, all the relevant information
• Be friendly, humble and apologetic - you screwed up, not the user
• Make error messages actionable - empower your user with the next step they should take
• If you absolutely must show an error code, tell the user why and what they need to do with it

Provide users with all the relevant information and tell them what action they should be taking next.  Users are usually pretty understanding of errors if you let them know exactly what happened, why it happened, and what they should do about it. The two biggest sources of frustration to a user in the face of an error are, “I don’t know what to do now” or “I would know what to do now but I don’t have the information.”

What I’d like to do now is play a little Extreme Makeover: Error Page Edition.

The first contestant is my friendly neighborhood bank, Wachovia. Nothing like kicking a company while they are down. Like most banks, Wachovia provides online banking services to their customers, and like most banks, these services are essentially web front ends to a mainframe. The thing about mainframes is they predate our online, real-time, 24/7 world, so many mornings when I get up at 4 AM EST, many of the services Wachovia offers to me online are not available. My morning error page comes with an amusing and ever changing variety of error codes. To Wachovia’s credit, these services have a good track record for me of being up by 6 or 7 AM and the English in their error message is rather helpful. By applying the rules above it can be better.

The error page is already friendly and actionable. This is a good first step and is more than we’ve come to expect from most error pages. It would be better if Wachovia wasn’t so stingy with information, if they made it clear why they are providing the error code and what should be done with it, and if they recognized that it is an inconvenience (”this inconvenience”) versus just a potential inconvenience (”any inconvenience”).

The next step for Wachovia would be getting rid of the error code. They presumably provide the error code so the user can pass it along to the customer service representative on the phone (I’ve been asked by Wachovia for the error code before). But it’s a bank and I’m logged in. They know who I am! Their systems should be making that information available to customer service representatives that need it without me needing to relay it to them. Even better, send me an email when the situation is resolved saying, “We’re sorry about the error that occurred while you were on our online banking site this morning, the problem has been fixed and you can access the service now.”

Next I’d like to makeover a company many consider to be the world’s top super model. Apple. Sacrilege? Not everything coming out of Cupertino smells of roses and gumdrops. Take the Time Machine (Mac OS X’s backup system) error dialog that unfortunately every Time Machine user has seen too many times. Apple does a good job following many of our rules, there are no error codes for example. Yet this dialog is immensely frustrating because it provides no meaningful information. What are you supposed to do now?

Making over this dialog is a matter of providing the user with more of the information that Time Machine obviously has, so the user can make an informed decision about what to do next.

The new dialog could be furthered improved with a link to information on how to fix the permission problem.

No matter how polished and foolproof you think your product is (and most of us think our products are mostly bubblegum and bailing wire), there will come a time when a user encounters an error. These are the times that try our product’s soul. The product’s response in the face of errors can make a good product great or a great product crumble.

Butterfly Error Dialog photo by schoschie