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.
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.
Which error messages are most annoying to you? Do you enjoy the use of humor?
9 replies on “The Three Most Annoying And Least Helpful Types Of Error Messages”
We decided that empathetic and helpful were much more valuable to the customer, and much easier to get right, than humor, which is by its very nature context-dependent (ask any comic working a dead room at a Lake Tahoe casino!).
There are a very few writers who have the knack for being funny without being annoying, you should pay those writers a lot of money, give them an office, and encourage them to follow their instincts. Those writers are incredibly rare. The rest of us normals can do wonderful things with empathy (not cloying), and as you point out, providing at least a hint as to the next step.
One exception is api errors, which are meant to be short and consumed by other processes, not people. UI error messages, however, should be written from the *customer’s POV* as much as possible.
It’s the difference between a Dad who says, unhelpfully, “Oh hey, son, you fell off that bike!” and one who says, “Looks like you couldn’t recover after hitting the curb. Here’s how I avoid the curb when turning blind corners.”
I sometimes think all content in an app should just be dynamic, that we’re past the age of waving our hands and guessing. Imagine if, in an error situation, a little app window opened up and said, “You hit the save button, but I didn’t get your data. Do you want help?” and then did something smart. Since a single error condition may be caused by hundreds or thousands of conditions, contexts, and actions, it seems silly to keep pretending a single error message will help the customer in most cases.
Oops, sorry, looks like I just repeated ideas from Don Norman’s post. For some reason (typical user!), I skipped all the intro text above the image. Doh!
Not at all, we both seem to mostly agree with Norman, but I really enjoy getting other tech writers’ take on this. The perspective is different.
The thing about those API errors that are only intended to be consumed by processes, is that I have seen more than one of those bubble up to the surface. More than five, too. The only thing that is less likely than their being helpful, is their being internationalized.
My former colleague Remco shared this wonderful collection of “classic” error messages on Twitter: http://t.co/HdjECQsmBK
Microsoft’s error messages usually drive me mad. Here’s a recent example:
“We cannot sign you up for the Microsoft Update service because there is a problem with the service.” – Really? A problem? How inconvenient…
But the one thing that makes me call for Redmond’s blood is the fact that usually you cannot select and copy the text in MS’s error messages*. When my software has spat out an incomprehensible or vague error message, I turn to the Web to find a solution (or, failing that, to find the company of others who have struggled with the same problem).
*Apparently this may be possible, according to Lifehacker, though I tested it with a ‘File not found’ message, and it didn’t work.
Please MS, please, just let us use the cursor and give us access to the text on the screen.
VMC
The copy/paste issue is a very good point. The first thing many users will do is google the message.
About the specific message you mention, I know you are focusing on the “problem” part, but I am also pondering whether the use of “we” is very sensible here. I understand they’re doing the whole “don’t blame the user” thing, but when an automated process fails, does it really make sense to talk about it in first person plural? There is no “we” doing the signup. I find this rather weird. Thanks for the example!
Why not use “we” for a UI error message, except for the lack of an antecedent? Seems more conversational than any other subject you could put in that spot. I’d start using contractions if I were MS, though. Our Loc team tells us they aren’t hard to translate these days.
I’d rewrite that “You tried to sign up for the Microsoft Update service, but we’re having trouble. .
The trouble is, telling the customer what that next step is when an error condition may be caused by a potrillion different things. Which is why we usually leave off the most important part of an error message, the next step to resolve. But we shouldn’t. We should write better code, so that error messages correspond more closely to the cause of the error condition. Impossible?
Hey, I put “insert next step for customer” in angle brackets, which made them disappear. sorry about that!