Plan a reader session without giving away the answer

Choose the decision the session should inform

For a guide collection, ask whether suitable readers can identify a report’s declared period and distinguish a known count from an unavailable outcome. Specify the actual guide version, relevant reader context and observation needed. Do not ask the session to prove overall business value from a small convenience set, or promise a representative population estimate from a few willing people.

GOV.UK describes moderated testing as observing actual participants attempting specific tasks, with neutral task goals. It is historical service-design guidance, not evidence that this journal completed a study or that one universal number of sessions is enough. Our plan is an original draft; no reader has been recruited, enrolled or observed for these examples.

Prepare a legitimate, usable session

Before real participation, provide the actual owner, purpose, expected activity, use of notes/recordings, access, retention and withdrawal/stop arrangements in an accessible form. Recording needs its own actual permission; willingness to try a guide is not permission to publish someone’s face or quotations. Collect only necessary context, not diagnoses, private platform credentials or a customer archive.

Check the actual device, assistive setup, language, materials and connection with the participant where appropriate. Use permitted practice data when a task does not need real personal material, and state the resulting context limits. Rehearse the technical route separately. A colleague rehearsal can find a broken task, but it is not an eligible-reader result unless the real protocol establishes that role.

Use a complete two-task discussion guide

Constructed introduction: “We are checking this guide, not testing you. Please work as you normally would and tell us what you are looking for if you are comfortable doing so. You may pause, skip or stop. The actual information and recording choices are provided separately.” This wording must match the real process before use; it does not itself establish consent or secure handling.

Task T1: “You need to describe which dates this report covers. Use the supplied guide and tell us the period you would report, or what remains unknown.” Task T2: “You need to explain whether the supplied request count establishes that people finished reading. Show which evidence supports your answer.” Moderator notes define the intended source version and acceptable evidence separately; the participant script does not say “click the period link” or disclose the conclusion.

Resolve three session-design mistakes

U1 — Constructed cue: the task tells a reader to open a named tab and select the correct value. Decision: state the actual reporting goal and remove the route hint. Outcome: a revised task, not newly observed findability or success.

U2 — Constructed rescue: a facilitator gives the decisive answer after the reader gets stuck. Decision: record assistance and what happened next; do not label the result independent completion. Outcome: useful diagnostic context without inflating the task-success numerator.

U3 — Constructed early exit: a participant chooses to stop before the task outcome is observed. Decision: respect the actual stop/withdrawal arrangement and preserve an appropriate stopped or unobserved state. Outcome: no forced failure, invented preference or silent replacement with a simulated person.

Keep observation, assistance and interpretation apart

Record actual task, route, words or actions needed for interpretation, assistance, result and unresolved evidence. Use declared states such as completed without help, assisted, not completed, stopped and unobserved. They answer different questions. A correct answer supplied by the moderator is not an unassisted success; “looked happy” is not an explicit preference.

Pause observation when the person asks, sensitive material appears unexpectedly or the essential access route fails. Do not press for a private account action merely to finish the script. If comparing versions, preserve the actual assignment/order and instructions under the appropriate protocol. This guide does not alter this journal’s separate registered five-task study, bodies, cohort or version.

Keep a plan and an honest result boundary

The private record covers learning question, eligible context, actual information/permission, source/version, neutral tasks, evidence criteria, environment, moderator/observer, assistance/stop rules and actual result. The packet contains the complete introduction and tasks. Local assertions check declared task IDs and outcome labels, not real participants, consent, completion, learning, accessibility or preference.

Primary guidance was read on 1 November 2026. All U-cases and scripts are constructed. No session, recording, recruitment, message or study was conducted. Technical browser QA remains technical evidence; a future eligible reader study needs actual voluntary participation and its own suitable analysis.

1. Define the learning question, source version and eligible context.
2. Prepare actual information, permission and access arrangements.
3. Write neutral tasks and separate observer criteria.
4. Declare assistance, stop and outcome states before observation.
5. Record real behavior without substituting technical QA or simulated readers.