Error Recovery: Protect the Work and the Way Forward
Turn errors into local, recoverable moments instead of vague page-level uncertainty.
Start with the moment where the interface asks too much.
Eleven fields are complete. The user submits. The page jumps to the top and says, “Something went wrong.” The fields may still be saved, or they may not. The problem may be one value, the network, the server, or the user’s account. A correctable issue has become a full-page mystery.
Recovery is part of the primary experience. A useful error identifies what happened, localizes the problem, protects valid work, explains the next step, and matches confirmation to consequence.
Show the failure and the correction.
The lab uses controlled markup instead of raster text so the lesson stays legible, accessible, and easy to revise.
Vague banner
A page-level error appears without field location or recovery path.
Validate near the field
Show correctable issues beside the control and link summaries to the right place.
Make the useful path easier.
Problem, place, protection, path
The message should say what failed, where attention is needed, what work remains safe, and what the person can do next.
Prevention before messaging
Input modes, examples, constraints, and timely validation reduce error frequency before recovery copy is needed.
Not every error can reveal everything
Security and privacy sometimes limit detail. The interface can still provide a safe next step without exposing internal infrastructure or account existence.
Turn critique into a usable rule.
Remove
Vague banner
A page-level error appears without field location or recovery path.
Reset work
Valid values disappear after a failed submit.
Raw internals
A technical code becomes the primary message instead of support detail.
Build
Validate near the field
Show correctable issues beside the control and link summaries to the right place.
Preserve what is valid
Do not make people re-enter correct work because one part failed.
Match recovery to cause
Invalid input, expired session, conflict, network failure, and server failure need different paths.
Use it on a real page.
Force common error classes in a safe local or staging environment.
Submit invalid input.
Interrupt the network.
Trigger duplicate submission.
Expire session or permission.
Retry after server rejection.
- Use screenshots and preserved-input checks.
- Users can recover without re-entering valid work or guessing system state.
- Errors are vague, far away, destructive, or technically exposing.
The rule should help the person making the next decision.
Business owner
Review errors as trust moments, not edge-case copy.
Designer
Design prevention, inline guidance, summary, preserved state, and retry.
Developer
Use validation, idempotency, and clear server responses so recovery is truthful.
QA
Trigger invalid input, duplicate submit, expired session, network failure, and server rejection.
Security and privacy may limit detail. Provide enough information to recover without exposing whether an account exists, revealing infrastructure, or leaking sensitive data.
Check the page, then answer the doubt.
- Errors identify the problem.
- Errors identify the place.
- Valid work is preserved.
- Focus moves logically.
- Retry is safe.
- Security-sensitive errors avoid leaking detail.
- Undo or confirmation matches consequence.
- Should validation happen before form submission?
- Correctable formatting and required-field issues should appear early enough to prevent avoidable full-form failure.
- What makes a good error message?
- It is specific, local, respectful, and tied to a clear recovery path while preserving valid work.
- Can errors be accessible to screen readers?
- Yes, when labels, descriptions, summaries, focus movement, and announcements are implemented carefully.
Standards and research links support the factual parts of the rule. They do not replace original judgment on the page.
Use the rule on the page that matters.
Use this when the reader is likely comparing redesign, UX cleanup, or launch support.
Start a project