UX Planet — Medium | Steven Brykman

No matter the device or desktop, at one time or another we’ve all seen them. And we’ve all been confused by them. I’m talking about error messages. Sometimes they’re so inscrutable they’re hard to forget. I can still remember a devastatingly persistent PostScript Error I got on a Mac SE way back in 1989 that delayed the printing of ZuNews, a UMass humor mag I published (coincidentally with former Apperian CEO Chuck Goldman). Though maybe the reason I remember it so vividly is because Chuck hilariously turned the Mac towards the printer and shouted, “It’s right there!!!”

Because alerts belong to that edge-case area of UX, they are often overlooked by UX people. As a result, developers wind-up writing them. And since developers aren’t usually copywriters, they can come-off sounding accusatory or contain highly technical language nobody but the developer understands. As if error messages are just meant for them — the programmers — and users will never see them. So let’s go over my Top 10 most common (and most egregious) error messages and talk a bit about how to best disappoint your users when things go awry. Simply put, the same rules that apply generally when it comes to creating a simple, intuitive user experience also apply to error messages.

1. Keep them short.

Just don’t.

Don’t worry so much about technical accuracy. What’s important is that it makes sense to the user, even if it’s not 100% accurate from a technical perspective.

2. Use plain and simple language. Avoid tech-speak. And above all, don’t scare users.

Huh?? Holy crap! Am I going to die? Because it sounds like this error is going to kill me!

Anybody remember this classic?

It’s not just a bomb, it’s also a trap! What in the hell is an “unimplemented trap”?

3. Use the right words.

My DVD player occasionally shouts this at me. Really? Prohibited? Do they even know what that word means?? It means “That which has been forbidden; banned.” Talk about scary! Am I going to be sent to jail for pressing Fast Forward? I’m already dealing with that creepy skull and all that fire…and now I’ve got the possibility of incarceration to worry about?! And why is it “currently prohibited”? Will there come a time when it will be legal again? Like with alcohol and weed? This alert should simply read, “Action not supported.” Done.

4. Don’t blame the user.

This language suggests the user is somehow to blame for the error. “Was I supposed to specify something?” asks your user, “Because I don’t remember asking for an error…”

5. If you can’t say something specific, don’t say anything at all.

My personal favorite. If the computer doesn’t know what the error is, how’s the user supposed to? Are you expecting the user to explain the reason for the error? Then shut-up about it! What possible benefit could there be in letting the user know that something happened, but nobody knows what. Imagine if other professions took this same approach: “We know there’s going to be weather tomorrow. We just don’t know what it’ll be.” My advice for developers moving forward: just make something up! Something like “Manifold depolarization error.” Or better yet, try this: “An error occurred.” There. Was that so hard?

6. Don’t state the obvious.

Aren’t all errors unexpected? Is somebody ever sitting at a computer, waiting for her 10AM error to show up? The word “unexpected” is confusing and unnecessary and should be expunged. Again, go with “An error occurred.”

7. Never assume users know what you’re talking about.

Believe it or not, most users don’t know what a server (or a request or a connection) time-out is. If anything, they probably know a time-out as that thing they put their kids in after they’ve bitten their baby brother. Change this to something in plain English, like: “There was a problem with the server.” (Though it’s likely your users don’t know what a server is, either. At least my parents don’t.)

8. Don’t number your errors.

If users don’t know what a Timeout Error or a Bad Request Error is (and why would they?), they certainly won’t know what Error 0x00000643 is. This is likely a shortcut for developers to quickly identify the exact cause of an error. But guess what else would help developers quickly identify the cause of the error? Words! Even words that people understand the meaning of! Using code numbers will only confuse users and make them feel stupid.

9. Keep it in-brand. Use language consistently.

We don’t generally think of error messages as an extension of our brand, but guess what? They are. So whenever possible, try to match the tone of the company’s existing brand language. This can be found on their website or in their printed materials. Is their verbiage formal or informal? Concise or verbose? Lastly, to increase familiarity and consistency, try to use words the brand already uses.

10. An alert is not a band-aid.

Never use an alerts as a shortcut to avoid having to build a better app or process. Remember: alerts are there for the users, not for the developers. In this case, the alert is a band-aid for improper (or lack of) incorporation of the back and forward browser buttons.

Of course, this is but a few of the countless horrific error messages out there. So from now on why not do your users a big favor and let the UX people handle the error message copy, okay? That one guy who dials 911 because of an “Unknown Unexpected Fatal Prohibited Bomb Time-Out (error XD9385494857.000)” that he doesn’t remember specifying, will thank you.

If to err is human, why are error messages so inhumane? was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.