Why the Script Matters
Run the same study with two moderators improvising their own questions and you get two different studies, not one. A script is the protocol that keeps sessions comparable: one participant's confusion at a step means something only if every participant faced the same step, worded the same way. Nielsen Norman Group's guidance on task writing is blunt about the failure mode - a scenario that reveals the interface's own terminology, or gives away the click path, isn't testing anything.
The Five-Part Structure
1. Introduction (5 min)
Set expectations, build rapport, remove performance anxiety.
Example: "Thanks for being here today. We're testing a design - not testing you. There are no right or wrong answers. If you find something confusing, that's incredibly useful feedback. Please think out loud as you work - tell me what you're looking at and what you're expecting to happen."
2. Background Questions (5 min)
Warm-up questions that establish context without previewing the tasks.
Example: "How often do you order food delivery in a typical week?" / "What app do you usually use for that?" / "Walk me through the last time you had to cancel or change an order."
3. Tasks (20–30 min)
Scenario-based, action-oriented, with no navigation hints and no product jargon.
Bad: "Find the reorder button and use it to reorder your last purchase."
Good: "You had dinner from this app last week and loved it. You want to order the same thing again tonight. Starting from wherever you'd normally begin, go ahead."
After each task, ask: "On a scale of 1–7, how easy or difficult was that? What made you say that?" - the second question is where the real data lives; the number alone tells you almost nothing.
4. Post-Task Debrief (5–10 min)
Capture overall impressions once the task pressure is off.
Example questions: "What stood out most to you?" / "Was there a moment you weren't sure whether something had worked?" / "If you could change one thing about what you just did, what would it be?"
5. Wrap-Up (2 min)
Thank the participant, confirm incentive delivery, and ask if they have questions for you.
A Full Example: Subscription Cancellation
Below is an illustrative script excerpt for testing a subscription-cancellation flow - the structure holds regardless of product.
"Imagine your streaming subscription just renewed automatically and you weren't expecting the charge. You've decided you want to stop it from renewing again. Starting from your account screen, show me how you'd do that." - example task scenario
Probing questions to have ready during and after this task: "What did you expect to happen when you tapped that?" / "Was there a point where you weren't sure this had actually cancelled anything?" / "If a friend asked you whether this was easy, what would you tell them?"
Common Script Mistakes
- Leading tasks: "Tap the cancel subscription button" tells users where to go before they've decided how to get there.
- Jargon: use the participant's language, not your internal product terminology.
- Too many tasks: 3–5 tasks per 60-minute session. More and you rush; fewer and you leave questions unanswered.
- Forgetting the think-aloud reminder: participants drift silent. Re-prompt with "what are you thinking right now?" - never with a hint.
Key Takeaways
- A script is a protocol - consistency across participants is what makes the data comparable.
- Scenario-based tasks beat instruction-based tasks: observe decisions, not execution of your own wording.
- 3–5 tasks per session is the right density for a 60-minute moderated test.
- Post-task Likert ratings plus a "why did you say that" follow-up give you quick quantitative signal alongside qualitative detail.
