UX Error Messages: Writing Clear, Actionable Recovery Copy
An error message appears when a user’s task has already been interrupted. The copy can either help them recover or make the interruption harder to understand. “Invalid input” identifies a system state; it does not tell a person what needs to change or whether their work is safe.
Effective error writing is part of interaction design. It depends on what the system knows, what the interface can preserve, and what recovery options actually exist. Copy cannot repair a confusing validation rule or a backend failure that discards user data.
Explain the problem in user terms
Say what failed and where, using the language of the task. “We couldn’t save your changes” is more useful than “Error 500.” A technical code may help support teams, but it should not be the only information shown to a customer.
Be specific when the system has reliable information. For example, “This file is larger than the 10 MB limit” helps the user act; “File error” does not. Do not guess at the cause when the system cannot distinguish between a network issue, a permission problem, and a service outage. In that case, state what is known and offer a safe next step.
Avoid blaming language such as “You entered this wrong.” Describe the requirement neutrally: “Enter a date after today.” The goal is to explain the system’s expectation, not judge the person.
Pair each error with recovery
Every error should answer: What can I do now? The next step might be correcting a field, selecting a supported format, trying again, contacting support, or waiting for the service to recover.
Make the recovery action concrete. “Check your connection and retry” is useful only if a retry is safe. If the request might already have succeeded, first help the user check its status so a repeated action does not create duplicate payments or records.
Do not offer a button that cannot resolve the problem. A generic “Try again” can be frustrating when the issue requires a different permission or data. If a failure is outside the user’s control, explain that the service is unavailable and provide a realistic alternative.
Preserve the user’s work
Errors should not erase valid entries. Keep form values when validation fails, preserve a draft after a network interruption, and retain successfully uploaded files when one item in a batch is rejected.
If work cannot be preserved for technical reasons, state that clearly before the action when possible. For high-impact steps, consider autosave or a review checkpoint so a transient error does not force the user to start over.
Place errors where they can be found
For a single field error, put the message near the field and associate it programmatically so assistive technology can identify the relationship. For a long form with multiple errors, provide a summary at the top and links to the affected fields. When submission fails, focus the summary or the first invalid field in a predictable way.
Do not use color as the only signal. Combine text with an icon or border when appropriate, maintain sufficient contrast, and ensure the message remains visible in different zoom and viewport conditions.
For asynchronous errors, announce the change without unexpectedly moving focus. A status message that appears below the submit button should be discoverable to screen-reader users as well as sighted users.
Match tone to the moment
The tone should support the user without minimizing the problem. A failed payment or lost connection is not the time for jokes. A light tone may suit a harmless typo, but clarity remains more important than personality.
Apologize when the product has caused a genuine problem, but do not use “Sorry” as a substitute for explaining what happened. Avoid exaggerated reassurance such as “Everything is fine” when the system cannot confirm the status.
Error-writing pattern
A useful message often contains three parts:
- What happened: name the failed action or field.
- What it means: give the relevant reason if known.
- What to do: provide a safe, specific recovery step.
Not every error needs three sentences. A concise message can cover all three parts when the cause and action are simple. For a service outage, it may be better to say that the action did not complete and that the user’s draft is saved.
Test recovery, not just comprehension
Ask participants to recover from the error and continue the task. Observe whether they know what to change, whether they trust that their earlier work remains, and whether the retry causes a duplicate. Include keyboard and screen-reader testing for inline and asynchronous errors.
Track repeated submission attempts, error recurrence, abandonment after failure, and support contacts. A low rate of visible errors may mean the system prevents problems, but it could also mean errors are hidden or unreported.
Error message checklist
- Does the message explain the failure in plain language?
- Is the affected field, file, or action identifiable?
- Does the user have a safe, actionable next step?
- Is entered work preserved where possible?
- Are retries safe and idempotent?
- Are errors visible and announced accessibly?
- Does the tone match the impact?
- Have people tested the complete recovery path?
An error message is useful when it restores a person’s ability to act. Clear language, preserved work, and a practical next step turn failure into a recoverable state.