Test a journey with users
A useful test asks a relevant participant to complete a task without being told where to click. Observe, record obstacles and test corrections afterwards. Aesthetic preferences and task completion answer different questions.
Choose an observable task
Start with a need: finding an appropriate resource, understanding an offer or sending an enquiry. Specify the starting point and what counts as success. Asking someone to explore the website provides no common completion criterion.
Describe a understandable situation without naming buttons or sections. Use test data, a prototype or an environment that triggers no real payment or message. Distinguish prototype limitations from journey defects.
Recruit relevant participants
Recruit according to important uses: domain knowledge, device, language and access needs. Colleagues familiar with the site structure may not represent visitors. Explain what will be observed and recorded.
Make sessions compatible with participants’ capabilities and availability. A few observations may reveal obstacles worth fixing, but do not automatically provide population-level estimates. Preserve recruitment limitations in the report.
Observe without steering
If appropriate, invite participants to explain what they seek and understand. Let them try. Neutral questions such as what they expected at a particular point help reveal confusion; instructions to use the correct button hide it.
Record task, completion, assistance, detours and interpretation. Separate observation from hypothesis: failure to find a filter is observed; insufficient contrast is a possible explanation to examine. Avoid collecting real credentials or unnecessary private information.
Fix and test again
Prioritise by task severity, affected audience and scope. A defect preventing form submission will often precede a colour preference. Connect each action to an observation and an expected outcome.
After changes, repeat the tasks and relevant accessibility checks. User testing does not replace technical or compliance auditing. Preserve conflicting observations and unresolved uncertainty instead of converting a few responses into certainty.
A record to keep with the decision
| Item | Evidence |
|---|---|
| Scenario | Situation, task, starting point and success criterion. |
| Sample | Represented uses, recruitment and limitations. |
| Observation | Outcome, assistance, obstacle and evidence without unnecessary personal data. |
| Correction | Priority, owner and repeat-test result. |
Download the worksheet to fill in (CSV)
Frequently asked questions
How many participants are needed?
It depends on the question, diversity of uses and method. Begin with focused sessions to identify problems; expand when the decision requires a representative quantitative estimate.
Must sessions be recorded?
Only where useful and understood by participants. Structured notes may suffice. Specify access, retention and deletion of recordings before beginning.
Reference material
GOV.UK Service Manual — Using moderated usability testing
W3C WAI — Involving users in evaluation
W3C WAI — Clear and understandable content
The practical checklist is an editorial synthesis to adapt to your service. It does not constitute a certification or an audit result.