Error state patterns: what to show when something goes wrong
Error states are the screens and messages that appear when something fails. Patterns for validation, system failures and recovery, based on WCAG and NN/g.
What types of error are there?
Not all errors are alike, and each type calls for a different pattern. It helps to separate them before designing:
| Type | Example | Where it appears | What it should allow |
|---|---|---|---|
| Validation | An email without an @ sign | Next to the field | Fix the value and continue |
| Failed action | “The draft could not be saved” | Near the action or in a notice | Retry |
| Empty because of an error | Search or loading returns nothing because something failed | In the content area | Retry or take another path |
| System failure | 500 error across the whole page | Full page | Go back, get notified or wait |
| Permissions | You do not have access to this resource | Page or section | Request access or leave |
The practical rule: the broader the error, the more space the message takes. A misspelled field does not deserve an error page.
How do you design the error message?
NN/g defines an error message as a system-generated interruption that informs the user of an incomplete, incompatible or undesirable situation. Its 2023 guidelines (Tim Neusesser and Evan Sunwall) propose several rules that apply to any screen:
- Close to the source. Display the message next to the element that fails. NN/g states it directly: display the error message close to the error’s source.
- Do not rely on colour alone. Use text, and if you want, an icon and a border. NN/g praises Amazon for combining border highlighting, iconography and red text.
- Do not rush. NN/g asks you to avoid displaying errors prematurely: leaving a field empty while exploring is not a mistake. Real-time guidance makes sense on error-prone fields such as passwords.
- Keep the tone neutral. Avoid words like “invalid”, “illegal” or “incorrect”, which NN/g says imply the user is at fault.
- Offer a way out. Stating the problem is not enough. Suggest a path: the expected format, a value from a list or an action.
- Preserve what the user typed. Clearing a form after an error is the fastest way to make someone give up.
WCAG 3.3.1 (Error Identification, Level A) points in the same direction: the user must know an error exists and what it is, and the error must be described in text. According to the W3C’s explanation, it is not enough to simply re-display the form without indicating that the submission failed.
How do you write the correction suggestion?
Criterion 3.3.3 (Error Suggestion, Level AA) asks for suggestions when an error is detected and the correction is known. The difference is clear with two illustrative versions of the same message:
- “Email is not valid”: identifies the error, so it points to 3.3.1.
- “Enter an address in the format name@domain.com”: also shows how to correct it, which is what 3.3.3 asks for.
If the user types “12” in a field that asks for a month name, the W3C suggests listing the accepted names or interpreting the input and asking “Do you mean December?”. In an address form, if the city and the postal code do not match, NN/g proposes not just saying they do not match, but offering a button for the city that matches the code the user entered.
The criterion has an exception: the suggestion is not required if it would jeopardize the security or purpose of the content. A typical case is a login, where saying which of the two values failed can help an attacker; there, a general message about the credentials is enough, with a way to recover them.
How do you design a system failure?
When the whole page fails to load, the message has to do three things: say what happened without jargon, give a concrete action and avoid leaving the user in a dead end. The most useful rule from NN/g here is that stating the problem is not enough: you should suggest remedies.
A solid pattern has this structure:
- What happened, in one sentence.
- What the user can do: retry, go back, save what they have.
- What the system is doing: “Retrying automatically…” if that is the case.
- An optional technical detail, collapsed, with the error code for support.
If the error is a validation problem, the moment you show it changes the experience: see form validation timing. To write the text with care, read how to write error messages. To prevent errors before they happen, read prevention versus recovery from errors. For the loading states that come before an error, see loading states. And if the failure comes from an irreversible action, such as deleting, review the destructive action safeguards before designing the message.
Example
Illustrative example: a booking form with four fields. On submit, the phone field has an incorrect format. The message appears under the field with text, a red border and the expected format: “Enter 10 digits, for example 0991234567”. The other data stays in the form. The focus moves to the field in error, so that someone using a screen reader hears it.
An exercise for tomorrow: review the errors in your product and classify them with the table above. If one “Something went wrong” message serves three different kinds of failure, you already have a problem to fix.
Common mistakes
- Using a generic message (“Error 400”) for every kind of failure.
- Showing the error only in colour, without text: NN/g warns never to use only colour or animation to indicate errors.
- Placing the message far from the problem, for example only above the form.
- Blaming the user with words like “incorrect” or “invalid”.
- Showing errors too early, while the user is still typing.
- Leaving a dead end: an error with no button, no link and no explanation.
- Clearing what the user typed when the error happens.
- Using modals for every error. NN/g reserves modals for severe errors that block progress; for a minor failure, a banner or a subtle notice is usually enough.