Questions to Ask in User Testing
For designers, researchers and product managers choosing questions to ask in user testing, also called usability testing, where a participant tries a product or prototype while a moderator watches. The list follows the session: screening before it, a short warm-up, neutral prompts while the participant attempts each task, follow-ups once a task is over, and a wrap-up. Each note says when to ask, what a good or a worrying answer sounds like, and how to keep from leading or rescuing the person in the chair.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Screening
When did you last do this kind of task, and how often does it come up?
Why ask it
The date is the part to trust: people round 'how often' up, and 'frequent user' means whatever they want it to mean. A good answer sounds like 'last week, to pay my rent, and about once a month'. Someone who has to reach back a year will be guessing at the tasks, so recruit them only if new or lapsed users are who you want to watch.
Which apps or websites do you use for this now?
Why ask it
Leave it open and keep your own product's name out of the question, so nobody can work out which answer gets them in. The list tells you what habits they will bring: someone used to a competitor will look for its menus in your design. Keep it beside you in the session, because it explains much of what they expect.
What do you do for work, and does it involve design, software development or market research?
Why ask it
People who build or study products for a living tend to review the design instead of using it, and their sessions fill up with advice. It is usual to screen them out unless they are the product's real audience. The same goes for anyone who works for you or for a competitor.
Have you taken part in a usability test or a paid research study in the past six months?
Why ask it
Frequent participants learn what moderators like to hear and start performing the think-aloud. One or two past sessions is nothing to worry about. Several in recent months, especially through the same recruiter, is a reason to give the slot to someone else.
Which device do you do this on most, and which will you have with you for the session?
Why ask it
A design tested on a laptop by someone who lives on their phone tells you little about their real use. Match the session to the device they named first. For a remote session, ask too whether they have shared a screen from it before, and send the steps ahead if not.
Is there anything that would make the session easier for you, such as a screen reader, larger text or extra time?
Why ask it
Asking in the screener means the setup is ready when they arrive and nobody has to explain themselves on the day. If someone names assistive technology, have them bring their own setup where you can, since their settings are part of what you are testing. Plan a longer slot and fewer tasks.
Are you comfortable with your screen and voice being recorded, and with a few people from the team watching?
Why ask it
Settle this before the day, in writing. What consent you need, how long a recording may be kept and who may see it depend on where you and the participant are and on your employer's rules, so ask whoever handles privacy at your organization how it works there. A hesitant yes deserves a notes-only session.
Warm-up
Before we begin, what questions do you have about what we are doing today?
Why ask it
'What questions do you have' gets more than 'any questions?', which most people wave away. Use the answer to repeat the two things participants forget: the product is being tested and they are not, and you did not design it, so nothing they say can offend you. If they ask whether they will be told the right answers, say you will go over anything they like once the tasks are done.
Tell me a little about your work or your week. What takes up most of your time?
Why ask it
It is an easy question with no wrong answer, there to get them talking in full sentences before a task asks them to think aloud. Two minutes is enough. If the answers stay at one word, slow down and ask one more easy thing before you bring out the product.
Take me through the last time you did this. What set it off, and where did you begin?
Why ask it
Their own story hands you the vocabulary for the tasks: if they say 'send money' and your script says 'initiate a transfer', change the script. Where they began, a search, an email link or an app already open, is worth comparing with where your first task starts them. Keep it to a few minutes, since a full discovery interview belongs in a session of its own.
What is the most tedious part of how you do it now?
Why ask it
Whatever they name is the thing they will be watching for in your product, whether or not a task covers it. A specific complaint, such as retyping an address every time, is worth listening for again in the wrap-up. A shrug suggests the current way suits them, which is useful to know before you weigh their enthusiasm later.
Have you used this product before, or heard anything about it?
Why ask it
You need to know whether you are watching a first encounter or a returning user, because the same stumble means different things. With an existing user, ask which parts they use, then expect them to run on habit in those and act like a newcomer everywhere else. Do not correct anything they have heard about it.
As you work, would you say out loud what you are looking at, what you are trying to do and what you make of it?
Why ask it
Mention it in your opening, then ask it again right before the first task, because by then the first mention has faded. Nearly everyone starts well and trails off within a few minutes, which is what the quiet-participant prompt under During tasks is for. If narrating slows someone to a crawl, let them work in silence and go back over the task with them once it ends.
During tasks
Looking at this screen without clicking anything, what do you think you can do here?
Why ask it
Ask it once, at the first screen, and give them time to look. A good sign is a description close to the product's real purpose in their own words. If they describe a different product, or read the headline back to you, the page is not explaining itself, and that misunderstanding will color every task that follows.
Without clicking yet, where would you start?
Why ask it
The first place a participant goes is strong evidence about your navigation, and asking before the click captures it even if they then change their mind. Use it sparingly, on the tasks where the starting point is the thing in doubt. On every task it turns the session into a quiz.
Could you show me how you would do that?
Why ask it
For the participant who answers a task by describing it: 'I would probably just search for it'. What people say they would do and what they then do part company quickly, and only the doing is evidence. If they hold back because the prototype looks unfinished, ask them to try anyway and say you will tell them when they reach something that is not built yet.
What are you thinking right now?
Why ask it
The standard prompt for a participant who has gone quiet. Wait through about ten seconds of silence before using it, and not at all while they are plainly reading or typing, since interrupting changes what they do next. If they say 'nothing', try 'what are you looking at?' and leave it there.
What do you expect to happen when you click that?
Why ask it
It has to come before the click: asked afterward, people tend to report having expected whatever appeared. A confident prediction that turns out wrong is one of the clearest findings a test produces. Ask it at decision points only, because asked at every button it teaches people to second-guess each move.
How does this compare with what you expected to see?
Why ask it
Use it right after a screen loads and their face changes. It is neutral where 'was that what you expected?' invites a polite yes. Listen for what they thought would be there: the missing thing is often a confirmation, a price or a next step.
What are you looking for?
Why ask it
For the moment when the mouse circles or the thumb scrolls up and down the same page. The word they use is the label they were hunting for, so write it down exactly. Do not follow it with a hint about where the thing lives.
What does that label mean to you?
Why ask it
Point at the word without reading it aloud in a meaningful voice. If participants give different meanings for 'Workspace' or 'Library', the term is the team's and not theirs. Hold the question until they have moved past the label if asking sooner would steer them toward it.
What would you do at this point if you were on your own?
Why ask it
This is the reply to 'what does this button do?' and 'am I doing this right?'. It hands the question back without refusing them. Often they say 'I would probably just try it', and then they do. If they say they would call support or give up, you have your finding and can decide whether to move on.
I noticed you stopped for a moment there. What was going through your mind?
Why ask it
Describe only what you saw. 'You looked confused' puts a feeling in their mouth, and most people will agree with it to be helpful. Sometimes the pause was a notification or a stray thought, and hearing that saves you from logging a problem that is not there.
You said that was 'odd'. What was odd about it?
Why ask it
Repeating the participant's own word, and nothing else, is the safest follow-up there is, because it adds no idea of yours. Swap in whatever they said: 'weird', 'nice', 'a lot'. One echo per remark is plenty, since a second starts to sound like a parrot.
How can you tell whether that worked?
Why ask it
Ask after a save, a send or a payment. A good answer points at something on the screen: a message, a changed total, the item appearing in a list. 'I assume it did' means your feedback was missed or missing, and in real use that person submits twice or goes off to check.
What would you want to know before going any further?
Why ask it
Suited to pages that ask for commitment: a sign-up form, a checkout, a permission request. Answers such as 'whether I can cancel' or 'what this costs after the trial' are content gaps, and cheap to fix. If they say 'nothing' and carry on at speed, take that as a pass.
How close is this to the way you would do it at home, with nobody watching?
Why ask it
Participants read every word and try every option in a test, then skim and guess in real life. Ask when the thoroughness looks unnatural, and invite them to carry on in their usual way. Keep the tone curious, so nobody feels caught out for being careful.
If this were real, would you keep going here or stop? What would you do instead?
Why ask it
A participant will struggle on out of politeness long after a real user would have left. Their answer marks the true end of the task, and 'I would have phoned them by now' is a failure even if they later finish. It is also a graceful way to close a task that is going nowhere without telling them they failed.
After a task
How did that go for you?
Why ask it
Start broad, before any rating or pointed question, so the first thing you hear is what stood out to them and not what you asked about. Watch the gap between this answer and what you saw: 'fine' after four wrong turns is common, and it is why what you observed stays the main evidence.
On a scale of 1 to 7, where 1 is very difficult and 7 is very easy, how was that task?
Why ask it
Ask it the same way, word for word, after each task and before you discuss anything, so the scores can be compared across tasks and across rounds of testing. With a handful of participants the number is a rough signal, not a measurement. Show the scale on a card or on the screen so nobody has to remember which end is which.
What kept it from being a point or two higher?
Why ask it
The reason is worth more than the number. Asking what held the score down gets a specific obstacle, where a bare 'why?' gets a general impression. If they gave top marks to a task you watched them fight through, do not argue: note both, and ask what they would tell a friend about to try the same thing.
Would you say that task is finished, or is there something still left to do?
Why ask it
People often believe they finished when they did not: the order was never placed, the setting never saved. Do not correct them during the session. A confident 'finished' on a failed task is a more serious finding than a struggle, because in real use nothing would send them back to fix it.
Which part of that took the most effort?
Why ask it
'Effort' lets them answer without admitting they were stuck, which many people avoid. Compare what they name with where you saw them slow down. When the two differ, they may have blamed themselves for the real problem and remembered only the last hurdle.
You went to the menu first and then came back. What were you hoping to find there?
Why ask it
Replace the menu with whatever detour you saw, and hold the question until the task is over so it cannot redirect them mid-attempt. The answer shows where they believed the feature lived. When several participants take the same wrong turn, that spot is a candidate for a link or for the feature itself.
What information did you want during that task that you could not find?
Why ask it
Good after tasks that involve choosing: a plan, a product, a delivery option. Listen for things they went without, such as a total price or a comparison, and for things that were on the page but unseen. Check the recording for the second kind, since the fix there is placement and not more content.
How does that compare with the way you do it today?
Why ask it
Tie it to what they told you in the warm-up. 'Quicker, because I did not have to log in twice' is a finding you can quote. 'About the same' on your headline feature is a warning that the improvement is visible to the team and not to the user. Treat 'much better' as politeness until they name the detail.
If you had to do the same thing again tomorrow, what would you do differently?
Why ask it
This separates a problem of first use from a problem every time. 'I would go straight to the search box' means the design can be learned, though it could introduce itself better. 'I still would not know where to start' means it has to change.
What, if anything, caught you off guard along the way?
Why ask it
The 'if anything' matters, since without it you are telling them something should have. Pleasant surprises count: a saved address or a step that was skipped for them is worth protecting in the next version. Leave a pause after asking, because surprises take a moment to recall.
Wrap-up
How would you explain what this product does to someone who has never seen it?
Why ask it
After the tasks, this shows what the session taught them, set against what they guessed at the first screen. A good answer covers the main job in plain words. If they describe only the last task, or still cannot say who it is for, the product's purpose is not coming through in use.
What was the most frustrating moment today, if there was one?
Why ask it
Asking for one moment forces a ranking, and the moment they pick is not always the one where they lost the most time, so record their choice alongside your own notes on severity. The 'if there was one' leaves room for an honest no. If you get that no after a visibly hard session, offer no examples, and ask which task they would least like to repeat.
What worked better than you thought it would?
Why ask it
Teams leave a test with a list of faults and then redesign away something that was working. This gives you the other list. Vague praise such as 'it is clean' can be set aside. A named moment, such as the form remembering their details, is something to keep.
If one thing could be fixed before this goes out, what would you pick?
Why ask it
Take the answer as a pointer to the problem, not as the solution. 'Add a big help button' usually means 'I did not know what to do on that screen', so ask which screen they had in mind. Participants are reliable about where it hurt and much less so about the cure.
What would stop you from using this in place of what you use now?
Why ask it
Asking about obstacles gets more honest answers than asking whether they would use it, which nearly everyone answers yes to while sitting with the person who invited them. Listen for reasons outside the interface: their data is elsewhere, their team uses another tool, they do not trust a new name with payments. Those never show up in a task.
How close were today's tasks to what you would really want to do with something like this?
Why ask it
It is a check on your own script. If participants keep saying they would never do task three, its results say little about real use, however badly it went. Ask what they would have tried first, and consider making that a task in the next round.
Which three words would you use to describe what you tried today?
Why ask it
A common closer, and weak evidence on its own, since people reach for 'simple' and 'modern' out of habit. Its value is in the follow-up: ask which moment each word came from. 'Busy' traced to one crowded screen is worth having. Skip it when time is short.
Was there anything you held back from saying because it felt impolite?
Why ask it
Participants soften their views for a moderator they like. Saying outright that bluntness is welcome, at the end when it can no longer affect the tasks, sometimes releases the real opinion. If something comes out, thank them plainly and do not defend the design.
Now that the tasks are over, what would you like to ask me?
Why ask it
This is where the questions you turned back during the tasks can be answered. If they ask how the thing they were stuck on was meant to work, show them and watch the reaction: 'oh, I saw that and ignored it' is a different problem from 'I would never have found that'. Their questions also show what the product left unexplained.
What should I have asked you about that I did not?
Why ask it
Ask it last, then wait longer than is comfortable. It catches the topic your script had no task for, often something from their own use that the team had not thought to test. An answer here that repeats across sessions is the first candidate for the next round's script.
How to moderate a user test without leading it
Practical guidance for the conversation itself
Before the session
Write tasks as situations, not instructions
A task that says 'use the filter to find a blue jacket' has told the participant where to click. Write the situation instead: 'You need a jacket for a wedding next month and have about a hundred dollars to spend.' Keep the words printed on your buttons and menus out of the task, or you will be testing whether people can match text.
Pick questions for each task ahead of time
Nobody asks every question on this page in one session. For each task, choose one or two prompts from During tasks that fit what you are unsure about, and decide which of the After a task questions you will ask every time. The rating question only earns its place if it follows every task in the same words.
Rehearse the opening
The first two minutes set the rules: the product is being tested and the participant is not, you did not design it and cannot be offended, you would like them to think aloud, and you may answer their questions with a question until the tasks are done. Say it the same way each session. Then show what thinking aloud sounds like on something unrelated, such as finding a setting on your own phone, and make the request again as the first task begins.
Run a pilot
Try the whole script on a colleague the day before. A pilot finds the task nobody understands, the prototype link that goes nowhere and the session that runs twenty minutes over. Fix the script, and leave the colleague's results out of the findings.
Give everyone in the room a job
One person moderates and one takes notes. Observers watch from another room, or with cameras and microphones off, and send their questions to the note-taker for the wrap-up. A participant facing four people from the company starts being polite to all of them.
If nobody will be moderating
In an unmoderated test the participant reads the questions alone, so the During tasks prompts do not apply. Use the Screening questions, write the tasks with extra care because nobody can clarify them, and put two or three of the After a task questions on screen once each task ends.
While they work
Let silence do the work
Most of a good session is watching. When the participant goes quiet, count slowly to ten before prompting. People often start talking again on their own, and what they say unprompted is better evidence than an answer to your question.
Answer a question with a question
'Is this the right page?' is a finding in itself: the page did not tell them. Reply with 'what do you think?' or with the question under During tasks about being on their own. If they press, say you will go through it together at the end, and then do.
Keep your reactions level
A warm 'great!' after a success tells the participant there are right answers and makes the next stumble feel like a wrong one. Use the same plain 'okay' or 'thank you' whatever happens. Watch your face and your note-taking as well: a burst of typing after a mistake is easy to read.
Decide beforehand when you will step in
Set a rule for each task, such as moving on after a fixed number of minutes or once they say they would give up. When you reach it, close the task without blame: 'That is all I needed to see on this one.' If a later task depends on the one they missed, set the screen up for them and say only that you are moving to the next starting point.
Save opinions for the end
Questions about liking, wanting and changing belong in Wrap-up. Asked in the middle of a task, they pull the participant out of using the product and into reviewing it, and few people find their way back.
Making sense of what you heard
What they did outranks what they said
A participant who took six wrong turns and called the task easy has given you two facts, and the first weighs more. Use their words to explain the behavior you saw, not to overrule it.
Separate 'could not find it' from 'did not understand it'
Both look like a stalled task. The questions about what they were looking for and what a label means tell them apart, and so does showing the answer in the wrap-up. One is fixed by moving or renaming something, the other by rethinking it.
Go carefully with promises about the future
'I would definitely use this' costs nothing to say to a friendly stranger. Give weight to what a participant did in the session and to the specific obstacles they named, and little to predictions about their own behavior.
Write up while it is fresh
Spend ten minutes after each session with the note-taker and any observers, listing what each of you saw before discussing what it means. Count how many participants hit each problem and report it plainly: with a small group, say 'four of the six people we tested' and leave percentages out.
Mistakes to avoid
Questions with the answer inside
'Was that easy?' and 'did you see the button at the top?' both tell the participant what you hope to hear. Turn them around: 'how was that?' and 'what did you notice on that page?' If a question hands the participant an adjective to agree with, or names a feature they have not mentioned, rewrite it. The pointed questions under Wrap-up are safe only because the tasks are over and nothing is left to steer.
Explaining the design
The urge to say 'the menu is still a placeholder' is strong, especially when you made the thing. Every explanation teaches the participant something a real user would not know. Keep a note of what you wanted to explain: it is a list of what the product fails to say for itself.
Rescuing too soon
Watching someone struggle is uncomfortable, and seeing where they struggle is the reason for the session. A hint at the first sign of trouble erases the finding. Hold to the rule you set beforehand, and make sure the participant knows they can stop or take a break whenever they like.
Asking the participant to design it
'Where should this button go?' gets a confident answer from someone who has thought about it for four seconds. Ask what they were trying to do and what got in the way, and leave the redesign to the team.
Turning the test into an interview
A usability test has a product on the table and tasks to attempt. If the warm-up runs to twenty minutes of habits and needs, the tasks get squeezed. Questions about a person's life with no product in front of them belong in a separate discovery interview.