Field note: Design the awkward states first
The character of a product shows up when something goes wrong. A useful next step, preserved work, and a clear explanation earn more trust than a perfect first screen.
- GOV.UK recommends keeping the answers a person entered when a form has validation errors.
- Its guidance distinguishes a mistake in an answer from a service problem or an eligibility decision.
- WCAG 2.2 explains how status updates can be announced by assistive technology without moving keyboard focus.
An editorial field note, published 26 September 2026, based on established design guidance reviewed for this edition. These sources are not new announcements. Their value is practical: they make the less photogenic parts of a product easier to build well.
An empty search, interrupted save, or rejected form is still part of the experience. When the interface loses someone’s work or leaves them guessing, a beautiful layout cannot repair that loss of trust.
Choose one journey you are shipping. Sketch its empty, waiting, success, invalid-input, and service-failure states. For each, write what the person knows, what work is retained, and the next action available. Walk through it using only a keyboard, then check how a screen reader announces updates.
Put it to work 20 minutes
A five-state sketch for one real product journey
Spend two minutes choosing one form or search flow, 15 minutes sketching its empty, waiting, success, invalid-input and service-failure states, then three minutes checking the recovery. Write what the person sees, what work is retained and the next action for each state.
See a worked example
Illustrative example: signing up for a job alert. These are proposed interface states, not results from a user test.
- The journey
- A job seeker enters an email address to receive a weekly design-role alert.
- Empty
- “Get design jobs every Monday.” An empty email field and “Create alert” button make the next action clear.
- Waiting
- The email remains visible. The button reads “Creating alert…” and ignores repeated clicks while the request is pending. A status message announces progress without moving focus.
- Success
- “Your alert is ready. Look out for your first email on Monday.” Keep the entered address visible so the person can spot a typo and choose “Change email”.
- Invalid input
- “Enter an email address, like [email protected].” Retain the typed value, connect the message to the email field and move focus to the error summary after submission.
- Service failure
- “We couldn’t confirm your alert. Try again.” Keep the email. Retrying must check for an existing alert before creating another. Verify this behavior with a simulated lost response.
Your turn
Name one task and the result the person wants.
Explain how to begin. Leave room for input without showing an error before an attempt.
Show that the request is in progress and prevent accidental duplicate submission.
Confirm what succeeded and what happens next.
Name the problem beside the input and make it easy to correct.
Preserve the work and explain a safe recovery. Flag behavior that still needs testing.
Your draft stays in this browser. No account needed.
Adding messages to every minor update creates noise. Announce changes that matter to the task, and test the result with the people using it.
Primary accessibility and service-design guidance supports the patterns; the specific wording and flow still need testing with your users.
Can someone recover from the failed state without help or re-entering their work?
Watch: Observed recovery attempts · Keyboard and screen-reader checks