Error messages are a constant source of frustration to users of all skill levels. A recent example is Don Norman’s rant Error Message Are Evil (sic) on LinkedIn, where he insists that error messages must start collaborating with the users, and that software needs to become better at anticipating and accommodating actual user behavior. As someone who is often tasked with the writing and rewriting of error messages, it’s hard not to agree.
(Image by martinak15 on Flickr)
Here are the three most common unhelpful types of error messages that I know of, and what makes them unbearably annoying to me.
1. Written for the developers: Object reference not set to an instance of an object
Of all error messages that should not go out to end users, this example is probably my least favorite. Someone really should just change the standard nullpointerexception error with something more readable to a user, once and for all. “Developer malfunction”, perhaps. I kid, but only just. And there are many more messages that follow a similar logic.
All too often, internal error messages trickle out to users from frameworks, APIs, or deep dark places in code that nobody every intended to expose. They are usually hardcoded and hold no information that the user can make sense of, or wrap a tiny piece of readable information in noise. Typically, they also use words like “illegal”, making any normal person think a crime has been committed, rather than the use of a character that couldn’t be parsed.
2. Well, duh: Unexpected error
Ohhhh, so you didn’t see this one coming, application? Well, that’s helpful for me as a user to know. And now what?
The literal “Unexpected error” is quite common, but there are tons of messages out there that are at about the same level of helpfulness once you’ve read them. Telling the user at least something they don’t already know is a very basic criterion for an error message. And they probably don’t care whether or not you were expecting it, but they do care whether it will fix itself or requires intervention.
3. Intended to be funny: Well, this is embarrassing
The example is from Firefox being unable to open a page, but Chrome’s “He’s dead, Jim”, or the Twitter whale, are more of the same, and the trend has been spreading, perhaps due to advice like this post from UXmas: The 4 H’s of Writing Error Messages, where “humorous” is one of the H’s, as the author claims it helps diffuse frustration. I disagree–and actually even the UXmas author himself goes on to warn that humor is not appropriate in most actual error situations.
Cutesy, chummy, intended-to-be-funny error messages may serve that purpose the first time the users see them. But error situations have a way of repeating themselves. The tenth time you get to the same error, the funny, “friendly”, conversational error message style is likely to have grown on you much like a fungus. There’s a reason there are tutorials for Getting Rid Of Firefox’s “Well, This Is Embarrassing” Message.
Being helpful is about being respectful to the user. Error messages should be troubleshooting assistants for users, not their pals. An actual pal might buy the user a drink when the operation fails for the 15th time, the error message will still just say the same thing.
Helpful error messages are hard (to write)
Users are annoyed when something fails. We don’t want to feel like we did something wrong, or like we spent our time, money, or both on a product or service that isn’t up to the job.
Writing helpful error messages is hard, but probably one of the best possible uses of a technical communicator’s time. I will share my own concrete advice for helpful error messages in a new post shortly.
Which error messages are most annoying to you? Do you enjoy the use of humor?