Tuesday, September 09, 2008

Epic Fail...Error Message Worst Practices (And How To Fix Them)

Error messages...the bane of users. We all dread the software crash or programmatic wrong turn that sends our productivity crashing into a brick wall. To add insult to injury, I think most of us would be hard pressed to find examples of good error messages in the software we use. Remember that one of the key goals of interface design to strive for is making the interface unobtrusive so that the user can focus on the task at hand, not on how to use the software. When users encounter an error, we are rudely pulling them out of their productive work and bringing the deficiency of our application to the front of their attention. If we can't avoid the situation that brings forth the error, the least we can do is handle it in a graceful and helpful way. Sadly, this concept seems to be the exception rather than the rule. I've often found that it's useful to perform some analysis of applications that fail to meet user expectations in order to learn better ways to do something. Let's look at some examples of error messages gone awry (the worst practices) and then figure out to fix them.

OK...thanks for that

And why, pray tell, am I not?

Eh? I don't speak Klingon.

Oh yeah...System error &H80004005. How stupid of me to forget!

Not only have you offended me sir, but you've scorched my retinas!

If only the girls at school were that easy.

The thing that all of these messages have in common is that they don't result in an action. That is, the best they do (and that is arguable) is tell the user something went wrong, but they don't address the most important part of the whole event..."WHAT SHOULD I DO ABOUT IT?!!!" If you were asked to determine the disposition of this user after encountering such error messages, what would you imagine they would say? Yeah...something along the lines of "Oh crap...here we go again with this piece of $*&@! application!" And you know what, I certainly wouldn't blame them for thinking that! Some errors are certainly worse than others. The most heinous offenders are those that only provide a very technical message that accomplishes nothing but making the user even more anxious.

The error messages that at least provide a "plain English" (or insert your language of choice here) description of the error are better than nothing, but are still not doing things quite right. Another sign of a bad error message is one that does not give any indication of whether the machine/software was at fault of if the error was due to the user's actions (e.g. stack overflow from a numeric calculation vs. user entered text in a number field). All in all, these bad characteristics and worst practices end up making the user feel stupid. Since our work as developers is supposed to be empowering users, then presenting them with less than perfect error messages means we've failed in that task.

So...now that we know what NOT to do, how do we go about fixing the problem? An important aspect of good error messages is that they provide enough information to the user so that he or she is clear about what to do next. The best error messages have some common elements:

*They tell the user what went wrong in plain English and do not make the user feel like they screwed up.

*They avoid technical jargon. If the programmer is the only person that understands the message, it is bad.

*They send an automated report to the developer (see the amazing OpenLog, created by Julian "The Genius" Robichaux. If you're not using OpenLog, you're doing it wrong!)

*Most of all, they tell the user what to do next.

That last point is critical. What the user should do as a next action will depend greatly on your environment, your policies and procedures and the error in question. Maybe it just tells the users to "Press Ctrl-C to copy this error to the clipboard and paste it into a new mail message. Send this message, along with the title of the error, to the help desk". Or it could give the user explicit instructions such as "Enter passcode 4331 into the highlighted field and press the enter key". What really matters is that the user is not left wondering what to do next. The error message should guide them to the next steps. The next action might not fix their problem, but it will at least let the user move on.

Here are a couple of good examples I swiped from the net. These messages address the criteria stated above. Notice the (in)famous Twitter "Fail Whale". No one ever said error messages had to be grey and boring.

I really love this one. It goes into extensive detail on what to do next. Do all of your errors have to be this detailed? No...but in some cases it might help.

The Fail Whale is fun and informative.

Remember that unexpected errors immediately cause users to cease being productive and often make them freak out. By anticipating possible errors and constructing good responses using the elements cited above, you'll be able to minimize the disruption and get the user on their way with the least amount of fuss.

So my call to action for you today is to review the applications you are currently working on. If your custom designed errors are more like the worst practices than the best practices, make it a point to fix them. Make them clear, helpful and actionable. Your users will thank you.


Tony Palmer said...

Yep spot on.

My rules for error messages are;
1) Error Message that a user can understand
2) What the user should do next
3) (optional) Diagnostic reference information which, helps to identify where the error is occurring.

Sometimes, I add a 'reference' message, that provides a little more (technical) information so that the problem can be identified and fixed. It is always after the action, so that the end user will generally ignore it. It's a trade off between a clean message and getting to the bottom of a problem faster.

Michelle said...

One thing I learned a few years ago was not to call field validation failures 'Errors'. I had one user get quite irate because she felt the system was blaming her.

So now my applications have 'Incorrect Data' or 'System Encountered a Problem' but rarely 'Error'

And yes - any code related errors go straight into OpenLog.

Anonymous said...

If you're missing seeing the Fail Whale on twitter these days because of improved performance, you can always install Random Whale a Firefox extension.