Error State & Error Message Design

The plain-language idea

An error message can be technically accurate and still fail its actual job. "Error 422," "Something went wrong," and "Request failed" are all true — and none of them tell the user what happened in terms they can act on. A useful error message states what went wrong in plain, user-facing language and, wherever possible, what to do next. "This email is already registered — try signing in instead" does the same job "Error 422" does for the system, but it's the version a human can actually use.

Errors also need to be shown at the right level, and the three levels aren't interchangeable:

• Field-level — the error belongs to one specific input (an invalid email format, a password that's too short). Show it right next to that field, not somewhere else on the page.
• Page-level — the error affects the whole view (a page failed to load its data). A banner or full-page state, not a toast that disappears before anyone reads it.
• Toast/transient-level — a brief, non-blocking notice for something that happened but doesn't need sustained attention (a background save failed, retrying automatically). Toasts are the wrong choice for anything the user needs to act on, because they vanish.

See it in a real thing: "invalid input" vs. the fix

Compare two versions of the same failed form submission:

"Invalid input. Please correct the errors and try again."

versus

"Password must be at least 8 characters and include a number. Yours is 6 characters with no number."

The first is technically true and requires the user to hunt across the entire form for which field, of possibly a dozen, is the actual problem. The second names the specific field, states the specific rule that wasn't met, and states specifically how the given input failed to meet it — the user can fix it without a second guess.

The most damaging pattern is an error that implicitly blames the user without saying which field or why — "Something's wrong with your submission" reads as the product refusing to explain itself. The fix is never a softer tone on the same vague message; it's naming the actual field and the actual rule.

What people usually miss

Watch out

• A technically accurate status code is not the same as a useful message. Surfacing the raw HTTP status or an internal error code to the end user is a debugging artifact leaking into a product surface — it belongs in logs or a "details" disclosure, not the primary message.
• Toasts are for notice, not for action. An error that requires the user to actually do something (fix a field, retry a critical action) needs a persistent, in-place error — a toast that auto-dismisses in three seconds can vanish before the user has even read it.
• A page-level error needs a real fix presented, not just a statement of failure. "This page failed to load" with no retry button is a dead end; the same message with a retry action gives the user something to do about it.
• Vague blame ("check your input") without specifics is worse than silence for trust — it tells the user something is wrong without giving them any way to resolve it themselves, which reliably produces a support ticket that a specific message would have prevented.

Why this matters in interviews

"How would you improve this error message?" tests exactly this distinction — a candidate who rewrites "Error 422" into specific, actionable, correctly-placed text (the right field, the right level, a concrete next step) is demonstrating the difference between engineering-accurate and user-useful, which is a genuinely common gap in real products.