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: “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.”
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 Bracey’s recommendations.
Turn 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.”
Provide 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 that your error messages cover unexpected problems
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
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 realise 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.”
Step away from ‘OK’ and ‘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’ recently said 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.”
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 labelled button or buttons that will send them on their way to that work.
Write your messages 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, unrecognised 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 non-technical 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 organisation 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.
Image, Step away from the keyboard by Niall Kennedy, creative commons
Image, Firefox error message, by i.a. walsh, creative commons