A more useful task is: “You need a library room for four people next Tuesday afternoon. Find a suitable option and show what you would do to arrange it.” The task gives the participant a reason to act while leaving the route through the interface open.
This usability test plan template turns that fictional room-booking scenario into a discussion guide, a moderator preparation sheet, and blank observation notes.
Tie the session to a research question
For this original example, the team wants to learn whether a likely library visitor can find a suitable room and understand what the final message means. The session uses a fictional prototype with a final message reading “Request received.”
The plan separates what the participant hears from what the moderator prepares:
| Planning field | Worked example |
|---|---|
| Research question | Can a likely visitor find a room that fits their group and explain whether their request has secured the room? |
| Participant | Someone who might use a library room for a small group. Actual recruitment details remain to fill in. |
| Starting point | Prototype home screen with the same starting state for this task. |
| Participant task | You need a library room for four people next Tuesday afternoon. Find a suitable option and show what you would do to arrange it. |
| Moderator preparation | Confirm which date “next Tuesday” means in this prototype, what availability it contains, and where the simulated flow ends. |
| Evidence to note | Where the participant starts, how they check suitability, any help given, and what they think happens after the final message. |
The GOV.UK guide to moderated usability testing recommends agreeing research questions, likely users, and the service area before designing tasks. Its task guidance emphasizes believable goals that avoid revealing how to complete them.
Keep the moderator's expected route out of the participant task. Otherwise, the session can become a demonstration of following your instructions.
Remove clues that answer your question
In the example, choose Compare task wording to see the difference:
| Leading instruction | Neutral task |
|---|---|
| Click Reserve room, choose Capacity, and select four people. | Find a library room for four people next Tuesday afternoon and show what you would do to arrange it. |
The first version names two interface controls. The second retains the group size and time requirement because those facts give the participant a concrete goal.
Read the task aloud to a colleague before the session. Ask them to point out control names, steps, or hints that came from knowing the design. Keep a clue only when that information would actually be available to the intended user.
Prepare probes that leave the answer open
The fictional session excerpt stops at the prototype's final message:
P01 sees “Request received,” pauses, and asks, “Does that mean the room is booked?”
Compare two possible moderator responses:
| Response | What it does |
|---|---|
| “It is still waiting for staff approval, right?” | Supplies an interpretation for the participant to accept or reject. |
| “What makes you say that?” | Invites the participant to explain which words or expectations prompted the question. |
The neutral probe helps you understand the uncertainty before offering assistance. If the participant remains stuck and you give help, record the words you used and when you used them.
GOV.UK's session guidance recommends clear, neutral instructions, watching and listening, and open questions about what the researcher observes. The aim here is to understand the participant's interpretation of the message.
Keep observation, interpretation, and help separate
The example's Session excerpt reveals the fictional sequence in stages. You can keep notes while moving between stages. Use distinct fields:
| Field | Illustrative entry |
|---|---|
| Observed action or words | Paused at “Request received” and asked whether the room was booked. |
| Researcher's interpretation | The message may leave booking status unclear. |
| Assistance | No assistance appears in the supplied excerpt. |
| Follow-up to explore | What would the participant do next, and what information would they look for? |
The question is evidence of uncertainty in this invented excerpt. It does not establish that a real visitor failed a task or that a percentage of users misunderstand the message.
For your own sessions, add the date, prototype version, task, and a participant code to each note. Keep your actual research records in the system your team uses. The browser example is a preparation exercise with temporary notes.
Build your own discussion guide
Create one complete, self-contained HTML usability test plan.
Service or prototype and version: [FILL IN]
Research questions: [PASTE]
Likely participant group: [DESCRIBE]
Task scenario and starting state: [PASTE]
Dates, availability, and dummy information supplied by the prototype: [PASTE]
Moderator-only intended evidence and known prototype limits: [PASTE]
Session location, accessibility arrangements, moderator, and note-taker: [FILL IN]
Recording and consent arrangements: [FILL IN]
Create a short introduction and participant tasks that state realistic
goals without naming interface controls or supplying the route.
Keep moderator-only notes separate. Show leading wording beside a
proposed neutral revision, explaining which clues were removed.
Include a preparation checklist, task order, neutral follow-up probes,
and blank observation records. Separate observed action or words,
researcher interpretation, assistance given, and follow-up questions.
Leave participant behavior and outcomes blank unless I supply them.
Label any supplied teaching transcript fictional. Do not manufacture
success rates, findings, consent, or recruitment results.
Provide task-wording comparison, moderator-probe comparison, and
staged transcript views when supplied. Add a blank plan builder that
names missing research question, task, or starting state. Preserve
typed notes when switching views. Mark a generated review stale
after edits and ask before resetting typed work. Keep input local
to the open page, with no claimed saving or participant submission.
Use readable text of at least 16px, labeled keyboard-accessible
controls, and a layout that fits 360px without horizontal scrolling.
Put CSS and JavaScript inline. Use no network or external assets.
Return the complete HTML.
Try the guide with a colleague before recruiting. Check that the prototype has the dates and room options the task needs, and that you know when to stop a simulated action. Fix missing setup before interpreting it as a participant difficulty.
Share the script before the session
Give the person moderating and the person taking notes the same task wording. They should know which information belongs in the introduction and which notes are for the research team alone.
An HTML preparation guide in NOS lets you revise the static task script on the page. Share that reading copy with the team, then correct a leading phrase in the saved page if the rehearsal exposes one. The existing active link opens the revised wording when colleagues return to it.
Keep the session's actual observations separate from the script. After the session, use the recorded behavior and assistance notes to decide which design question needs the next round of research.