Most applications handle the happy path deliberately. Every form submission, every API call, every navigation event gets thought through. Error states get a fraction of that attention, usually added at the end of a sprint, often written by developers who are primarily thinking about logging rather than user experience.
The result: a product where success is smooth and failure is inconsistent, cryptic, or both. Fixing this requires a systematic audit, not a patch-on-demand approach. Here's how to do one from scratch.
Why Error Audits Are a Separate Project
You might think error message quality is caught during QA. It's usually not. QA tests for functional correctness: does the form reject invalid emails? Does the error appear at all? The user experience of the error message is a different question entirely: is the message specific? Does it tell the user what to do next? Is it written in plain English?
These are quality dimensions that require intentional evaluation. Functional correctness and UX quality overlap but don't cover each other. An error message can be technically correct (the right error, shown at the right time) and still be a UX failure ("Error 400: Bad Request").
Step 1: Map Every Surface Where Things Can Go Wrong
Start by listing every user action in your application that could produce an error. This is not the same as listing error messages you've already written. It's a comprehensive map of failure surfaces.
Group them into categories:
Form validation errors cover every field in every form: required fields left empty, values in the wrong format (email, phone, date), values that fail business rules (password too short, username already taken, amount below minimum).
Authentication errors cover wrong password, expired session, locked account, insufficient permissions for the requested action.
Network and system errors cover request timeouts, server errors (5xx responses), connection failures, service unavailable states.
State errors cover actions taken at the wrong time: editing a record that was deleted by another user, submitting a form twice, attempting an action that requires a completed prerequisite.
Empty states are a special category of error-adjacent state: no results from a search, no items in a cart, no activity in a feed. These aren't errors caused by failure, but they require the same kind of guidance.
Work through the application feature by feature and add everything to a spreadsheet. For most applications, this produces 30 to 80 distinct failure surfaces.
Step 2: Trigger Every State Deliberately
Once you have the map, systematically trigger each failure state. This sounds obvious, but it requires intention -- most error states require specific setup to reach.
To trigger form validation errors: submit forms with each field empty, with values in the wrong format, with values that violate business rules (one at a time, so you see exactly which error appears for each).
To trigger authentication errors: use wrong credentials, let sessions expire (or manually clear session cookies), attempt restricted actions while logged in as an unpermissioned user.
To trigger network errors: use browser DevTools to throttle connections to "Offline" or "Slow 3G" mid-operation. Attempt operations while the network is cut. Browser DevTools provide network throttling controls that make this straightforward.
To trigger state errors: requires more setup -- use multiple browser tabs, manipulate database state directly in a test environment, or write targeted test scripts.
Document every failure state you trigger with a screenshot. The screenshots serve two purposes: they're evidence for your audit findings, and they let you compare current vs. revised messages after you fix them.
Photo by Marcial Comeron on Pexels
Step 3: Evaluate Each Message Against Three Criteria
For each error state you've triggered, evaluate the message against three criteria:
Is it specific? Does the message tell the user exactly what went wrong, not just that something went wrong? "An error occurred" fails this. "Your email address is not in the correct format" passes.
Does it point to next steps? Does the message give the user a clear action to take? "Your session has expired" fails this. "Your session has expired. Sign in again to continue." passes.
Is it written in plain language? Would a non-technical user understand it immediately? Technical error codes and developer-facing messages fail this unless they're accompanied by a plain-language explanation.
Use a scoring approach: mark each error message as Pass, Partial (needs improvement), or Fail on each criterion. This gives you a prioritized list: messages that fail all three criteria need complete rewrites; messages that fail one need targeted improvement.
Step 4: Check Accessibility
An error message that users can read visually may be completely inaccessible to users who rely on assistive technology. The Web Accessibility Initiative provides guidelines that apply directly to error messages.
The practical checks:
Error messages must not rely on color alone. "The field outlined in red" communicates nothing to users with color blindness unless the message is also repeated in text near the field.
Error messages must be associated with their fields programmatically. Screen readers read what the DOM says, not what visually appears nearby. WebAIM covers the technical requirements for linking error messages to inputs using aria-describedby and aria-invalid attributes.
Dynamically inserted errors must be announced. When an error message appears after a form submission, it needs to be in an ARIA live region or focus must move to the error so screen reader users hear it.
Run your application through a screen reader (VoiceOver on macOS/iOS, NVDA on Windows) and try triggering errors. What you hear is what screen reader users experience.
"Error states are where accessibility and usability overlap most visibly. An error message that a screen reader can't announce is a broken user journey for a meaningful share of your users -- and it's one of the most fixable categories of accessibility failure." - Dennis Traina, founder of 137Foundry
Step 5: Prioritize by Impact
Not all error states are equal. Prioritize fixes based on two factors: frequency and conversion impact.
High-frequency errors (login errors, common form validation failures) affect the most users and should be fixed first. High-conversion-impact errors -- errors that appear during checkout, signup, or other key flows -- should also be front of the queue even if they're less frequent.
An error audit will typically produce 20 to 40 items that need fixing. Trying to fix everything at once is impractical. A prioritized list makes it a project you can actually ship.
Step 6: Fix, Then Test with Real Users
Write revised error messages based on your audit findings. For each revision, check:
The specific cause is named. The next action is explicit. Technical jargon is replaced with plain language. Blame language is neutralized (use "Check that..." instead of "You entered...").
WCAG 2.1 Success Criterion 3.3.1 requires that input errors be identified in text and described to the user. Criterion 3.3.3 requires that error correction suggestions are provided where possible. Your revisions should meet both.
After revising, test with users who were not involved in writing the messages. Developers and designers become blind to their own copy quickly. A user who has never seen the interface will tell you immediately whether a message makes sense.
The A11Y Project maintains a checklist that covers error-related accessibility requirements alongside other WCAG criteria, useful for validating fixes.
Making Error Audits Routine
A one-time audit fixes what exists today. An ongoing process catches new errors before they ship.
The most effective ongoing practice: add error states to your definition of done for every feature. When a feature adds a new form, the developer lists every validation error and writes the message text before the feature is considered complete.
The second-most-effective practice: include error state screenshots in design specs. When designers spec a component, they show the default state, the hover state, the focused state, and the error state. If the error state isn't in the spec, the developer has to invent it.
For a comprehensive set of error message patterns covering both form validation errors and system errors, 137Foundry's design resources include the article How to Design Error Messages and Empty States That Actually Help Users, which covers pattern selection for different error types and how to design empty states that give users somewhere to go.
Error message quality is not a bonus feature. It's part of your product. Treat the audit as product work, and you'll ship a product that handles failure as well as it handles success.
Top comments (0)