Practical framework / 5 MIN READ
Write interface errors that support recovery
Connect each detected failure to a truthful explanation and a safe action the reader can actually take.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
An error message should help someone recover without guessing what happened or repeating an action with uncertain consequences. The writer needs the actual system failure states before choosing reassuring language.
What you will leave with: Leave with an error-to-recovery matrix that separates user-correctable input from service failures and unknown outcomes.
Use this when
- A form repeatedly says something went wrong.
- Readers lose work after a validation failure.
- A retry instruction may duplicate a consequential action.
This is interface-state writing, not a troubleshooting article, support-ticket routing plan or permission to expose sensitive diagnostic details.
Map the failure before writing the message
Ask the implementation owner what the system knows at each failure point. Separate missing input, rejected format, unavailable service and an action whose outcome is uncertain. Record whether any data was saved and whether repeating the action is safe. A generic failure message can conceal important differences between nothing happened and the response was lost after completion. Do not invent a cause to make the copy sound helpful. Build a matrix with the trigger, known state, reader consequence and available recovery action before writing the final message for each case.
Give a correction when it is known
W3C's error-suggestion criterion calls for known correction suggestions for detected input errors, subject to security and purpose limits. Explain the relevant requirement in ordinary language and connect it to the affected field or action. Tell the reader what to change without blaming them or repeating an opaque technical code as the whole explanation. Keep useful entered information where the system can do so safely. If revealing the exact reason would expose protected account information, work with the security team on a safe explanation rather than applying maximum specificity indiscriminately.
Make retry and escalation truthful
Offer retry only when the system can support it safely and explain any known delay or prerequisite. For an uncertain outcome, provide a status-check route before encouraging another attempt. If the reader cannot fix the problem, say what useful option remains and what information a support contact will need, without exposing internal stack traces or private identifiers. Do not promise an immediate response from a channel that is not staffed accordingly. Where an error blocks a deadline-sensitive task, have the responsible service owner decide the authorized alternative rather than letting the writer improvise a policy exception.
Test the full recovery path
Trigger each error safely in a test environment and inspect its placement, visibility and accessibility with the implementation team. Confirm that the proposed action works, the reader can return to the relevant input and the message changes when the state changes. Test more than one simultaneous error and a repeated failure. Record exact conditions and expected outcomes so future changes can be checked. Ask a reader unfamiliar with the system what they would do next. If their action differs from the intended safe recovery, revise the message or the interaction rather than assuming they failed to read carefully.
Make the reasoning concrete.
A hypothetical document-submission service reports an error after a user uploads a file.
Unsafe generic retry
Opening: The message says upload failed, try again even though the server may have stored the file.
Hypothesis: The instruction appears straightforward.
Risk: A second upload may create duplicate submissions while the first outcome remains unknown.
State-aware recovery
Opening: The service distinguishes rejected file type from an unconfirmed upload and offers the appropriate correction or status check.
Hypothesis: The reader has a safe next step based on what is known.
Risk: The message must match actual backend behavior rather than an editorial assumption.
The team tests both states and approves separate messages only after the recovery paths are verified.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Trigger
What exact condition produces this error?
Knowledge
What is known about saved data and completed actions?
Recovery
What can the reader safely do next?
Protection
What explanation would expose sensitive information?
Verification
How will the failure and recovery be reproduced safely?
Watch for the wrong conclusion.
- Inventing a cause for an unknown failure.
- Encouraging retry when the action may already have completed.
- Blaming the reader for a service problem.
- Testing message appearance without testing recovery.
Your next action
Build an error-to-recovery matrix for one form and verify the next action for its three most consequential failure states.
Sources & scope
The framework, examples and suggested checks are original editorial synthesis. Hypothetical examples are not measured results. Source checking is not an independent audit or a guarantee of business outcomes. No named human reviewer is claimed.
- W3C WAI: Understanding SC 3.3.3, Error Suggestion →Primary publisher guidance · Supports: Supports known correction suggestions for detected input errors, with security and purpose exceptions. The recovery matrix is a focused content tool, not a full accessibility audit.