The question: Can someone who does not understand the implementation complete a task without you coaching every click?
Before you begin: At least one project runs, stops and recovers, with synthetic demonstration data and a clear data explanation.
- 01Obtain consent
- 02Observe a task
- 03Fix one obstacle
- 04Hand over clearly
Concepts and learning objectives
The next step is testing whether another person can use your understanding, not growing a user base. Invite one consenting person to attempt a realistic task using synthetic data. They can stop and need not provide private information. If nobody is available, revisit an unfamiliar task yourself after a delay and label this as weaker self-testing.
Observe where they hesitate, misunderstand, avoid a control or struggle to recover. Constant coaching hides problems. A handoff needs startup, data flow, cost, limits, stopping and recovery, not just a product introduction. Do not infer universal needs from one person's preferences.
Reading and selected sections
| Priority | Source and selected sections | Budget |
|---|---|---|
| Required | R75 · GOV.UK — Moderated usability testing — Task design, moderation and observation. | 40 min |
| Required | R76 · GOV.UK — Getting users' consent for research — Purpose, recording scope, withdrawal and informed consent. | 30 min |
| Optional | R08 · MIT — Beyond the Code — Maintenance, collaboration and handoff. | 35 min |
Studio lab
- Write a plain invitation: purpose, expected time, synthetic data, recording scope and how to stop. Obtain separate consent before audio, video or contact collection.
- Give a goal such as arranging three activities and checking an export, rather than a button-by-button script.
- Record observations: pauses, mistakes, questions and recovery. “The user is not technical” is not an actionable finding.
- Fix the biggest obstacle only, then check with the person or a fresh synthetic task.
- Write a one-page handoff covering startup, data destinations, cost, limits, export, clearing, stopping, recovery and version. Public feedback must be an agreed anonymous summary.
Deliverables and acceptance
| Deliverable | Evidence of completion |
|---|---|
| Consent and observation plan | Defined records and withdrawal without private-data requirements. |
| Real feedback or stated alternative | External observation distinguished from self-testing; no fabricated endorsement. |
| Handoff guide | A newcomer can start, stop and respond to errors. |
Independent exercise: Rewrite one misunderstood message yourself and test a new scenario. More words are not necessarily clearer.
Privacy and safety: Removing a name does not guarantee anonymity; role, timing, tasks and screenshots may identify someone. Prefer synthetic reconstructions over transcripts or recordings. Workplace trials require their own organisational approval.
Everyday use: Notice whether the tool reduces explanation. Your future self is also a second user who needs to understand, repair and retire it.
Pass or revisit: Observe and improve one important problem and produce a usable handoff. State recruitment limitations honestly.
A reusable collaboration prompt
Design a single-task usability observation with synthetic data and clear consent, recording and withdrawal. Observe rather than coach. Fix the main obstacle and create startup, data, stop and recovery guidance. Do not invent user feedback.
Sources and verification scope
Reference IDs and scope follow the supplied manuscript, baseline 2026-09-27. External authenticated labs were not all completed; recheck versions and access before implementation.
- R08MIT — Beyond the Code ↗
2026 notes; maintenance and handoff supplements.
- R75GOV.UK — Moderated usability testing ↗
Task observation and recording.
- R76GOV.UK — Getting users' consent for research ↗
Consent questions; not a substitute for local legal advice.