Errors happen. When we need to let users know about them, we present straightforward messages that let users know what happened and what they can do about it.
Keep it simple
Error messages usually consist of two or sometimes three things.
Error or alert definition
Tell users what happened. Be honest and let users know what the system did, what they did, or what they’re about to do.
If you have any information about the error, let users know. Be specific. Don’t just say “Something’s not right” when you know more about what really happened.
If you can describe the error situation clearly in one line, do so, and work with design partners to choose a pattern that works with brief copy. Providing simple, fast guidance is the goal.
- Something’s not right.
- We couldn’t connect to your bank.
More information (optional)
If we have information that doesn’t fit in the error or alert definition or call to action, we can include an additional sentence. We want to keep error messages brief, so more information is optional, and it’s great if we don’t have to include it.
- This is a new feature we’re trying out, and it might not always work.
- The password on your bank account might have changed.
Call to action
Tell users what to do next to solve the problem. If the user can’t fix the problem, let them know what next step they should take (such as trying again later or contacting help).
- Try again later.
- Check your password and sign in again.
Putting the example elements together, we get these sample error messages:
Something’s not right
This is a new feature we’re trying out, and it might not always work. Try again later.
We couldn’t connect to your bank
The password on your bank account might have changed. Check your password and sign in again.
We couldn’t get data from your bank. Try uploading your transactions from a file.
Avoid the try-again loop
Make sure that errors and calls to action don’t trap users in a try-again loop. If the user doesn’t fix the error the first time, it’s annoying for them to see the exact same error the second and third time around.
For example, there are cases where we say something like, “Make sure you’re uploading the right file, and then try again.” And then, after their second failed attempt, we give them a more helpful follow-up message like: “That’s still not working. Let’s go ahead and type your info.”
Error messages from third parties
Occasionally, we need to show users error messages from third parties, such as financial institutions. To make this experience less jarring, craft a brief error message and then follow that with the copy from the third party, preferably highlighted in a callout box.
Wells Fargo sent you this message about the info you tried to import:
[The copy from Wells Fargo appears here.]
Design goals for error messages
- Build and keep trust.
- Build and keep confidence.
- Keep momentum.
- Avoid tragedy.
- Provide guidance.
- Before is better than after.
- Sooner is better than later.
- Proximate contextual messages require fewer words.
- Short (copy) beats good.
- Every error is an opportunity to build trust.
- Error messages aren’t a substitute for error-free functionality.
- Something’s not right. Try again.
We use this message when we’re not sure what caused the error or when the error is so complicated and technical that explaining it might just annoy the customer.
- Oops! We’re sorry! You’ve encountered an asynchronous error. Please try again.
We don’t use exclamations in the copy. And we generally don’t say we’re sorry. A machine is delivering this message, and our users can see through the false empathy. As for the “asynchronous error” copy, we try really hard to keep our content conversational. Unless you’re a developer, you probably haven’t used the word asynchronous with your friends in the past two weeks.