THE SHORT ANSWER
Design a simple user journey as ENTRY → ACTION → RESULT → RETURN. Define why the user arrives, the smallest sequence needed to complete the goal, the feedback that confirms progress, the errors and empty states that need recovery, and what brings the user back when repeat use matters.
Map the outcome before the screens
| Stage | User question | Product responsibility |
|---|---|---|
| Entry | Am I in the right place? | Set context, promise and eligibility |
| Action | What do I need to do? | Present the next clear task |
| Result | Did it work? | Confirm outcome and explain next steps |
| Return | Why and how would I come back? | Preserve useful state and continuity |
Design the states around the happy path
- First-use and onboarding state
- Empty state before data exists
- Loading or processing state
- Validation state with a specific correction
- Permission-denied state
- Temporary service failure
- Successful completion and receipt
- Return state with saved context
A journey is incomplete if the only designed route assumes perfect input, connectivity and permission.
Remove friction that does not protect the outcome
Every field, decision and navigation step should have a reason. Some friction is necessary: confirming a destructive action or reviewing payment details can protect users. Unexplained repetition, hidden requirements and vague errors simply consume attention.
Check headings, labels, keyboard focus, contrast and zoom early rather than adding accessibility after the journey is fixed.
Evidence & context: W3C Web Accessibility Initiative
Test the journey before building the system
Walk a paper or clickable prototype with likely users. Ask them to pursue a goal without coaching, observe where the next step is unclear and separate interface confusion from an incorrect product assumption.
Use the findings to revise the product requirement and later compare observed product behavior through funnel analytics.
Evidence & context: GOV.UK Service Manual
Sources & further reading
- Learning about users and their needs
GOV.UK Service Manual. Public-service design guidance linking user needs to stories, acceptance criteria and continued research. Its process should be adapted to the product and risk context.
- Making prototypes
GOV.UK Service Manual. Guidance on choosing prototype fidelity to explore and test ideas. It explicitly distinguishes prototype code from production-ready software.
- Easy Checks — A First Review of Web Accessibility
W3C Web Accessibility Initiative. A first-pass accessibility review covering titles, headings, contrast, keyboard focus, labels and zoom. Passing these checks is not comprehensive conformance testing.
Examples and exercises are illustrative unless attributed to a source. No independent expert review is claimed.
A correction, a counterexample or an experience worth sharing?
Join the conversation ↗