Every product has error states. Almost every product gets them wrong. "An error occurred," "Something went wrong," "Invalid input" — these messages are technically true and practically useless. They tell a user that the system failed without telling them what failed, why it failed, or what to do next. For a piece of interface text that most teams write in five minutes and never revisit, error messages have an outsized effect on whether a user trusts a product, finishes a task, or quietly abandons it and opens a support ticket instead.
Good error message writing is a specific discipline that sits at the intersection of UX writing, interaction design, and accessibility. It's also one of the highest-leverage places a small team can improve a product, because unlike a redesign or a new feature, fixing error copy rarely requires new engineering work — just better words in the same components that already exist.
What a good error message actually does
The consistent framework across UX writing guidance is simple to state and surprisingly hard to execute: a good error message names what went wrong, explains why it happened, and points to a fix, delivered through a component appropriate to how serious the problem is. Miss any one of those three pieces and the message fails at its job even if the tone is polite and the grammar is perfect.
Consider the difference between these two messages for a failed form submission:
- Bad: "Invalid input."
- Better: "Your password needs at least 8 characters, including one number. You entered 6."
The first tells the user something is wrong but leaves them guessing at which field, what rule was violated, and how far off they are. The second answers all three questions in one sentence. That's the entire discipline in miniature — the difference isn't cleverness, it's completeness.
Plain language over technical accuracy
A recurring theme across UX content guidance is that error messages should be written in plain, conversational language that anyone can understand, not the vocabulary of the system that produced the error. A backend validation failure that surfaces as ERR_422_VALIDATION_CONSTRAINT or "Request failed with status code 500" is accurate from the server's point of view and meaningless from the user's. The user doesn't know what a 422 is and shouldn't have to.
This doesn't mean hiding useful detail — a support team or a power user may genuinely need the status code — but it means the code belongs in a secondary location (an expandable "technical details" section, a copyable error ID, a support link) rather than the primary message a first-time user sees. The primary message should read like a person explaining the problem to another person, not a system logging an exception.
Tone: factual and calm, not cute and not alarming
There's a persistent temptation, especially in consumer products, to make error messages "on brand" with jokes or exaggerated apologies — "Oops! Our bad! 🙈" It works occasionally, but the tone should still be factual first. State what the issue is in plain language, then what the user can do about it, keeping the tone factual yet friendly. A playful error message that doesn't actually explain the problem is worse than a plain one that does, because it burns the user's patience on personality instead of spending it on resolution.
The opposite failure mode — alarmist language for low-stakes errors — is just as common. Treating a mistyped email address with the same visual weight and wording as a failed payment or a data-loss warning trains users to either panic at every red banner or ignore all of them equally. Severity should be visually and verbally calibrated: a red, modal, blocking treatment for something that truly stops the user, and a lighter inline treatment for something they can fix in place.
Placement matters as much as wording
Where an error appears is often more important than what it says. The strongest guidance here is to use inline validation wherever possible — showing the message directly next to the field or action that caused it, rather than in a banner at the top of the page or, worse, a toast that disappears before the user finishes reading it. Inline validation next to a form field, paired with a visual cue like a highlighted border, keeps the fix and the problem in the same visual space, so the user doesn't have to hold the error in their head while scrolling to find the field it refers to.
Timing matters too. Validating a field the instant a user starts typing, before they've finished, produces error messages that feel like they're scolding the user mid-thought ("Password too short" appearing after the third keystroke). Better patterns validate on blur (when the user leaves the field) or on submit, and clear the error the moment the user starts correcting it — positive reinforcement that the fix is working, rather than making them resubmit to find out.
Accessibility is not optional
Color alone is not a reliable signal. A meaningful share of users have some form of color vision deficiency, and red text or a red border communicates nothing to them if it's the only signal used. The standard fix is to pair color with an icon — an exclamation mark, an alert glyph — and with text, so the error is legible through at least two independent channels. Screen reader users need the error programmatically associated with its field (via aria-describedby or equivalent) and ideally announced when it appears, not just visually rendered; a red border that a screen reader never mentions is invisible to that user entirely.
Contrast matters too — error red on a light background needs to meet the same WCAG contrast thresholds as any other text, and teams that pick a "brand red" without checking contrast frequently fail this without realizing it until an audit catches it.
Consistency is a system problem, not a copy problem
Individual error messages are usually written by whichever engineer happened to build the feature, which is why most products end up with wildly inconsistent error tone: some messages are terse and technical, others are chatty and apologetic, and the capitalization, punctuation, and level of detail vary field to field. The fix that consistently shows up in mature UX content practices is treating error messages as a governed set, not individual strings — a style guide that specifies sentence structure ("What happened. What to do."), capitalization rules, punctuation, and a bank of approved phrasing for common failure categories (network errors, validation errors, permission errors, timeout errors) that any engineer or writer can pull from instead of inventing new copy each time.
This is a case where a small upfront investment — a one-page error message style guide with five or six templated patterns — pays for itself many times over in consistency and in the engineering time saved not debating copy in every pull request.
A checklist for auditing existing error messages
If you're reviewing an existing product's error states rather than writing new ones, a few questions catch most of the common failures quickly:
- Does the message say specifically what went wrong, not just that something did?
- Does it explain, in plain language, why (if the reason is useful to the user)?
- Does it tell the user what to do next, ideally as an action they can take immediately?
- Is it placed next to the thing it refers to, not in a disconnected banner?
- Does it use more than color to signal severity?
- Is it announced to assistive technology, not just rendered visually?
- Would a first-time user, with no technical background, understand it without help?
Most products fail at least two or three of these on a first honest pass, and almost all of the fixes are copy and small component changes rather than a redesign.
Common error categories and how to handle each
Not every error is the same shape, and treating them all with one template is part of why so many products end up with inconsistent copy. A few recurring categories are worth handling deliberately:
Validation errors (a form field doesn't meet a rule) are the most common and the easiest to get right, because the fix is almost always fully known at the moment the error fires: "Email needs an @ symbol" is complete and actionable. These should appear inline, at the field, the instant the user has enough context to fix them — typically on blur rather than on every keystroke.
Network and connectivity errors (a request timed out, the server didn't respond) are harder because the system genuinely doesn't know what went wrong from the user's point of view. The honest move here is to say exactly that — "We couldn't reach the server. Check your connection and try again" — rather than inventing a more specific-sounding but false explanation. Offering a retry action directly in the error message (a button, not just prose telling the user to reload) measurably reduces abandonment here, since it removes a step between diagnosis and recovery.
Permission errors (the user tried to do something they're not allowed to do) should say who can help, not just that access is denied. "You don't have permission to edit this document. Ask an admin on your team to grant access" is far more useful than "403 Forbidden," because it gives the user their next action instead of a dead end.
System/server errors (something broke on the backend, not because of anything the user did) are the category most often mishandled, because engineers write them defensively rather than helpfully. The user did nothing wrong here, and the copy should say so plainly — "Something went wrong on our end, not yours. Try again in a minute" — paired with a way to report it if it persists (an error ID, a support link) rather than leaving the user to guess whether retrying is even worth attempting.
Empty and zero-result states are adjacent to true errors and often mishandled the same way — a blank screen or a terse "No results" instead of guidance on what to try next (broadening a search, checking a filter, or a clear call to action if the emptiness is expected, like a brand-new account with no data yet).
Testing error copy the way you'd test any other UX
Because error messages are easy to write quickly and easy to leave unrevisited, they rarely get the same scrutiny as onboarding flows or checkout pages — despite often being encountered by a larger share of users. A few lightweight practices close that gap without much overhead: read every error message out loud before shipping it (copy that sounds natural in a design file often sounds robotic or condescending read aloud); have someone outside the team who built the feature try to trigger and then resolve the error without help, since the person who wrote the validation logic is the worst judge of whether the message is actually clear to someone who doesn't already know the rule; and periodically pull real error logs to check which messages are firing most often in production, since the errors a team assumes are rare are sometimes the ones users hit constantly.
Why this matters beyond the interface
Error messages are also, quietly, a support-deflection lever. A vague error that leaves a user stuck is one of the most common reasons people abandon a signup flow, give up on a purchase, or open a support ticket for something that a clearer message could have resolved on the spot. For products that field a high volume of repetitive support questions — "why won't this form submit," "why did my upload fail" — better error copy at the point of failure is frequently a cheaper and faster fix than adding more support capacity after the fact. A support widget that can answer "why is my form showing an error" in the moment is useful, but the ideal is that the error message itself already answered the question before the user needed to ask anyone.
Getting error messages right is unglamorous work. It rarely shows up in a portfolio case study and never in a highlight reel. But it's one of the few places in a product where a genuinely small investment — rewriting a few dozen strings with more care — has a measurable, immediate effect on whether real users can actually finish what they came to do.
Sources:
- Error message examples: How to craft clear, effective UX messaging - LogRocket Blog
- Error Message UI: 7 Best Practices + Real SaaS Examples - Eleken
- How to write error messages - UX Content Collective
- 6 Best Practices for Writing Great Error Messages - UX Design World
- User experience guidelines for errors - Microsoft Learn
Get new posts as they publish
No spam — just the next post, straight to your inbox.