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