How to moderate a usability test: what to say when a participant gets stuck
How to moderate a usability test without leading anyone: an opening script, neutral lines for the four moments that go wrong, and why silence beats helping.
Published August 2, 2026
Fifteen seconds into the checkout task, the participant stops. They scroll up, scroll down, scroll up again. You can see the button from where you're sitting. The silence stretches until it starts to feel rude, so you say: "Have you looked at the top right?" They find it instantly.
That wasn't an observation. You led them there.
Most of moderating a usability test is not talking
Your job during a session is to protect the participant's own thinking, and two habits damage it more than anything else: helping too early, and asking people to explain themselves while they're still working. Both feel polite. Both erase the very thing you came to watch.
The good news is that none of this is a talent you're born with. Avoid those two habits, pick up a few small techniques, and anyone can moderate. Running the session is step four of a usability test, and what it takes is one opening script plus about six neutral lines you can reuse in every session for the rest of your career. Prepare those, resist the urge to fill silence, and you're most of the way to running a clean session.
Write your opening once, then reuse it forever
The first two minutes set the tone for the whole session. Say these things in whatever order feels natural:
Thanks for making the time. I'll ask you to try a few things on a website yourself, and I'll mostly stay quiet and take notes while you do.
One important thing: what we're looking at today is our product, not you. There are no wrong answers. If something is confusing or annoying, that's exactly what we need to hear, so please say it.
While you work, I'd like you to think out loud. Just say whatever's going through your head, even if it feels obvious.
If you ask me something, I might not answer straight away. That's not me being unhelpful, it's that I want to see what you'd do on your own. I'll answer anything you're curious about once we're done.
The heads-up about not answering is the one people skip, and skipping it is what makes the silence awkward later. If you warn someone up front that you'll go quiet, they take it in stride instead of reading it as disapproval. NN/g's moderating checklist makes the same two points: frame the session as research rather than a test of the person, and tell them ahead of time that help may not come right away.
One more habit worth borrowing from that checklist: avoid the word "test" with participants. Call it research, or a study. Nobody thinks clearly while they believe they're being graded.
"Think out loud" works. "Explain your reasoning" doesn't.
What you can see from where you're sitting is what the participant did. Where they were looking, what they mistook for something else, none of that shows. So at the start of a session you ask them to think out loud. It's a common enough request in UX to look like a habit, but it comes out of Ericsson and Simon's research on verbal reports.
Having someone say what's in their head doesn't change how they behave. Asking them to explain why they did something does. That line is what separates the safe things to say mid-task from the costly ones.
Start with saying what's in your head. Across a meta-analysis pooling 94 studies and roughly 3,500 participants (Fox, Ericsson and Best, 2011), people who thought aloud performed the same as people who worked in silence. The only thing that shifts is the clock: talking makes a task take a little longer, so don't hold those times up against numbers measured in silence.
Explaining is where it breaks. In the same research, when people were asked to describe or explain what they were doing, they did better than the silent group. Putting it into words makes you look at your own actions once more, and that makes you more careful than you'd otherwise be.
That is why "why did you do that?" is dangerous mid-task. It isn't rude, it's not even a bad question. It turns a person who was using your product into a person accounting for it, and from there you're watching someone more deliberate than the user you set out to study. And once they start explaining themselves, they keep doing it, more carefully, for the rest of the session.
Ask why later. Between tasks or at the end, "what were you expecting when you clicked there?" is a great question and costs you nothing.
When someone goes quiet mid-task, don't walk them through the task again. "What are you thinking right now?" is usually all it takes. If your line mentions the screen, the goal, or anything they might be hunting for, it's already a hint.
Four moments, and the line to have ready
Almost everything that goes wrong in a session is one of these four, and each has a bad reflex attached to it.
| The moment | The reflex to resist | Say this instead |
|---|---|---|
| They're stuck and it's painful to watch | "Have you tried the menu at the top?" | "What are you thinking right now?" |
| They ask you directly for help | "Sure, it's the icon on the right." | "What would you do if I weren't here?" |
| They go silent for a long stretch | "You're looking for settings, right?" | "Can you tell me what you're looking at?" |
| They ask you what you think | "Yeah, we know that screen is confusing, it's being redesigned." | "I'll tell you everything at the end. How did it feel to you just now?" |
NN/g has a name for what to do when they ask you outright: the boomerang. You hand back a generic, non-threatening version of their own question. "What do you think that does?" "What would you normally do here?"
You learn what they expected, which is the actual finding, and they learn you're not going to rescue them.
NN/g has two related moves. The echo is repeating their own last words back with a small question in your voice: they say "this table is weird," you say "weird?" and they keep going, in their words rather than yours. The Columbo, named after the detective, is a half-finished question you let them complete: "so you're wondering if…". You get an answer without ever supplying the frame.
When a participant turns a question back on you, the stakes are higher than they look. "Is it supposed to work this way?" "Is it just me, or is this awkward?" You want to answer, but the moment you tell them what you think, or let slip that a screen is already being redesigned, everything they say afterward is shaped by it. Hold your opinion until the session is over. Then share it freely. By then they've earned an honest answer.
Count to ten before you say anything
Here's the practical version of "stay quiet", and it comes straight from NN/g: before you interrupt, count to ten in your head and ask whether speaking actually serves the research.
You will lose that count constantly at first. Ten seconds of someone struggling feels like a minute. But that stretch is where the finding lives. A participant who circles a screen three times and then finds the button has told you something you'll never hear from the one you pointed at it.
Sometimes you do have to help, and that's fine. Someone genuinely blocked for two minutes learns nothing more, and the rest of your tasks are still waiting. When it happens, help as late and as little as you can.
Then write it down. "Finished with help" is not the same result as "finished," and if you record both the same way, your notes will overstate how well the design worked.
In Interbang, each task is scored on a five-step scale: independent, minor difficulty, struggled, observer helped, and failure. Separate an assisted finish from a clean one, write down how you helped, and the context is still there when you review.
Two people beat one
One person running the session and taking notes will miss things. While you're writing or typing, you aren't watching.
Split it: a moderator who talks to the participant and manages the tasks, and a notetaker who says nothing and writes everything. NN/g recommends splitting the roles, and Rubin and Chisnell's Handbook of Usability Testing treats them as separate roles for the same reason.
If you're on your own, keep the notes deliberately rough during the session and tidy them up right afterward, while it's all still fresh.
This is preparation, not practice
Almost nothing here gets better with practice. It gets better with preparation. Write the opening script once, keep the six lines somewhere you can see them, and decide before the session that silence is allowed. That's the whole discipline.
Your tasks matter just as much. A leading task leaves nothing to observe, no matter how well you moderate. If you haven't written yours yet, write them as scenarios rather than instructions first. And once the sessions are done and you're staring at a pile of notes, turning them into a short list of problems worth fixing is its own job.
Frequently asked questions
Is it ever okay to help a participant? Yes. If someone is genuinely blocked and no longer learning anything, help them so the rest of the session isn't wasted. Give the smallest hint that unblocks them, as late as you can, and record that the task was completed with help rather than independently.
What if the participant barely talks at all? Some people find thinking aloud unnatural, and pushing harder only makes them clam up. Ask "what are you thinking right now?" once, gently, and let the gaps go. Behavior is data too: where they hesitate, backtrack, and re-read tells you plenty even in silence.
When can I ask "why did you do that?" After the task, not during it. Asking mid-task pulls someone out of doing and into justifying, and that shift can change how they approach everything that follows. Note the moment as it happens, then come back to it once the task is finished: "you paused on that screen for a while, what was going on there?"
Can I moderate a product I designed myself? You can, and on a small team you'll have to. Just know the two risks: you'll be tempted to defend the design, and participants will soften their feedback if they know it's yours. Introduce yourself as someone working on the research, avoid saying you built it until the end, and if a colleague can moderate the flows you're closest to, let them.