Avoid Being Embarrassed by Your Error Messages

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.

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. 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.

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.