Usability Testing Moderator Guide: Tasks, Prompts and Observation Notes

A usability testing moderator guide keeps a session focused on what a participant does, understands and expects while attempting realistic tasks. It helps the moderator remain consistent without becoming a script reader who ignores context.

The goal is not to prove that a design works or to measure the participant. The product is under examination. Moderators must preserve unaided behavior, mark assistance and report limitations so teams can make responsible decisions.

Define the study decision and task risks

Start with the product decision: identify blocking interaction problems, compare navigation approaches, assess comprehension or verify a revised workflow. Define which users, devices, contexts and product versions are in scope.

List task risks before recruitment. A test involving real accounts, payments, health information, destructive actions or live customer data requires controls beyond an ordinary prototype review. Use safe test data and environments wherever possible.

The research owner approves the plan, the moderator runs the session, the note-taker preserves evidence and the product decision owner acts on reviewed findings. Keep these responsibilities explicit.

Recruit and prepare without coaching

Recruit participants with relevant characteristics and recent experience. Avoid training them on the target interface before the test unless prior training is part of the real user context. Provide practical information about duration, device needs, accessibility, compensation and participation rights.

Run a technical check for prototype access, screen sharing, recording, audio, accounts and fallback materials. Reset data between sessions. The participant should not encounter another person’s information or a state altered by the previous test.

Use research interview recording guidance to prepare authorization, access and retention controls.

Write realistic, neutral tasks

A task should describe a goal in the participant’s language and provide only context they would reasonably have. Avoid naming a menu item, button or navigation route that the test is meant to evaluate.

Weak: “Click Export and choose PDF.” Better: “You need a copy of this report that a colleague can read without access to the system. Show me what you would do.”

For each task, record starting state, success evidence, critical errors, allowed data, timebox, assistance rule and stop condition. Pilot tasks to identify accidental clues and impossible setup.

Copy this usability testing moderator guide

USABILITY TEST SESSION

Study / build / device:
Participant reference:
Moderator / note-taker:
Recording and consent status:
Safety or escalation contact:

1. OPEN — 5 MIN
Purpose, rights, recording, think-aloud method and questions

2. CONTEXT — 10 MIN
Recent relevant experience, current tools and expectations

3. TASKS — 35 MIN
For each: starting state, goal, observation, neutral probes, assistance

4. REFLECTION — 10 MIN
Expected outcome, confidence, difficult points and alternatives

5. CLOSE — 5 MIN
Recap, participant correction, missing topics and next steps

TASK CARD
Scenario and goal:
Starting state:
Success evidence:
Critical issue / stop condition:
Allowed assistance:
Post-task questions:

Leave time between sessions for reset and debrief. Back-to-back scheduling encourages incomplete notes and contaminated test states.

Open the session and establish rights

Explain that the design, not the participant, is being evaluated. State the purpose, session format, recording status, access, retention, confidentiality limits and the right to pause, skip or stop. Obtain the required agreement before capture begins.

If using think-aloud, demonstrate with an unrelated example. Ask the participant to say what they notice, expect and are trying to do. Do not demand a constant narration that prevents natural interaction.

Confirm whether observers are present and how they may communicate. Observers should not contact or coach the participant during the task.

Present tasks consistently

Read the task as written and answer genuine context questions without revealing the route. If a participant asks what a label means, respond with a neutral probe such as “What would you expect it to mean here?” before deciding whether clarification is necessary.

Avoid praise that signals correctness. “Thank you, keep going” is safer than “Perfect.” Do not defend the design, blame the prototype or explain intended behavior while unaided observation is still valuable.

Record any deviation in wording, setup or assistance. Consistency supports comparison, but participant welfare and safe system use take priority over script purity.

Observe behavior and take evidence-ready notes

Capture what happened before interpreting why. Useful notes include the task step, action, visible system response, participant words, timestamp and assistance. Separate observation from inference in distinct fields.

Task / timestamp:
Observed action and system response:
Participant statement:
Moderator assistance:
Possible interpretation:
Evidence to verify:
Severity discussion owner:

The note-taker should flag exact quotations for later source verification. Use the qualitative research transcription quality checklist before relying on wording or speaker attribution in a report.

Use neutral prompts and assistance rules

Good prompts include “What are you looking for?”, “What did you expect to happen?” and “What would you do next?” Ask after an observable pause or action rather than interrupting every moment.

Define assistance levels in advance: repeat the task, clarify scenario context, offer a general nudge, then provide direct help. Mark the level and time. Once help is given, do not report the subsequent completion as fully unaided.

Stop a task when continuing could expose real data, create an unintended transaction, cause distress, damage equipment or exceed the approved scope. Safety and consent override completion metrics.

Probe expectations after the task

After each task, ask what the participant expected, what felt uncertain and what they would do in a real context. A post-task explanation should supplement observed behavior, not replace it.

Avoid satisfaction questions as the sole result. Someone may report liking the interface after failing a critical task, or dislike a color while completing efficiently. Preserve both evidence types and their difference.

If comparing alternatives, control order where practical and ask for reasons tied to the task. Do not turn a small qualitative study into a popularity ranking.

Manage observers and sensitive events

Give observers a structured evidence sheet and a channel for proposed follow-up questions. The moderator decides whether and when to ask them. Prevent observers from identifying participants, taking unauthorized screenshots or discussing sensitive details outside the approved workspace.

For an authorized usability session with visible, agreed capture, Kuno can help draft a transcript, observations and follow-up actions for human verification. It does not determine usability severity or approve a release. Explore Kuno

If a participant reveals sensitive information or encounters a serious product risk, pause as required and follow the named escalation route. Record only what the responsible owner needs.

Debrief without turning observations into votes

Hold a short session debrief with the moderator and note-taker. Review strongest evidence, surprises, assistance, setup deviations and follow-up questions. Do not let observers vote issues into findings based on personal preference.

Across sessions, cluster behavior by task, trigger and context while preserving negative cases. The research debrief template helps maintain the route from source evidence to provisional pattern and decision.

Assign owners to verify technical behavior, source quotations and unresolved context. Escalate critical safety, privacy, accessibility or data-integrity issues through the approved product process.

Complete human review and final QA

Before reporting, confirm the tested build, device, task wording and participant criteria. Verify timestamps and key quotes. Separate unaided completion from assisted completion, observed error from moderator interpretation and participant preference from task performance.

Use the ux research repository examples to preserve controlled source references and limitations. Product, accessibility, security or other specialist owners should review findings within their remit. The decision owner determines priority and release action; no generic score or AI summary should make that judgment automatically.

Final QA should confirm that identifying data is minimized, contradictions remain visible, owners and dates are assigned, escalation status is accurate and the report states what the study cannot conclude.

Reproduce high-impact observations on the tested build when safe and appropriate. This separates persistent interface behavior from a transient prototype, connection or setup failure. Do not erase the original session evidence if reproduction fails; record both results and assign an owner to investigate. Review clips, screenshots and quotations for consent scope before distribution, and give stakeholders enough surrounding context to avoid turning a dramatic moment into a misleading highlight. When a design changes, define which tasks require retesting and which findings remain relevant.

Preserve the session as reviewable evidence, not an automated release verdict. Kuno supports authorized capture and draft notes while researchers and product owners retain responsibility. See Kuno