Errors

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.

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.

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).

Putting the example elements together, we get these sample error messages:

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.

Design goals for error messages

• Build and keep trust.
• Build and keep confidence.
• Keep momentum.
• Avoid tragedy.
• Provide guidance.

Guiding principles

• 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.