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.
- You reached the maximum number of categories in your QuickBooks Online plan.
- Amount is higher than your available funds.
- You got signed out because your QuickBooks admin changed your role.
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.
- You reached the daily trade maximum. (5 per day)
- Amount is over the 7-day rolling limit. ($100,000)
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.
- To add more categories, upgrade your plan.
- Find a supported browser.
- Refresh the page.
- Update your billing info.
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.
Something isn’t working
We need to fix some things on our end. After we’re done, you can manage your subscription here.
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.
You already have a tag with this name. Try a different name.
It’s time to update your browser
To keep using QuickBooks, update or switch to a browser we support by Feb 1, 2022. [CTA: Find a supported browser]
Amount exceeds 95% of bitcoin balance. Use Sell all instead.
Your bitcoin account is on hold
Select the Help icon to chat with an expert or request a callback.
Totals not available. Try refreshing the page.
[X] didn’t load. Pull down to refresh or check your internet.
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.
While not ideal, 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.
- [X] didn’t save. Try again or check your internet.
This message works because it describes the error and includes a call to action to resolve the problem.
- Didn’t save. Try again!
This message is too vague. “Try again” doesn’t give enough specific instructions to the customer.