Error States
Error states must tell users what went wrong, why it went wrong, and what to do next — a message that only reports failure without guiding recovery is incomplete.
An error message that says “Something went wrong” has told the user nothing useful. They already know something went wrong — that is why they are reading the message.
The three requirements
Every error message must do three things: identify what went wrong (which field, which action, which constraint was violated), explain why it went wrong (the rule that was not met, the condition that failed), and direct the user toward recovery (what specifically to do to fix it). A message that satisfies only the first requirement — “Invalid email” — leaves the user to infer the second and third. A message that satisfies all three — “Email addresses must include an @ symbol — e.g. name@example.com” — removes all ambiguity.
Where errors appear
Errors belong adjacent to the element that caused them. A form field error appears directly beneath the field, not in a toast at the top of the screen. When a form has multiple errors, each field shows its own error message, and a summary at the top links to each affected field — giving users both an overview and direct navigation. Do not clear the user’s input when showing a validation error — make them correct it, not re-enter it.
Inline versus submission
Inline validation — checking input as the user types or as they leave a field — catches errors early but must be used carefully. Triggering an error immediately as a user starts typing in a field creates a hostile experience. Validate on blur (when the field loses focus) for most cases. Only validate on input when the constraint is about format that the user is actively building (such as a password strength indicator) rather than a failure state.
Tone
Error messages should be factual and helpful, not apologetic or alarming. “We couldn’t save your changes” is better than “ERROR: Save operation failed.” Active voice, plain language, and a forward-looking instruction are the standard. Avoid technical jargon, status codes, and internal system terminology. Write for the user who has never seen the system before.
The takeaway
Write error messages as part of designing the interaction, not as copy added at the end. For every input or action that can fail, define: what are the failure modes, what message does each produce, and where does it appear? Errors designed in advance are always clearer than errors written under time pressure before launch.