It goes without saying that an important goal of user interface and user experience design is to minimize the chances that users will encounter errors. Nonetheless, as the saying goes, “stuff happens”. There will always be a need to help users identify, understand and recover from error conditions. I find that error handling is often the source of great user frustration, and a very common source of abandonment. “I’d probably give up at this point” is a phrase I hear a lot in user testing sessions when users can’t quickly and easily diagnose and correct an error. When users encounter a problem they’re in need of reassurance and guidance, so it’s not surprising that when they don’t get it they often become frustrated, irate, and/or willing to give up.
The good news is that it’s possible to avoid many of the worst-case abandonment scenarios caused by poor error handling. In part 1 we discussed helping users identify when they’ve encountered an error (it’s sometimes more nuanced than you might think). Here in part 2 we’ll concern ourselves with communicating clearly about the nature of the error and helping users resolve the problem.
What really had happened was…
For many users encountering an error is disorienting. I don’t mean dragged-backwards-through-a-car-wash-with-a-bag-over-your-head disorienting*, but it’s often at least mildly confusing. I’ve pointed out before that usability problems tend to have a cumulative effect, so it’s important to consider even the small usability barriers.
To minimize this effect it’s important to orient users to the nature of the problem. Ideally error messages should always be:
- Clear – it should go without saying that error messages must be easily understandable. It’s important to avoid industry or technology-specific jargon, excessive abbreviations, and any other language that might not be understood by the audience. As I pointed out in a different article, it’s common for members of a software or web design team to make too many assumptions about what theirs users will understand.
- Specific and descriptive – in most cases errors should be as specific as possible. “Sorry, you can’t do that” and “Not a valid entry” are vague messages and likely to cause confusion and/or frustration. By contrast, “Sorry, we need your email address” is very specific and can’t be easily misunderstood. Of course there are some exceptions to this rule. For example in a scenario where you’re explaining that a user’s credit card has been declined, it’s preferable for security reasons not to explain too much (would-be credit card thieves can use detailed feedback like this to help them validate stolen card numbers).
- Concise – brevity is most definitely the soul of good error messages. Yes, the goal is to communicate clearly. But you also need to get right to the point in as few words as you reasonably can. In the context of selling an airline ticket, a message like “Sorry, the number of seats requested exceeds the number of seats currently available for the selected flights” might be clear and specific but it’s far too many words. “Sorry, that flight has been sold out” is more concise.
- Helpful – recommend a course of action that will resolve the problem. In the most obvious cases it’s enough to explain what happened and why. But often it’s helpful to point users in the right direction to help them resolve the problem. For example, “We need your email address” is probably an adequate error message if it appears right next to the email address field. But if your layout demands that the message appear at the top of the page, far away from the relevant field – then you should also explain exactly what the user needs to do. In this example, adding “Please enter your email in the field below” would communicate how the user should correct the problem. Going back to a previous example it’s probably not enough to simply indicate “That flight has been sold out”. It will also be useful to add something to the effect of, “Please select a different flight from the choices on this page, or start a new search.”
The closer your error message is to embodying these elements the more likely it is to reassure users and help to solve the problem.
I’ll learn you!
A related and useful element to consider employing in some error messages is a link to “learn more”, as in the following example:
Sometimes the causes of an error can be complex, or can be due to one of many possibilities. Since we want the message to be concise, in these situations it’s often best to summarize and then offer a “learn more” (or “more info” or similar) link so that users who need additional help and information can get it, but those who just want the quickest way forward can find it without hassle. A word of warning though: if you’re going to offer a “learn more” link that displays some type of additional information and/or online help, be sure it’s actually helpful.
To err is human; to improve divine…
Consider reviewing your website or application errors from top to bottom and seeing how well they stack up to these attributes. Make improvements where you see shortcomings. Your users will thank you. Not only that, you’ll increase user satisfaction – and if you’re running a transactional website most likely you’ll improve conversion as well. Skeptical that better error messages can improve conversion? Check out this recent article on that very topic.
* This amusing phrase was coined by musician Thomas Dolby many years ago to describe the experience of his live show. I saw him play live in 1984 and I found it to be considerably more enjoyable than his description might lead you to expect.
Photo credit: “Amnesia” by cesarastudillo. Creative Commons licensed.
Related posts:
{ 1 trackback }
{ 0 comments… add one now }