Text displayed when something goes wrong in an interface, telling users what happened and how to recover. Good error messages are specific, written in plain language, non-blaming, and actionable — they never simply say 'Error' or display system codes.
Common contexts
- Inline form validation telling a user exactly which field failed and why, as they move through a checkout
- Server-side error state explaining a payment failure and offering a clear retry path
- Permission error in a B2B tool that tells the user who to contact rather than just blocking access
Use when
Every time the system detects an error that requires user action — even minor ones. Treat every error message as a recovery touchpoint, not a failure notification, and always pair the problem statement with a next step.
Avoid when
Don't display error messages preemptively before a user has had a chance to complete input — showing a 'required field' error the moment a field loses focus creates anxiety and feels accusatory rather than helpful.
The best error message is a preventive one — if you're seeing high rates of the same error, the real fix is usually upstream in the form design, not in the wording of the error text itself.
Real-world examples
- Mailchimp's error messages are written in plain, friendly language that explains what went wrong and how to fix it, contrasting with generic system-level error codes common in enterprise software.
- GitHub's 404 page uses humor and helpful navigation links to turn an error state into a branded, useful experience rather than a dead end.
- Google Forms provides inline error messages with specific guidance (e.g., 'Please enter a valid email address') directly below the problematic field, following accessibility best practices.