If to err is human, why are error messages so inhumane?

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.

UX of Error Messages
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.
UX of Error Messages
Huh?? Holy crap! Am I going to die? Because it sounds like this error is going to kill me!

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

UX of Error Messages

3. Use the right words.

UX of Error Messages
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.

UX of Error Messages
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.

UX of Error Messages
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.

UX of Error Messages
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.

UX of Error Messages
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.

UX of Error Messages
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.

UX of Error Messages
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 if you need help constructing your error messaging, or would like to consult with a strategist on anything related to mobile strategy or user experience, contact Propelics now to schedule a complimentary 30 minute call to help bring your digital presence up to speed with current best practices.

Share on

Facebook sharing Linkedin sharing button Twitter sharing button

Ready to get started?

Enter your information to keep the conversation going.
Location image
4 Sentry Parkway East, Suite 300, Blue Bell PA, 19422

Email Image


Phono Image610 239 8100

Location Image4 Sentry Parkway East, Suite 300, Blue Bell PA, 19422
Phono Image610 239 8100