Error messages get designed last and tested least. After the happy path works, teams put a generic error message on every failure state and ship. The result is a product that handles success gracefully and handles failure with a generic "Something went wrong."
This is a missed opportunity, and a significant one. Users form impressions of a product not just through its features but through how it responds when things go wrong. A product that handles errors with clarity and care communicates competence and trustworthiness. A product that responds to errors with vague, unhelpful messages communicates the opposite.
Photo by Walls.io on Pexels
What Users Actually Experience During an Error
When a user encounters an error, they go through a short but important cognitive process. First, they notice something did not work. Then they try to understand why. Then they look for what to do next. If the error message does not support that third step, a significant percentage of users will abandon rather than persist.
The data behind this is consistent across product categories. Nielsen Norman Group research on usability consistently finds that users who cannot quickly understand how to recover from an error abandon the task at much higher rates than users who hit no errors at all. An unclear error message is not just a minor annoyance; it is a conversion killer.
Three Things Every Error Message Must Do
Identify what went wrong
Not generally ("An error occurred") but specifically ("Your email address is not in the right format"). The user needs to know what specifically failed before they can fix it.
Specificity reduces the amount of work the user has to do. A specific error message makes the recovery path obvious. A vague error message turns error recovery into a guessing game.
Point to what to do next
An error message without a recovery path is a dead end. "Your session has expired" is half an error message. "Your session has expired. Sign in again to continue." is a complete one. The difference is a clear next action.
For errors caused by the user, the next action is usually obvious: fix the specific thing that failed. For errors caused by the system (server errors, timeouts), the next action might be "try again in a moment" or "contact support." Both are more useful than silence.
Use human language
Error messages written in technical language ("HTTP 422: Unprocessable Entity", "Null reference exception") serve developers debugging a system, not users trying to complete a task. Users who encounter technical error language either give up or feel like they did something incomprehensible wrong.
Plain language in error messages is not dumbing down the product. It is communicating at the right level of abstraction for the audience. An error message that says "We could not save your changes. Check your connection and try again." delivers the same information as a technical error without alienating the user.
The Psychology of Error Attribution
One nuance that improves error message quality: error attribution matters to users emotionally, even when the attribution is implicit.
Error messages that frame the problem as the user's fault ("Invalid input") cause users to feel blamed, even when they know they made a mistake. Error messages that avoid the framing ("Check that all required fields are filled in") address the same problem without triggering a defensive response.
This is not about absolving users of responsibility. It is about keeping them emotionally engaged with solving the problem. A user who feels blamed by a product is more likely to stop trying than a user who feels supported.
This principle is especially important for errors that are genuinely the user's fault (wrong password, invalid format, missing required field) because those are precisely the errors where a defensive response most derails recovery.
When Error Messages Build Trust
Good error messages build trust in ways that successful interactions do not.
A successful interaction confirms that the product works. An error message that handles failure well confirms that the product was designed thoughtfully, by a team that considered what would happen when things went wrong. That is a different kind of trust, and in some ways a stronger one, because it shows intentionality.
Products with clear, helpful error messages are rated more favorably in usability studies even when users encounter more errors, compared to products with fewer but poorly communicated errors. The experience of getting stuck and getting unstuck quickly is better than getting stuck and staying stuck.
Consistency Across Error States
One underappreciated dimension of error message quality: consistency. Most products accumulate error messages written by different people over different periods of time. Some are specific and helpful. Some are vague and technical. The inconsistency itself is a problem.
When error messages are inconsistent, users cannot build a mental model of how the product communicates. A user who learns that "Check your email format" means they need to add an @ sign will be confused when a different error in the same product says "Invalid value" for the same issue in a different form.
Treating error messages as a shared content layer -- with a style guide or at minimum a shared review process -- produces consistent language across the product. Users who encounter one well-written error message have calibrated expectations for how the next one will behave.
Turning Error Messages Into a Design Asset
Treating error messages as a design asset means several things in practice.
First, inventory every error state in the product. This requires intentionally triggering errors: submitting invalid form data, disconnecting from the network mid-operation, trying to perform actions without required permissions. Most teams have never done this comprehensively.
Second, evaluate each error against the three criteria above: specific, actionable, human language. Error messages that fail any of the three criteria need revision.
Third, test error messages with real users. What is obvious to a developer is often not obvious to a user. Web accessibility guidelines also require that error messages be accessible to users with disabilities, which means testing with screen readers and checking that errors are communicated through means other than color alone.
For a comprehensive framework covering both error messages and the related problem of empty states, 137Foundry's design resources cover both in the article How to Design Error Messages and Empty States That Actually Help Users. The article includes patterns for different error types and a specific approach to designing empty states as positive experiences rather than edge cases.
The Web Content Accessibility Guidelines (WCAG) also specify requirements for how error messages must be communicated to assistive technology users, which adds a functional dimension to the design quality argument.
The Reframe That Changes Everything
The most useful reframe for error message design: errors are not failures of the product. They are transitions in a user's workflow. The user was doing something, it did not work, and they need to get to the next step.
An error message's job is to make that transition as smooth as possible. Done well, a user encounters an error, reads the message, takes the indicated action, and moves forward with minimal friction. Done poorly, the same user encounters an error, cannot understand why, has no clear next step, and leaves.
The features of your product are what you offer. The error messages are what you offer when the offering does not work. Both are part of the product experience.
Top comments (0)