Research methods workshop / 5 MIN READ
Give the participant a goal and the moderator a protocol
Prepare a task-based usability session that preserves the difference between independent action and moderator help.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
A moderated usability session places a participant in a defined task with a product or service. The protocol should create a meaningful attempt, protect the participant and leave a clear record of what the interface enabled before the moderator intervened.
What you will leave with: A moderated task protocol with starting state, intervention rules and observation fields.
Use this when
- A team needs to understand how people use a proposed interface.
- A prototype is ready for structured task attempts rather than general opinions.
This is not naturalistic workplace observation, a performance assessment of participants or a statistical usability benchmark.
Define the task and its starting conditions
GOV.UK describes moderated usability research as observing participants attempting specified tasks. Choose a concrete goal that can reveal the uncertainty the team needs to understand.
Describe the situation and desired outcome without naming the interface control that would complete it. Identify the starting screen, permitted materials and relevant prototype version. Make the scenario understandable to the intended participants. If the task depends on an experience they do not have, reconsider the recruitment or scenario rather than asking them to imitate an unfamiliar professional role and treating the result as ordinary use.
Protect the attempt from unintended real-world consequences
Decide what accounts, records and actions the participant can safely use. Prefer approved test arrangements when real activity could send a message, spend money or change a live service. Make the boundary explicit before the task starts.
Check how the prototype behaves outside its main path. A link that leaves the test environment can create confusion or expose unrelated information. Have a safe stopping point and a clear way to reset the task. Do not ask participants to reveal passwords or confidential employer material to make the scenario feel realistic. Record the limitations of the test setup so later readers know what context it could not reproduce.
Agree how the moderator will intervene
Explain that the service is being examined and the participant can stop. Let the person attempt the goal while the moderator observes and uses neutral prompts where needed. Define when a clarification, hint, reset or stop is appropriate.
Record each material intervention and what happened before it. If the moderator points out a hidden button, subsequent completion cannot demonstrate that the button was independently discoverable. Helping someone continue can still produce useful learning about the next stage, provided the assistance remains visible. Avoid repeatedly rescuing the design or praising actions that reveal the team’s preferred route.
Review the task evidence within its limits
Capture the participant’s actions, explanations, pauses and recovery attempts alongside the actual system state. Separate a prototype defect, misunderstood scenario and interface problem where the evidence permits; preserve uncertainty when it does not.
Ask follow-up questions about observed moments without teaching a new interpretation and then recording it as the participant’s original view. Link findings to the task and setup rather than claiming all users will behave identically. Revise the protocol if an avoidable instruction problem prevents learning, and record the change. The deliverable is a traceable account of a meaningful task attempt, including the researcher’s influence on it.
Make the reasoning concrete.
A fictional participant is asked to reschedule a booking in a prototype. After a long search, the moderator says to use the menu beside the date, and the participant completes the change.
Record unqualified completion
Opening: Mark the task complete and omit the hint.
Hypothesis: The result looks straightforward.
Risk: It hides the discoverability problem that required assistance.
Preserve the intervention boundary
Opening: Record the search, hint and assisted continuation separately.
Hypothesis: The team can improve entry to the flow and still learn about later steps.
Risk: The evidence supports a narrower conclusion than effortless independent completion.
The researcher reports that the participant continued successfully after a specific hint. The next design review addresses the entry-point problem without blaming the participant or overstating what the session established.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Goal
What meaningful outcome should the participant attempt?
Setup
Which version, start state and safe materials will be used?
Intervention
When may the moderator clarify, help, reset or stop?
Record
How will assistance and system limitations remain visible?
Interpretation
What does this task attempt support, and what does it leave unknown?
Watch for the wrong conclusion.
- Giving the interface answer inside the task wording.
- Letting a research task trigger unintended live actions.
- Reporting assisted completion as independent discovery.
Your next action
Write one task protocol and rehearse how you will record a hint without erasing the difficulty that prompted it.
Sources & scope
The workflow, worksheets and hypothetical examples are original editorial analysis. Sources support only the identified principles. No measured business results or named human reviewer are claimed.
- GOV.UK Service Manual: Using moderated usability testing →Primary government research guidance · Supports: Moderated usability research observes participants attempting specified tasks; the intervention and evidence-boundary protocol is original editorial analysis.