A good error message tells the user what happened, why it happened, and exactly what to do next — never just "something went wrong." The best ones prevent the error from occurring at all, whenever a field-level constraint can catch it before submission.
Quick Answer: Follow prevent-explain-recover: stop bad input before it's submitted, explain failures in plain language without blaming the user, and always end the message with a specific recovery action. Place errors inline near the field they concern; reserve toasts for system-level failures the user didn't cause.
Why Most Error Messages Fail Users
Most error messages fail because they were written as an afterthought — a catch block that renders error.message straight from an API response. The fix is treating error copy as a first-class deliverable, specified alongside the happy path, not bolted on after QA finds a gap.
Engineers write error strings to describe what the code did ("Validation failed: field 'email' invalid"). Users need to know what they should do ("Enter an email address with an @ symbol, like name@example.com"). Those are different jobs, and conflating them is the root cause of nearly every bad error message in production.
The blame reflex is the second failure mode. Messages like "You entered an invalid value" or "Invalid request" implicitly frame the user as the one who screwed up, even when the real cause is a stale session, an ambiguous form label, or a backend timeout. Nielsen Norman Group's long-running usability heuristics explicitly call for error messages phrased as "precise problem indication or constructive suggestion," not generic blame or codes only engineers understand.
A third failure is silence at the point of failure. A payment fails, the page reloads, and the cart is empty with no explanation. The user doesn't know if they were charged, if the site is broken, or if they did something wrong. Ambiguity is worse than a blunt error, because it leaves the user unable to act at all.
The Cost of Getting This Wrong
Poor error handling doesn't just annoy users — it directly suppresses conversion and completion rates. The Baymard Institute's checkout usability research has repeatedly found form validation and error messaging among the top friction points causing site abandonment, well ahead of "no guest checkout" complaints. When a user hits a confusing error twice, most don't file feedback — they leave.
The Prevent-Explain-Recover Framework
The prevent-explain-recover framework reframes error UX as a design decision made in three layers: stop the error before it happens, explain it clearly if it happens anyway, and give the user a concrete way to recover. Most teams only design the middle layer and skip the other two.
Prevent: Design the Error Out of the Interaction
Prevention is cheaper than explanation. Every error message you have to write well is evidence a better interaction design could have avoided the error entirely.
- Constrain input at the source. Use date pickers instead of free-text date fields, dropdowns for a known set of options, and input masks for formatted fields like phone numbers or credit cards.
- Validate inline, as the user types or on blur, not only on submit. Catching a malformed email the moment the user leaves the field is cheaper — cognitively and emotionally — than surfacing it after a five-field form submission fails.
- Disable actions that cannot succeed. Gray out a "Submit" button until required fields are filled, rather than letting the user click it and then telling them why it failed.
- Show constraints before the user violates them. A password field that lists its rules ("8+ characters, 1 number") up front prevents an error better than rejecting the password after submission.
This is the layer most closely tied to cognitive load and why a simple screen can still overwhelm users — every rule the user has to hold in memory instead of seeing on screen is a chance for an error, and every error is itself a load spike at the worst possible moment.
Explain: The Anatomy of a Good Error Message
A well-formed error message has three parts, in this order: what happened, why it happened, and what to do about it. Skip any one of the three and the user is left guessing.
| Component | Bad example | Good example |
|---|---|---|
| What happened | "Error" | "This file couldn't be uploaded." |
| Why it happened | (missing) | "It's 15MB, and the limit is 10MB." |
| What to do | (missing) | "Compress the file or choose a smaller one." |
| Tone | "Invalid input" | "Enter a date in MM/DD/YYYY format" |
| Blame framing | "You entered the wrong password" | "That password doesn't match our records" |
Notice the good column never uses the word "invalid" without qualifying it. Specificity is the difference between an error message and an error code with extra words. "Invalid input" tells the user nothing actionable; "Enter a date in MM/DD/YYYY format" tells them exactly what to fix.
Recover: Always End With an Action
Recovery is the layer teams skip most often, because it requires designing what happens after the error, not just the error itself. A message without a recovery path is a dead end.
- Offer a direct fix, not just a description: "Try again," "Use a different email," "Contact support" — each with a functioning link or button, not just text.
- Preserve user input. Never clear a form because one field failed validation; re-render the error next to the offending field with everything else intact.
- Offer an escape hatch for errors the user can't fix themselves — a retry button for network failures, a support link for account-state issues, a "save as draft" for anything long-form.
- Distinguish recoverable from unrecoverable errors in tone. A typo is recoverable and low-stakes; a payment decline needs a calmer, more reassuring tone and a clear next step.
Tone and No-Blame Language
Error tone should be calm, specific, and free of language that assigns fault to the user, even when the user technically caused the problem. The goal is functional clarity, not personality — a light voice can still read as flippant when someone is stuck.
Avoid "you" as the subject of a failure. "You entered an invalid password" reads as accusatory; "That password doesn't match" describes the state without pointing a finger. This is a subtle rewrite, but it changes who the message implicitly blames.
Avoid exclamation points, jokey copy, and words like "oops," "whoops," or "uh-oh" for anything beyond the most trivial, reversible errors — a 404 page can afford levity; a failed bank transfer cannot. Match tone to stakes, not to brand voice guidelines written without failure states in mind.
Never expose raw system errors to users. Stack traces, HTTP status codes, and internal error IDs belong in logs and, optionally, in a collapsed "technical details" disclosure for support purposes — not as the primary message. If a support agent needs the code, show it small and secondary, never as the headline.
Rewrite test: read the error message aloud as if saying it to a friend standing next to you. If it sounds like something you'd never actually say out loud to a person, rewrite it.
This same discipline — writing for the person in front of the interface rather than for the system underneath it — is the throughline of good design literacy for PMs: the words in a product are as much an interface decision as the layout.
Inline vs. Toast: Where to Place the Error
Inline errors belong next to the specific field or action that failed; toast (or banner) notifications belong to system-level events the user didn't directly trigger. Mixing them up is the most common placement mistake — an inline-shaped problem shown as a toast disconnects the message from its cause.
| Situation | Best placement | Why |
|---|---|---|
| Invalid form field (bad email format) | Inline, under the field | User needs to fix that exact input |
| Required field left empty | Inline, under the field | Same — the fix is local to the field |
| Payment declined | Inline or modal, near the payment form | High-stakes; user needs full context, not a fleeting message |
| Network request failed in the background | Toast | Not tied to a visible field; user needs to know status changed |
| Session expired | Modal or full-page interstitial | Blocks all further action until resolved |
| Bulk action partially failed (8 of 10 succeeded) | Inline summary near the list, not a toast | User needs to see which 2 failed and why |
Rule of thumb: if the user is actively looking at the thing that failed, use inline placement. If the failure happened somewhere the user isn't currently looking — a background sync, an autosave — use a toast, but make it persistent enough to notice and dismissible without losing the message.
Toasts that auto-dismiss after two or three seconds are a common cause of "I didn't even see what went wrong." For anything the user needs to act on, keep the notification visible until they dismiss it or resolve the underlying problem.
Error Placement and the Broader Flow
Error states are one piece of a much larger discipline: designing every state a screen can be in, not just the happy path. That's the core argument in the complete guide to product design and UX for PMs — error, empty, loading, and success states are all first-class states, not edge cases bolted on afterward.
Error placement also can't be designed in isolation from the surrounding flow. If a form spans multiple steps, an error on step 2 needs to be visible without forcing the user to abandon step 3's progress — a problem best caught by mapping the full customer journey rather than reviewing each screen in isolation.
Specifying Error UX Before It Ships as an Afterthought
The most reliable way to get good error messages into production is to specify them at the same time as the happy path, not after a bug report surfaces a blank error state. Retrofitting tone and recovery paths after launch is slower and produces worse copy, because it's reactive instead of designed.
Before requesting engineering review of any form or flow, it's worth running the copy past someone with product design fluency, using the same review discipline covered in how a PM can critique design without overstepping — the goal is catching blame-y or vague error copy in review, not in a support ticket.
Key Takeaways
- Prevent-explain-recover reframes error UX as three design decisions, not one string of copy — prevention beats explanation every time it's possible.
- A good error message always contains what happened, why, and what to do next — omitting any one leaves the user guessing.
- No-blame language avoids putting "you" at the center of the failure; describe the state, don't assign fault.
- Inline errors belong next to the field that failed; toasts belong to system-level events the user didn't directly cause.
- Never expose raw stack traces or error codes as the primary message — log them, and surface them only as optional technical detail.
- Specifying failure paths alongside the happy path, not after launch, is what actually gets good error copy shipped on time.
Frequently Asked Questions
What makes a good error message in UX design?
A good error message states what happened, explains why in plain language, and gives the user a specific action to recover — all without blaming them for the failure. It avoids system jargon, stack traces, and vague phrases like "invalid input."
Should error messages use inline validation or toast notifications?
Use inline validation for anything tied to a specific visible field or action, since the user is already looking at it. Reserve toast notifications for background or system-level events the user isn't currently focused on, like a failed autosave.
How do you write error messages without blaming the user?
Avoid framing the user as the subject of the failure — write "that password doesn't match" instead of "you entered the wrong password." Describe the system's state rather than the user's mistake, and keep tone calm and specific rather than casual or apologetic.
When should validation happen — on submit or as the user types?
Validate as the user leaves a field (on blur) whenever possible, rather than waiting until form submission. Catching an error early, one field at a time, is cognitively cheaper than surfacing five errors at once after a full-form submit.
Why do error messages hurt conversion rates?
Confusing or blame-heavy error messages leave users unsure how to proceed, and usability research from organizations like the Baymard Institute has repeatedly found form and checkout error handling among the top causes of abandonment. A clear recovery path keeps users in the flow instead of pushing them to leave.