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.
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 results 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:
Sure, it’s a short message but does it tell users anything at all?
Instead, this works better:
Clear, concise, and empathetic messaging from Spotify. Users know what the problem is and what they need to do to fix it.
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.
Please, don’t do this:
I feel like these are trick buttons for users.
Rather, this is much clearer:
Instagram gives users two clear actions that go along with the message above them.
3. Avoid oops and whoops
The Internet has come a long way from those original “Oops!” messages. Users have been oopsed and whoopsed 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 any more 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 realize 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.)
Please, don’t do:
So many things wrong with this one. What if your users aren’t native English speakers? Also, what happened to using periods at the end of sentences?
This is much better:
Twitch’s error messaging is on brand, a little humorous, but not cutesy or annoying.
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: [email protected]” instead of telling the user: “You entered your email incorrectly.”
Don’t do this:
I feel like I’m in trouble and I don’t even know why.
This works much better:
HBOMax demonstrating the correct format needed rather than telling me I did it wrong.
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:
Slack is known for having great (and appropriately humorous) microcopy.
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.” (Check out more style guides for notes on humor and jokes in microcopy.)
Best to not do this:
A perfectly unnecessary example of condescending microcopy on an unsubscribe link.
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:
Not only is this microcopy from Bitly negative, it comes across as condescending and doesn’t tell the user what is wrong with the password OR the email format. 😠
This is much, much better:
Microsoft Office taking the blame and telling users what to do next without any negative words directed at them.
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 in a drop down that the user can opt to click should they want to learn more about Error 502.)
Definitely don’t do this:
Umm, what does that error message even mean?
Instead, do this:
Straight to the point and in simple language that sounds like an actual person is talking.
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 mircoropy 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:
(Yes, I know this is from a game. I’ve talked about microcopy in games before.) But still, when everything has an exclamation point, users really don’t know which buttons are important.
If you really
have to want to use an exclamation point, do it like this:
Github is trying to bring attention to the message with the yellow highlight and very light usage of that exclamation point. There’s a bit of humor injected so users don’t feel like they’re being shouted at.
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 with. 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:
Giving users a long list is only going to frustrate them further and make it extremely difficult to understand, especially users with screen readers.
Please make life better for all users by doing this:
Hulu showing that inline validation is becoming standard across the Internet and apps because it’s a much better experience for users.
Do you agree with our guidelines or do you think something is missing?
I’d love to hear more. You can find me on LinkedIn; I love chatting about words. The UX and Microcopy Facebook group is into discussing all sorts of microcopy. Come and join the discussion!
What is UX writing? (article)
Microcopy in a nutshell (article)
UX writing vs. content design: Setting the record straight (article and podcast episode)
UX research for beginners (article)
Who’s afraid of UX research? (podcast episode)