Avoid Being Embarrassed by Your Error Messages

By Caroline Jarrett

Published: August 9, 2010

“People make mistakes and computers do unexpected things. We try to design out the errors as much as possible, but inevitably, we end up dealing with error messages.”

Put a person and a computer together, and you have the possibility of an error. Put two computers together: more possibilities for error. People make mistakes and computers do unexpected things. We try to design out the errors as much as possible, but inevitably, we end up dealing with error messages. It’s easy to find plenty of recommendations about creating error messages. For example, Rhonda Bracey gave this succinct advice in her UXmatters article “Reviewing User Interfaces”:

“Good error messages tell users what went wrong—and possibly why—provide one or more solutions for fixing the error, and offer a set of buttons that relate directly to the next action a user should take.”—Rhonda Bracey

So how did an error message make it to Top Tweet status on Twitter recently?

“An unknown error message ‘APIEpicFAIL’ was received from the device” (with the only option available: click an “OK” button).

When Duncan Campbell (@dunk) tweeted about this message, he commented sarcastically: “Could this be the best Apple error message ever?” It clearly fails all of Rhonda’s recommendations.

Turning the Error Message into Plain Language

If you understood what that error message was trying to say, please skip to “Providing Helpful Error Messages.”

For everyone else, here’s what I think it means. (Years ago, I was a software engineer, working on communications protocols, so I’m going to have a crack at dissecting this one, at the risk of exposing how little I know about it today.)

The computer that displayed the error message, which I’ll call the first computer, was trying to talk to some other device with a computer in it—most likely an iPhone. That is the device to which the message refers. A programmer has anticipated that the device might not always work as expected and has listed anticipated problems. Unfortunately, the device has itself sent an error message back to the first computer, but it’s not on that list of anticipated problems, so the programmer hasn’t written any code to handle the problem, apart from showing the poor user this useless error message.

Putting the message in plain language: “Something has happened that I didn’t program an error message for. Sorry.”

Providing Helpful Error Messages

To ensure your user interfaces don’t make the mistake of displaying such cryptic error messages, here are some guidelines for providing helpful error messages.

Make sure your error messages cover unexpected problems.

“Assign a unique error code to each can’t-ever-happen error case. Then include a last-gasp error message—for something that should never happen, but just might.”

The real world is always messier than we expect it to be. When you offer users a list of predefined answers they can select, I urge you to include Other as a possible option—with a text box that lets users explain what Other means. If your list of anticipated options is perfect, no harm is done and nobody selects Other. But if your list of anticipated options happens to miss out a bit of messy reality, you’ll rapidly discover what you’ve missed from the way people fill out the Other box.

The same goes for computing devices—or indeed, anything else with lists that have even the slimmest possibility of not being comprehensive. Assign a unique error code to each can’t-ever-happen error case. Then include a last-gasp error message—for something that should never happen, but just might.

Its wording could be along these lines: “Unexpected error. We didn’t think you’d ever see this message, but you have. Please contact us and give us this error code: [Error Code].”

Give users some hint about what to do next.

At least try to give users some hint about what to do next.”

Rhonda’s advice includes telling the user what to do about an error. If you believe your can’t-ever-happen error message would appear rarely enough, why not put your direct phone number into it? Does doing that make you feel too uncomfortable? How about your email address? Or maybe the contact details for your help desk?

I realize all of these suggestions might seem ridiculously utopian, but this error message was never supposed to appear, so the traffic it generates shouldn’t be all that bad, should it?

If these arguments fail to convince you, at least try to give users some hint about what to do next, such as: Please try again, switch everything off and on again, jiggle the plug, uninstall the software, or whatever.

Not sure if this will work in practice? Here’s an example of where it did work. James Dyson contributed this advice to a discussion on the STC UUX list:

“We recently changed how we handled error messages, and the changes received a lot of positive feedback. Instead of telling users what is wrong, we told them how to fix it. For example, we used to display the error message ‘Low Voltage Error.’ Now we display ‘Check Power Cable.’ We had character limits, but you get the idea. This approach reduced support calls and certainly improved user confidence.”—James Dyson

Provide buttons that offer appropriate actions.

“It’s not OK, and I don’t want to Cancel.”

I do a lot of presentations about how to design forms. When I discuss buttons in error message boxes, I put up a slide that says: “It’s not OK, and I don’t want to Cancel.”

I’m not alone. Gerry McGovern’s blog post “Why Does the OK Button Say OK? includes this:

“Most times I come across the OK button, something not-OK has happened. It's like my cat coming into our kitchen and saying. ‘Hello Gerry. Just wanted to let you know I did a pee in the sitting room. OK.’ Well, sorry, it's not OK.”

As Rhonda points out, “Offer a set of buttons that relate directly to the next action a user should take.”

If all a user can do at this point is close the error message box, label the button with what it does: “Close this message.”

If there is anything a user can do that will improve the situation, offer a clearly labeled button or buttons that will send them on their way to that work.

Write your message in plain language—like a human talking to another human.

“You’re going to display your error message to a person, so write it in the tone of voice you would use if you were telling the error message to the person directly.”

You’re going to display your error message to a person, so write it in the tone of voice you would use if you were telling the error message to the person directly. What is appropriate to your brand and the users you expect to be working with?

Avoid jargon like invalid code, unrecognized field, mandatory—and device.
If you are not clear on what people might see as jargon, try out the text on a person who doesn’t design or develop technology.

Or, if that is impossible, you can get a sense of what words might be familiar to nontechnical people from a tool such as the Vocabulary Profiler, an online checker that tells you whether your text is among the most common 1000 words in English, the next most common 1000 words, from academic language, or is unfamiliar to most people. The Vocabulary Profiler strikes me as ugly—and, ironically, its user interface is full of jargon—but it’s also quick, effective, and free.

Think about error messages as part of a conversation with users.

“Underlying all of this advice: the concept of error messages being part of a conversation with your users.”

In her book Letting Go of the Words, Ginny Redish says, “Think of the Web as a conversation started by a busy Web user.” Underlying all of this advice: the concept of error messages being part of a conversation with your users.

Do you want your error messages to be part of a productive, continuing conversation between your organization and your users? Or do you want your error messages to be the subject of a mocking conversation on Twitter, with your users tweeting them to their friends and followers? That’s the choice.

8 Comments

Excellent article, Caroline, thanks!

David Farbey

Good article. I didn’t know about Vocabulary Profiler. I have to check this out. We all know that terminology is a huge factor in the user experience.

The only thing I feel that needs mentioning is: don’t just write good error messages, track them. Use some form of analytics to see where the pain points in the site/application are. Of course, that’s a whole topic in and of itself and shouldn’t be discussed in detail in this post, but mentioning this—like in a sidebar or something—is probably worthwhile.

BTW—it’s a shameless yet relevant plug—I just wrote about error message usability myself: “Error Messages: Greater Detail for the Greater Good.”

Hallo Caroline,

Great post. I especially like the bit that says error messages are part of a productive, continuing conversation. Error messages as social tools! :)

Cheers, Sarah

@dfarb, @sarahmaddox: thanks

@Joebaz: good extra tip, thanks. And I enjoyed your article, too: perhaps error messages are going to be this month’s topic in general.

Nice article, Caroline. I had a few thoughts—one reason to not post a private phone number or email even for an outlier use case is—someone might tweet it or disseminate it some other way. Just as you can’t always predict every error scenario, you also can’t predict what people will do with your information. ;)

I also blogged about this topic awhile back—in “Cute error messages are not any more usable“—specifically regarding the issue of using natural language and the current trend to use “cute” natural language. My point was just that the use of cute natural language—like “oops!”—doesn’t make up for the fact that the user still hasn’t been able to accomplish their goal, and it should still include those core items you identify—what happened and how can I fix it?

@jamie

You’re right about the dissemination of personal information. That’s sort of why I put “direct phone number”—I was thinking in terms of a person working in a corporate environment.

I realized that the direct phone number bit would likely be an uncomfortable suggestion, and I wasn’t being entirely serious about it. It was really a suggestion to be a bit provocative, to challenge people about how truly unlikely the error circumstance might be.

And also to help to bring in the notion of a real conversation: that, as designers, writers, or programmers, we need to think in terms of being real humans who are writing for other real humans.

I enjoyed your piece on error messages; thanks for the link.

Caroline Jarrett

Twitter: @cjforms

I agree that paying attention to error messages is a very important way of improving visitor experience.

I think it’s very wise to track the error messages in your Web analytics system—for example, use virtual pageviews or events in Google Analytics. That way, you can get an idea of how often the messages are being seen, which might be interpreted as an indication of how bad an experience your visitors are having. You can also establish a benchmark for how often these error messages result in an exit from the site. And then try to improve things!

Tim:

Thanks for that great suggestion.

Best Caroline

Join the Discussion

Asterisks (*) indicate required information.