---
title: "Usability Testing Moderation Tips for PMs"
description: "Usability testing moderation tips: think-aloud prompts, how to answer questions with questions, when to rescue, what to note, and an observer sheet to share."
canonical_url: "https://builderscamp.com/guides/other/usability-testing-moderation-tips"
date_published: "2026-10-05"
date_modified: "2026-10-05"
author: "Dr Chloe Sharp"
publisher: "Builders Camp"
guide_class: "other"
---

# Usability testing moderation tips: neutral prompts, when to step in, and what to write down

**TL;DR:** Ask participants to think aloud, then stay mostly silent: use a short bank of neutral prompts, answer questions with questions, and only step in when someone is completely stuck, recording every assist as a failure. Have a note-taker log participant, task, time, action and verbatim quote for every observation, and give observers a one-page sheet so engineers watch in silence and write down behaviour rather than opinions.

## What does a moderator actually do in a usability test?

A moderator gives the tasks, keeps the participant talking, and otherwise stays out of the way. Jakob Nielsen, in [Thinking Aloud: The #1 Usability Tool](https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/), wrote that "Thinking aloud may be the single most valuable usability engineering method", and reduced a basic think-aloud study to 3 steps: recruit representative users, give them representative tasks, and "Shut up and let the users do the talking."

The third step is the hard one. Nielsen's own list of the method's downsides includes biasing user behaviour: "from an untrained facilitator, such interruptions can very easily change user behavior." A moderator who explains a button, nods at the right answer or rephrases a task has changed the result, and nothing in the recording flags it. The tips below exist to keep that from happening while still getting the participant to tell you what they think.

This guide is the third step in a four-part sequence for running a real test: [recruit with a screener](https://builderscamp.com/guides/templates/usability-test-screener-questions), [write the session guide](https://builderscamp.com/guides/templates/usability-test-script-template), moderate (this guide), and [report the findings](https://builderscamp.com/guides/templates/usability-test-report-template). The examples continue the same grocery checkout study. For the overall method and what a PM owns at each stage, see [how to run a usability test](https://builderscamp.com/guides/other/how-to-run-a-usability-test).

## How do you get participants to think aloud and keep talking?

Explain it, show it, and let them practise before the first real task. Nielsen notes that most people find a running monologue unnatural and suggests showing "a short video demo of a think-aloud session" to explain what is expected. If you have no video, demonstrate for 20 seconds on an unrelated website: "I'm looking for the opening hours, I'd expect them at the bottom, nothing there, so I'll try the menu."

Then give a throwaway practice task, such as finding today's weather on a news site. It costs two minutes and tells you whether this participant will need frequent reminders. Nielsen also warns about filtered statements: people who want to appear smart stay quiet until they have worked something out, and you lose the moment of confusion you most needed to hear.

When the talking stops, use a short prompt and nothing more. This is the prompt bank to keep beside the session guide:

| Situation | Say | Never say |
|---|---|---|
| Silent for more than a few seconds | "What are you thinking right now?" or simply "Keep talking." | "Are you stuck?" |
| Hovering or scrolling back and forth | "What are you looking for?" | "The button is at the top." |
| Clicks something unexpected | "What did you expect to happen?" | "Interesting, why did you click that?" (said with surprise) |
| Says "hmm" or "that's weird" | "That's weird?" (echo, see below) | "Is the layout confusing?" |
| Completes the task | "How sure are you that it's done?" | "Great, well done!" |
| Gives an opinion ("I'd never use this") | "What makes you say that?" | "Most people like it." |
| Asks if they did it right | "There's no right or wrong here. What would you do next at home?" | "Yes, that's it." |

The "never say" column is a list of things moderators actually say under pressure. Praise is the subtle one: tell participant two "great!" after Task 1 and they will start performing for you.

## How do you answer a participant's question without answering it?

Turn it into a question back to them. Kara Pernice of Nielsen Norman Group, in [Talking with Participants During a Usability Test](https://www.nngroup.com/articles/talking-to-users/), gives three techniques that work in almost every case:

- **Echo.** Repeat the participant's last words with a questioning tone. Participant: "This delivery bit is odd, I'm not sure what..." Moderator: "Not sure what?" You add no words of your own, so you cannot bias them.
- **Boomerang.** Push the question back with a generic one. Participant: "Do I have to pick a slot before I pay?" Moderator: "What do you think?" or "What would you do if you were doing this on your own?"
- **Columbo.** Ask half a question and trail off. Participant: "If I go back, will I lose my basket?" Moderator: "You're wondering if... you might..." The participant usually fills the gap with the real concern.

Pernice also gives a rule for whether to speak at all: "When in doubt about whether to talk to the usability test participant, count to 10 silently." Many questions are thinking aloud in question form, and the participant answers them themselves before you reach ten.

## When should you let a participant fail, and when should you rescue them?

Let them struggle and fail by default, because struggle is the data. The [GOV.UK Service Manual on moderated usability testing](https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing) gives the exception: you can help a participant "get back on track if they get completely stuck", because giving them a chance to recover means you can keep learning from the rest of the session. The skill is telling "completely stuck" apart from "slow and annoyed".

Use an escalation ladder, and only move to the next rung when the one before has not worked:

1. **Wait.** Count to ten. Most hesitation resolves itself.
2. **Neutral prompt.** "What are you looking for?" This often unsticks a participant who has lost track of the goal.
3. **Reread the task.** "Let me read the task again." This repairs a misunderstood scenario without pointing at the interface.
4. **Ask what they would do in real life.** If they answer "I'd phone the shop" or "I'd give up", you have the finding. Note it as a failure.
5. **Move them on.** "Thanks, that's really useful. Let's go to the next one." If the next task depends on this one, take them to its starting screen yourself.

Write down the rung each participant reached on each task. In analysis and in the report, a task completed after rung 3 counts as a failure for that participant, not a success with help. If a participant asks how they were supposed to do it, show them during the wrap-up, after all tasks are done, so the answer cannot change their behaviour on later tasks.

## What should the note-taker write down?

One line per observation, in the same format every time, so analysis can sort and count them. The GOV.UK guidance on [analysing a research session](https://www.gov.uk/service-manual/user-research/analyse-a-research-session) asks people to "write exactly what they saw or heard (eg verbatim quotes or observed behaviour), not what they think it means." Interpretation happens later, as a group, when all five sessions are visible.

The format:

```
ID | Task | Time | What they did | Quote (verbatim) | Rung
```

Here is how the note-taker's log looked for participant P3 on Task 1 of the grocery study (deliver on Saturday before 11):

```
P3 | T1 | 06:12 | Scrolled past slot picker to payment     |                                   | 0
P3 | T1 | 06:40 | Scrolled back up, opened "Delivery"     | "Where do I say when?"             | 0
P3 | T1 | 07:15 | Picked Sat slot labelled "11:00"         | "Eleven, that's fine I think."     | 0
P3 | T1 | 07:30 | Probe: how sure it arrives before 11?    | "Oh. It might be after eleven."   | 0
P3 | T1 | 07:50 | Changed to Sat slot labelled "9:00"      |                                   | 0
```

Compare that with a typical untrained note: "P3 found the slot picker confusing and nearly booked the wrong time." That note is an interpretation. It hides that P3 scrolled past the picker (a visibility problem) and read a slot labelled 11:00 as arriving by 11 when it starts at 11 (a labelling problem). Those are two different fixes, and only the observation format keeps them apart. If you will analyse with an assistant afterwards, these lines are also what [AI for usability test analysis](https://builderscamp.com/guides/tools/ai-for-usability-test-analysis) means by putting observed actions into the transcript.

## How do you reset the environment between sessions?

Reset everything a participant could have changed, so participant four starts where participant one did. GOV.UK advises allowing "at least 15 minutes between sessions" and planning "no more than 6 one-hour sessions a day". Use the gap for this checklist:

- Clear the test basket, applied codes, saved addresses and order history in the test account.
- Log out, close the browser profile and reopen the prototype from the original link.
- Restore any prototype state a task changed, such as an order moved to a different day.
- Delete the chat history in the call tool, so the next participant cannot see earlier tasks.
- Check observers are still muted with cameras off.
- Save and rename the notes file with the participant ID.
- Hold a five-minute debrief with observers: what surprised them, and anything to watch in the next session. Do not change task wording mid-round.

## Which eight mistakes contaminate a usability test session?

Each of these changes what the participant does, which makes their results unusable for that task or worse, misleading:

1. **Teaching the interface.** Explaining what a feature does before or during a task. The participant now knows what real users would not.
2. **Leading probes.** "Did you see the button at the top?" tells them there is a button and where it is.
3. **Rephrasing tasks per participant.** A friendlier wording for participant three means you tested a different task. Read the script word for word.
4. **Reacting.** Praise, sighs, laughter, "interesting!" on a wrong click. Participants read moderators closely.
5. **Asking for opinions mid-task.** "Would you use this?" in the middle of a task switches them from doing to reviewing. Keep opinion questions for the wrap-up.
6. **Rescuing too early.** Jumping in at the first hesitation removes the very struggle you recruited five people to see.
7. **Letting observers leak.** An unmuted microphone, a visible chat, or a designer explaining their reasoning. Hoa Loranger's line in [Team Members Behaving Badly During Usability Tests](https://www.nngroup.com/articles/team-members-user-test/) is the one to repeat to the team: "Usability testing is the team's opportunity to receive feedback, not give it."
8. **Skipping the reset.** A basket that still holds the previous participant's discount code turns a test of the voucher field into a test of nothing.

## How should engineers and other observers watch a session?

Invite them, because watching changes priorities faster than any report. Nielsen's argument in [Involving Stakeholders in User Testing](https://www.nngroup.com/articles/stakeholders-and-user-testing/) is short: "Seeing is believing." He also names the risk of partial attendance: "it's not enough to test 1 or 2 users if you want to identify true trends and patterns", and people remember the problems they saw themselves far better than the ones they read about. Ask observers to watch at least two sessions, and tell them up front that one participant's struggle is a data point, not the finding.

Loranger suggests allowing "up to 3 observers in the same room" and passing observer questions through the moderator at the end. Remote observation removes most of the room problem, but observers still need rules. Share this sheet before the first session:

```
OBSERVER SHEET: [Study name], [date]

Before the session
  Camera and microphone OFF for the whole session.
  Do not post in the call chat. Use [team channel] instead.
  You do not need to understand everything; watch behaviour.

During each task, write one line per thing you SEE:
  Participant | Task | Time | What they did | Exact words

  Good:  P2 | T3 | 14:05 | typed code into search box | "Is this where?"
  Not:   P2 found the voucher UX confusing

Questions for the participant
  Write them in [team channel]. The moderator may reword
  them and ask at the end. Some will not be asked.

Please do not
  Explain or defend the design, even afterwards to the participant.
  Decide on a fix after one session.
  Share recordings or names outside the team.

After the session (5 min debrief)
  1. The one thing that surprised you most:
  2. One thing that worked well:
  3. Anything to watch for in the next session:
```

The sheet's middle section matters more than the rules. An engineer who writes "P2 typed the code into the search box" has brought a fix to the analysis. One who writes "voucher UX bad" has brought an opinion.

## What are the limits of moderated think-aloud testing?

Think-aloud is qualitative, and Nielsen is explicit that the method "doesn't lend itself to detailed statistics, unless you run a huge, expensive study." Five sessions tell you what goes wrong and why. They do not tell you what share of all users will hit it, and a report that says "60% of users failed" on five participants is claiming more than the study can support. Report counts out of five instead.

Prompts, probes and the effort of narrating also add time, so time-on-task from a moderated think-aloud session is not a speed benchmark. For timing and success rates at scale, run an unmoderated or quantitative study after the qualitative rounds. For turning what you wrote down into something stakeholders act on, the last step in this sequence is [how to write a usability test report](https://builderscamp.com/guides/templates/usability-test-report-template).

Builders Camp runs live and self-paced bootcamps in product management and AI product building. [See the Usability Testing for Product Managers bootcamp](https://builderscamp.com/bootcamps/usability-testing-for-product-managers?utm_source=guide&utm_medium=organic&utm_campaign=usability-testing-moderation-tips) for the next cohort and the self-paced version.

## Frequently asked questions

### What is the most important usability testing moderation tip?

Talk less. Jakob Nielsen's three steps for a think-aloud test end with letting the users do the talking, and he warns that prompts from an untrained facilitator can easily change what participants do. Most moderation skill is knowing when a silence is useful and which few neutral words to use when it is not.

### What should you say when a participant asks you a question during a task?

Turn it back to them. Nielsen Norman Group's boomerang technique answers 'Do I have to register to buy this?' with 'What do you think?' or 'What would you do if you were really doing this on your own?' You learn what they expected, and they keep working as they would alone.

### When should a moderator step in to help a participant?

When the participant is completely stuck and the rest of the session is at risk, not when they are merely slow or frustrated. Before helping, try a neutral prompt, then rereading the task. Record every assist, and count an assisted task as a failure for that participant.

### What is think-aloud in usability testing?

A method where participants say what they are looking at, thinking and trying to do while they use the product. Nielsen defines it as asking participants to use the system while continuously thinking out loud. It shows you misconceptions as they happen, which an after-the-fact interview cannot.

### What should the note-taker write down?

For each observation: participant ID, task, a timestamp, what the participant did, and any quote word for word. Write behaviour and quotes, not interpretations. The GOV.UK Service Manual asks for exactly what people saw or heard, not what they think it means, so the notes stay useful in analysis.

### How many people should observe a usability test?

As many as can watch silently, ideally remotely. Nielsen Norman Group suggests no more than 3 observers in the same room as the participant. Encourage engineers and designers to watch at least two sessions, since one session alone can mislead them about what is common.

### How long should you leave between usability test sessions?

At least 15 minutes, according to the GOV.UK Service Manual, which also suggests no more than six one-hour sessions a day. Use the gap to reset the prototype and test accounts, debrief observers for five minutes and tidy notes while they are fresh.

## Sources

- [Jakob Nielsen, Nielsen Norman Group: Thinking Aloud: The #1 Usability Tool](https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/)
- [Kara Pernice, Nielsen Norman Group: Talking with Participants During a Usability Test](https://www.nngroup.com/articles/talking-to-users/)
- [GOV.UK Service Manual: Using moderated usability testing](https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing)
- [GOV.UK Service Manual: Analyse a research session](https://www.gov.uk/service-manual/user-research/analyse-a-research-session)
- [Hoa Loranger, Nielsen Norman Group: Team Members Behaving Badly During Usability Tests](https://www.nngroup.com/articles/team-members-user-test/)
- [Jakob Nielsen, Nielsen Norman Group: Involving Stakeholders in User Testing](https://www.nngroup.com/articles/stakeholders-and-user-testing/)

## How this guide was made

Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.