Best 10 Examples And Guidelines For Error Messages
A big part of UX is about managing pain points for users. One of the most dreaded (for users) is the error message. This could be an inline error when signing up for a product or it could be one that pops up in the middle of a user’s workflow. The key is to make the interaction as smooth and painless for users as possible. Microcopy best practices and style guides can help you when crafting these types of messages but there’s a lot more to them than just the basics.
Here are ten basic guidelines to help UX writers and content designers create the most effective error messaging for your users.
1. Keep language clear and concise
The rule that applies to all UX microcopy also applies to error messaging. The longer a message, the less likely your users will read them. In fact, an oft-cited study by the American Press Institute showed that shorter sentences result in greater understanding by users. So, when sentences were 14 words or less, users understood 90% of the messaging. When the sentences were 8 words or less, users understood the whole 100%.
Now, sometimes it might not be possible to write a message that short, so don’t beat yourself up attempting to get to 8 words on your error popup. Just remember that less is more and clarity and usefulness are the most important things.
For example, don’t do:
Instead, this works better:
Take a look at the RED banner that flashes for a good 10 sec — ( enough time for the user to read the message) and then slides out of view.
2. Keep user actions specific and logical
The action buttons for your error messages should be very clear to users. Even if they don’t read the whole error message, they should be able to easily see which option to choose in order to solve the issue. If the error message has a “yes,” “no,” or “cancel” action button, consider adding an action word after it. “Yes, refresh the page.” or “No, stay in the app.”
Within the error message itself, there should also be the consequences of those actions. If they stay in the app or refresh instead, what will happen to their progress thus far? Make sure everything is explained as simply and clearly as possible.
Uhh — Yeah, don’t do this:
Rather, this is much clearer:
3. Avoid oops and whoops
The Internet has come a long way from those original “Oops!” messages. Users have been opposed and whooped to death at this point, so generally, it’s best to avoid the cutesy-sounding language.
It doesn’t really help smooth anything over for users anymore and might even annoy them. Would you say whoops to your manager or to a professional colleague if you made an error? Probably not.
It’s generally not good business to talk to your users like they’re children or baby internet users either. At this point, they’ve probably seen error messages and realized what their purpose is, so the “oops” is no longer necessary. (Some people might also throw “yikes” in that group as well but this can also depend on your brand’s tone and voice.)
Another — Don’t do this moment:
Rather — Do this:
4. Don’t blame the user
Users are already going to be frustrated when they get an error message — don’t make it worse by placing the blame on them. This means you should avoid using phrases like “you did” or “you didn’t” when explaining what went wrong. Instead, keep directives specific to what the user needs to do to remedy the problematic action. If the email address they entered is incorrect, then say “Please enter a valid email address using the following format: joe@example.com” instead of telling the user: “You entered your email incorrectly.”
Don’t do this:
Rather do this:
5. Avoid ambiguity
How many times have you gotten frustrated at an error message that popped up with nothing helpful anywhere? We all have been there. Try to keep your users from wanting to shout at the screen by being specific about the error. No, that doesn’t mean you need to put a long jargon-heavy error code. That won’t mean anything to the user. Instead, tell them why there was an error and how they can address the issue.
Avoid vague messaging like this:
Instead, keep it specific, like this:
6. Don’t mock your users / Keep the jokes to a minimum
No one likes being talked down to. Unfortunately, a lot of “humor” found online and in UX can come across as condescending. There are lots of other places to inject friendly, light humor into UX microcopy but an error message isn’t always the best place for it. It would be like asking a friend for advice about your bad day and then they make a sarcastic comment instead. Not the best way to keep user stress levels low.
Mailchimp’s style guide lays it out more specifically, “don’t go out of your way to make a joke — forced humor can be worse than none at all. If you’re unsure, keep a straight face.”
Keep away from your design looking like this:
Instead, humor can be used to have a little fun when appropriate:
7. Avoid negative words
This goes along with user blaming and condescending language. The user is already going to be experiencing some levels of stress because, well, they’re getting an error message.
This should be an opportunity to positively inform users about errors rather than reinforce a negative interaction. It’s a simple language adjustment that can really help users breathe a little easier. Some style guides, like Apple’s, prefer a friendly tone over choosing positive words so check with your company’s style guide to be sure.
Please, please don’t do this:
This is much, much better:
8. Write for humans
No one wants to get one of those Windows messages with a file name three lines long. (What does GeneralNetworkUserError_502 mean anyway?) UX microcopy is all about connecting with users and providing a good experience for them, not bombarding them with technical jargon that they won’t understand (And probably will not help them solve the issue that led to the error in the first place.)
This is one of those universal microcopy rules that applies to all messaging. Write like you’re a human, not a jargon robot. (If you need to include more information about a particular error, then add a drop-down that the user can opt to click should they want to learn more about Error 502.)
Definitely don’t do this:
Instead, try doing it this way instead:
9. Don’t write in ALL CAPS (and avoid exclamation marks)
Everyone knows that one person who sends them messages in all caps. And we all should know that typing in all caps is basically like shouting in real life. As are exclamation points. Now, I love to use exclamation points all the time in my emails but when it comes to microcopy or content, it’s mostly a big “no.” They can add stress or anxiety when it’s completely avoidable by just not using them.
Don’t do this:
Instead, try this:
10. Try to use inline validation
This guideline is less about microcopy and more about UX design. Rather than having an error message pop up with a long list of things the user needs to complete, it’s much better UX to have inline validation. Inline validation is basically putting the error message right next to or above the label it belongs to. This also assists with accessibility as screen readers should read the error message and the field label together, allowing all users to better address the issue at hand.
This really is the worst possible way to do this:
Please for the love of God — make life better for all users by doing this:
Last words:
Great job on reading, I hope you learned the correct dos and don’ts from this article. appreciate the support and until your next read
Keep practicing
Thanks for reading
