Write from the system’s actual state and an action that can be completed. Review the message alongside its field, retained data and response after retrying.
Identify what kind of problem occurred
An empty field, an unsupported format and a service interruption require different responses. Before writing, ask the team what the system detected and what is known about submission. If it cannot confirm whether the request was saved, the message needs to preserve that uncertainty and offer a way to check.
In a fictional shop, a form collects information to prepare a sample. “Something went wrong” leaves a person unsure whether to change an entry or wait. The first editorial task is turning a technical state into an understandable situation without publishing unnecessary internal details.
Connect the instruction to its field
These original examples assume fictional rules that the service would need to enforce. Wording must change when a rule changes; copying it without reviewing the form can create another contradiction.
| State | Proposed message |
|---|---|
| Project name is missing | Enter the project name. |
| File exceeds 5 MB | The file must be 5 MB or smaller. Choose a smaller version. |
| Selected date is in the past | Choose a delivery date after today. |
GOV.UK recommends using the label’s wording and explaining how to correct the error. Check that the person can find the named field and that the instruction corresponds to an available action.
Keep the voice clear during difficulty
Humor can hide an instruction or feel strange when someone fears losing work. Try a direct sentence before adding personality. “Check the file” remains ambiguous: explain which condition prevents its use and which alternative the process accepts.
For a service failure, avoid attributing the problem to the person. A fictional response could say: “We could not confirm submission. Keep this screen and check the status using the reference shown.” This option works only if the screen and channel actually support it. Good wording needs an operation behind it.
Review what remains after an error
Back on the form, are earlier answers still there? Does the message remain near the correct field? Can someone locate it without relying only on color? GOV.UK’s pattern retains answers when showing errors. Implementation also needs a review of labels, associations and navigation.
W3C explains that when an error is detected and correction suggestions are known, they are provided unless doing so compromises security or the content’s purpose. That condition matters: do not reveal account information or invent a correction the system cannot know.
Test a complete recovery journey
Prepare fictional inputs for states the team recognizes: empty, incorrectly formatted, oversized file and an interruption simulated in a test environment. Ask someone to explain what happened and try continuing. Record where they hesitate, what is retained and what the system confirms at completion.
This exercise evaluates comprehension and behavior in those cases. It does not by itself establish complete accessibility or increased conversions. Our customer journey map then places this recovery within the broader experience.
Keep the message and rule together
- Detected state and available evidence.
- Affected field or service area.
- Approved wording and translations.
- Available action and retained data.
- Observed retry result and review owner.
Keep the record when limits or validation rules change. A brand promise guides the experience you want to offer; this review checks a sentence and its practical consequence. Begin with one documented frequent error before changing every message.
Follow the evidence.
Sources checked October 19, 2026. Illustrative scenarios and numbers are fictional. The records and exercises are original editorial proposals, without attributed customer results or provider tests. Our editorial standards.
