Error State
What an interface shows when something failed — which system failed, whether the user's work survived, and what they can do next.
UI ComponentsAn error state answers three questions in order: what failed, whether anything was lost, and what to do now. Most shipped error states answer none of them. “Something went wrong” tells the user only that the product knows it is broken, which they had already worked out. The version that works names the operation (“We couldn't save your changes”), states the damage (“your draft is still here”), and offers the recovery (“Retry”).
Errors divide by who can fix them. Validation errors are the user's to fix and belong next to the field, in the user's words, before submission. System errors are yours, belong near the action that failed, and should carry a retry plus a reference the user can paste into a support message. Permission errors are neither, and saying “Not found” when the real answer is “you do not have access” sends people to support with the wrong question.
Error state vs empty state
The distinction is whether the system worked. An empty state means the request succeeded and returned nothing; an error means it did not succeed. Products that collapse the two teach users to distrust every blank screen.
In practice
A payments dashboard returned “An error occurred” whenever a transfer failed, for six different reasons. Support handled about 40 tickets a month asking what went wrong. Splitting the message into the actual causes — insufficient balance, limit exceeded, recipient details rejected, network timeout — with the specific fix in each, cut those tickets to single digits. No backend change: the API had been returning distinct codes the whole time.
Where teams get it wrong
- “Something went wrong” as the only message. It is the string that tells the user nothing and the support team nothing either.
- Not saying whether the work survived. The first thing anybody wants to know after a failure is whether they have to type it again.
- Validation errors that only appear on submit, after the field is off-screen.
- Technical error codes shown with no plain-language sentence beside them.
- Errors written in the passive voice to avoid admitting fault. “Your session could not be validated” hides who should retry what.
Learn more
You may ask
Frequently Asked Questions
What makes a good error message?
It names the operation that failed, says whether the user's work survived, and gives one concrete next step. “We couldn't save your changes — your draft is still here. Retry” does all three in eleven words.
Where should validation errors appear?
Next to the field they belong to, and as soon as the answer can be judged — usually on blur rather than on submit. An error summary at the top of a long form helps only if each item links to its field.
Should error messages include error codes?
Include one when a human will need it to get help, alongside a plain sentence — never instead of it. A code the user can copy turns a vague support thread into a searchable one.
Related terms
All terms- Empty StateWhat a screen shows when it has no content yet — the first screen every new account sees, and usually the last one anybody designs.
- Form DesignDesigning the fields, sequence, validation and error handling of a form so people can finish it without stopping to think.
- Toast NotificationA brief message that appears over the interface to confirm an action or report a problem, then disappears on its own.
- AlertAn in-page message about something needing attention — persistent, placed where it applies, and gone only when the condition is.
Defined by Mara Last reviewed .
Let's talk about your product.
Happy to look at what you're building and say where design would move the needle.
Contact Us