60+ User Testing Questions That Actually Reveal Usability Issues

The short version: Good user testing questions are neutral, open-ended, and tied to what a person actually does in the product, not what they think they'd do. Ask context questions before the session, give task prompts and "what are you thinking?" nudges during it, and save your opinion-and-satisfaction questions for after, once behavior is already on the record. The single biggest mistake is leading the witness, asking "How easy was that?" instead of "How did that go?" Below are 60+ questions organized by stage, plus a table of what to ask instead of the usual traps.

Why the right user testing questions matter

You can run a flawless study, recruit the perfect participants, and build a beautiful prototype, and still walk away with garbage data. Usually it traces back to the questions. A leading question plants the answer. A vague one gets a vague reply. A yes/no question closes the door right when you wanted it open.

Question quality sets the ceiling on insight quality. If you ask "Was the checkout easy to use?" almost everyone says yes, partly to be polite, partly because they don't want to look like they struggled. You learn nothing. Ask "Walk me through what you just did to check out" and you get the actual story, including the moment they hovered over the wrong button for four seconds and quietly gave up on the discount code.

Leading and biased questions are the number one mistake in user testing, and they're sneaky because they feel helpful in the moment. The fix isn't complicated, but it does take discipline: stay neutral, ask people what they did rather than what they'd hypothetically do, and let silence do some of the work.

One thing to be clear about before the list: questions don't measure usability. Observed behavior does. What someone actually does, whether they complete the task, where they hesitate, what they click by mistake, how long it takes, is your primary signal. Self-report is unreliable; people misremember, rationalize, and soften the truth to be polite. So treat every question below as a way to explain behavior you watched, not a substitute for watching it. The rest of this guide is the questions themselves, sorted by when in the session you'd ask them. If you want the broader method behind all of this, our usability testing guide covers planning, recruiting, and analysis end to end.

Pre-test questions (before the session)

Pre-test questions do two jobs. They confirm you're talking to the right person, and they warm the participant up so they're comfortable thinking out loud later. Keep this part short. People came to test the product, not fill out a survey, and a long intro burns the goodwill (and the clock) you need for the tasks.

Screening questions

These run in your screener before anyone gets booked, not live in the session. They make sure the people you recruit actually match the audience you're designing for. A clean screener is the difference between five sessions of signal and five sessions of "well, they're not really our user, but..." If you're building one from scratch, our guide to writing screener surveys walks through how to set these up as qualifying logic so off-target people never make it onto your calendar.

1. How often do you [do the core task your product supports]? Filters for genuine frequency. Someone who books travel twice a year tests a travel app very differently than someone who books twice a month.
2. Which of these tools or apps do you currently use for [job to be done]? Reveals whether they're coming in cold or with strong habits from a competitor.
3. What's your role and how long have you been doing it? Confirms they sit in the segment you're targeting, and screens out people guessing at a persona.
4. Have you used [your product] before? If so, how recently? Lets you sort new users from returning ones so you don't mix first-impression data with experienced-user data.
5. Which of the following best describes how comfortable you are with [relevant technology]? Catches the extremes. A study aimed at mainstream users shouldn't be packed with power users.
6. In the last [time period], have you [made a purchase / completed the relevant action]? Confirms real behavior, not just stated interest.
7. Are you currently employed in market research, UX, or product design? Standard exclusion. Industry insiders test products differently than real users and can skew your results.

One rule matters more than the questions themselves: never telegraph the qualifying answer. If a participant can tell that "several times a week" is the response that gets them into a paid study, professional survey-takers will pick it whether it's true or not. Use multiple-choice options with believable distractors, mix the order, and avoid obvious yes/no qualifiers. The point of a screener is to filter people out honestly, not to hand them the password.

Background and context questions

These open the live session. They're conversational on purpose, the small talk that gets someone talking before you hand them a task. Each one should also tell you something about how they'll approach the product.

8. Tell me a bit about how you usually [accomplish the relevant goal]. Surfaces their existing workflow, so you can spot where your product fits or clashes with it.
9. What were you doing the last time you needed to [do this task]? Anchors them in a real memory instead of a hypothetical, which makes everything that follows more honest.
10. What tools or apps do you reach for most in this area? Tells you their mental model and the conventions they'll expect your interface to follow.
11. What usually frustrates you about [this kind of task or product]? Gives you a baseline of existing pain, so you can tell later whether your design fixes it or repeats it.
12. When you try something new like this, what makes you trust it (or not)? Reveals the trust signals that matter to this person, useful for onboarding and first-run design.
13. Walk me through the last time you [relevant scenario] start to finish. A storytelling prompt that loosens people up and exposes steps they'd never list if you asked directly.
14. Is there anything about [the product area] you've always wished worked differently? An easy open door that often surfaces the strongest unmet need of the whole session.

A note on these: don't describe the product yet. The moment you explain what it's "supposed" to do, you've biased every reaction that follows. Let them discover it.

Before the first task: set the frame

The most important thing you say in a session isn't a question. It's the short framing you give right before the tasks, and it's the part new moderators skip most often. Say some version of this, in your own words:

• "We're testing the design, not you." People assume they're being graded. Tell them plainly that any struggle is the product's fault, not theirs, and that confusion is exactly the data you need.
• "There are no right or wrong answers." This frees them to be honest instead of performing competence.
• "Please think out loud as you go." Explain that you want a running narration of what they're looking at, expecting, and reacting to. Demo it once if they freeze up.
• "I didn't design this, so don't worry about my feelings." Even when it isn't strictly true, distancing yourself from the work gets you far more candid feedback.
• Get recording consent on the record, remind them they can stop anytime, and confirm they're comfortable before you start.

Skip this and you'll spend the whole session fighting politeness bias. Spend ninety seconds on it and the rest of the questions actually work.

Task-based questions (during the session)

This is where the real data lives. Everything before was setup. Now you give the participant realistic tasks and watch what they actually do, prompting only enough to understand their thinking without steering it. For unmoderated studies, these become your on-screen instructions and think-aloud prompts; Great Question's unmoderated prototype testing records the screen and voice so you catch the hesitations you'd otherwise miss.

The golden rule here: ask about what's happening, never hint at what should happen.

Think-aloud prompts

Think-aloud is the backbone of usability testing. You want a running narration of the person's thoughts as they work. These prompts keep that narration going without putting words in their mouth.

15. What are you thinking right now? The workhorse prompt. Neutral, open, and you'll use it constantly.
16. What are you looking at on this screen? Tells you where attention lands first, which is rarely where you assumed.
17. What would you do next? Captures intent right before action, so you can compare what they planned to what they did.
18. You went quiet there, what's going through your head? Silence usually means confusion or concentration. This finds out which.
19. What did you expect to happen when you clicked that? Surfaces the gap between their mental model and the actual behavior of the interface.
20. How does this compare to what you expected? Open-ended reaction that works at any point without leading toward "good" or "bad."
21. Talk me through why you chose that option over the others. Reveals the decision logic behind a click, which is often more useful than the click itself.

A word of caution on probing mid-task. Two of these, "what did you expect to happen?" (19) and "why did you choose that?" (21), are really retrospective questions. Asking them in the middle of a task interrupts natural behavior and invites people to invent tidy reasons on the spot, which is its own kind of bias. During the task, keep your prompts light: "keep talking," "what's going through your mind." Save the deeper "why" probes for the moment a task wraps, or for a retrospective walkthrough at the end where you replay what happened together. The less you interject, the more real the behavior you're watching.

Navigation and findability questions

Half of usability problems are really findability problems. People can't complete the task because they can't find the thing. These questions and prompts isolate where wayfinding breaks down.

Use them sparingly, though. Asking "where would you go to do X?" before someone acts can prime them, and leaning on it turns observation into a pop quiz that makes people self-conscious. Your default should be to give a realistic task and watch where they actually go. Reserve the direct "where would you expect to find this?" questions for moments when someone is already stuck and you want to understand the dead end.

22. Where would you go to [accomplish a specific sub-task]? Ask before they act, then watch. The gap between where they say and where they look is gold.
23. How would you find [specific feature or piece of information] from here? Tests whether your labels and hierarchy match their expectations.
24. You're on this page, where do you think you are in the overall flow? Checks whether people keep their bearings or get lost.
25. If you wanted to go back and change [X], how would you do that? Reversibility is a quiet usability killer; this exposes it.
26. What do you think this button/link/icon does? Ask before they click. Mismatches here are direct evidence of unclear labeling.
27. Is this where you expected to end up? Neutral way to catch a navigation dead end without telling them they "went wrong."
28. What would you click first to get started? First-click testing in question form. First clicks predict task success better than almost anything else.

For deeper structural questions about labels and hierarchy, card sorting and tree testing are the dedicated methods; you can run both alongside these sessions if information architecture is the main thing you're investigating.

Comprehension questions

People can navigate to a screen and still have no idea what it's telling them. Comprehension questions check whether your copy, data, and visuals actually land.

29. In your own words, what is this page telling you? The cleanest comprehension check there is. If they can't paraphrase it, the content failed.
30. What does [specific term or label] mean to you? Jargon you stopped seeing years ago is often a wall for new users.
31. What do you think this number/chart/status is showing? Tests whether your data visualization communicates or just decorates.
32. What would you expect to happen if you [took a specific action] here? Checks whether the interface sets accurate expectations before the action.
33. Who do you think this product is for? A revealing positioning check. If the answer is "not me," you've found a messaging problem.
34. What's the main thing you're supposed to do on this screen? Confirms the primary action is actually obvious, not buried.

Throughout the task section, watch your phrasing. The same question can be neutral or leading depending on a single word.

• Instead of "Was that button easy to find?", ask "How did you find that button?"
• Instead of "Do you like this layout?", ask "What's your reaction to this layout?"
• Instead of "Was that confusing?", ask "What was going through your mind there?"
• Instead of "Don't you think this is faster?", ask "How did the speed compare to what you're used to?"
• Instead of "Would you use this great feature?", ask "When, if ever, would you use this?"

Post-test questions (after the session)

Now that behavior is on the record, you can ask for opinions. The order matters: if you ask "How satisfied are you?" before the tasks, you get a guess; ask it after, and the answer is grounded in something real that just happened. Keep these tied back to specific moments from the session whenever you can.

There's a timing distinction worth getting right, because most guides miss it. Post-task questions are asked immediately after each individual task, while it's fresh, the Single Ease Question and the confidence question below are the classic examples. Post-session questions are asked once, at the very end, after all the tasks are done, things like SUS, NPS, and your open-ended reflection. Don't save a per-task ease rating for the end; you'll get a blurred average instead of a clean read on each task. And don't run the full SUS after every task; it's designed to score the whole experience once.

Overall experience questions

35. Overall, how did that go for you? Deliberately open. Whatever they lead with is what mattered most to them.
36. What stood out, good or bad? The "or bad" gives explicit permission to criticize, which most people otherwise won't.
37. If you had to describe this product to a friend in one sentence, what would you say? A brutal clarity test for your positioning.
38. What was the most frustrating moment? Direct route to the sharpest pain, and people remember frustration vividly.
39. What was the easiest part? Tells you what to protect. Not everything needs fixing.
40. Was there a point where you felt stuck or unsure? Lets them flag confusion you might not have caught on screen.
41. If you could change one thing, what would it be? Forces a priority instead of a wish list, so you learn what actually bugs them most.

Satisfaction and preference questions

This is where standardized metrics earn their place. Mixing a couple of quantitative scales with your qualitative questions lets you track usability over time and across studies. The two most common are the System Usability Scale (SUS), a 10-item questionnaire scored out of 100, and a single-question version of Net Promoter Score.

42. On a scale of 1 to 7, how easy or difficult was it to complete that task? A Single Ease Question (SEQ). Ask it right after each task, not at the end. Quick, per-task, and surprisingly predictive.
43. How well did the product meet your expectations, on a scale of 1 to 5? Quantifies the expectation gap you've been probing qualitatively.
44. How likely are you to recommend this to a colleague or friend, from 0 to 10? The NPS question. Treat it as directional at best here: NPS is a loyalty metric, and asking someone to vouch for a product they met ten minutes ago is shaky. SUS and SEQ are the more defensible usability measures. The number matters less than the "why" you ask right after.
45. (SUS) I think I would like to use this product frequently, strongly disagree to strongly agree. One of the ten standard SUS items, run at the end of the session. Use the full set if you want a comparable score; cherry-picking single items breaks the validated benchmark.
46. Compared to what you use today, is this better, worse, or about the same? Forces a real-world comparison instead of a vacuum rating.
47. What would make you choose this over [their current tool]? Surfaces the switching trigger, which is product and marketing gold at once.
48. How confident were you that you were doing things correctly? Best asked right after a task, alongside the SEQ. Confidence and correctness often diverge, and the gap is a usability signal in itself.

A quick warning on rating scales: a "7 out of 7" with no explanation is almost useless. Always pair the number with "What made it a 7 and not a 5?" The number tracks the trend; the follow-up tells you why.

Open-ended reflection questions

End wide. These give people room to surface anything the structured questions missed.

49. Is there anything you expected to see that wasn't there? Catches missing features and content from the user's point of view.
50. What, if anything, would stop you from using this? Surfaces dealbreakers and objections you can't see on screen.
51. Who else do you think would find this useful, or useless? A sideways way to learn about audience fit and edge cases.
52. If this were your product, what would you fix first? Reframes them as an owner, which tends to produce sharper, more honest answers.
53. Was there anything that surprised you? Surprises, good or bad, mark the spots where the design defied expectations.
54. Anything we didn't talk about that you want to mention? The catch-all. Never skip it; some of the best findings arrive here.

Follow-up questions for deeper insights

Most first answers are surface-level. "It was fine." "Pretty easy." "I don't know, just didn't like it." Follow-up probes are how you get from the polite version to the real one. The skill is staying curious without leading, which mostly means reflecting their words back and then waiting.

55. Tell me more about that. The most useful five words in research. Says nothing, opens everything.
56. What do you mean by [their exact word]? Don't assume "annoying" or "clunky" means what you think. Make them define it.
57. You mentioned it was confusing, can you point to where? Turns a vague feeling into a specific, fixable location in the interface.
58. What were you hoping would happen instead? Moves from complaint to the underlying expectation, which is what you can actually design for.
59. Has that happened to you before with other tools? Tells you whether it's a problem with your product or a category-wide habit.
60. Why do you think that is? Pushes past the symptom toward the cause. Use sparingly; too many "why"s feels like an interrogation.
61. Can you walk me through that again, slowly? When something happened fast, a replay in slow motion often reveals the real breakdown.

The technique underneath all of these is simple and hard: shut up. After you ask, count to five in your head before filling the silence. People almost always add the most useful part of their answer in that pause, the part they were deciding whether to say. The same probing muscle powers good user interviews, so if you run both methods, it's worth getting fluent in it.

Questions to avoid (and what to ask instead)

Some questions feel natural and do real damage. They lead the participant, stack two questions into one, or ask people to predict their own future behavior (which humans are famously bad at). Here are the worst offenders, why they hurt, and what to ask instead.

👉 [HTML EMBED: “Questions to avoid” table — paste embed-questions-to-avoid.html into a Webflow HTML Embed element here]

If you take one thing from this section: when in doubt, ask "what" and "how," not "did" or "do you." "What" and "how" open the answer up. "Did" and "do you" snap it shut. The same neutral-questioning habit makes or breaks your user interviews too, so it's worth drilling until it's automatic.

How to choose the right questions for your study type

Not every question fits every method. A think-aloud prompt is perfect in a moderated session and impossible in a survey. Your phrasing and your mix of open versus closed questions should shift with the method you're running.

👉 [HTML EMBED: “Study type comparison” table — paste embed-study-type-comparison.html into a Webflow HTML Embed element here]

The practical move is to combine them. Run an unmoderated test to see where lots of people get stuck, then run a handful of moderated sessions to understand why. Layer a short SUS survey on top to track the score over time. The reason teams end up wanting all three in one place is sequencing: the slow part isn't asking the questions, it's recruiting people and stitching the results together across tools. When Asana consolidated its research onto Great Question, its research cycles dropped from two weeks to two or three days, mostly because the recruiting and the running and the analysis stopped living in separate places. You can run moderated, unmoderated, and survey studies against the same participant pool, recruited straight from your own customer panel, and keep every transcript in one research repository so the questions you ask actually turn into findings you can act on.

User testing question template (60+ questions)

Here's the full set in one place, organized by stage, so you can copy it into your study plan and trim to fit. Pull the ones that match your method and your product, swap the bracketed bits for your specifics, and you've got a session guide. For pre-built, customizable versions of these (plus SUS and NPS), grab one from Great Question's template library.

Pre-test, screening (run in your screener) 1. How often do you [do the core task]? 2. Which tools do you currently use for [job to be done]? 3. What's your role and how long have you done it? 4. Have you used [product] before? How recently? 5. How comfortable are you with [relevant technology]? 6. In the last [period], have you [completed the relevant action]? 7. Do you work in market research, UX, or product design?

Pre-test, background and context (start of session) 8. How do you usually [accomplish the goal]? 9. What were you doing the last time you needed to [task]? 10. Which tools do you reach for most here? 11. What frustrates you about [this kind of task]? 12. What makes you trust a new tool, or not? 13. Walk me through the last time you [scenario], start to finish. 14. Anything about [product area] you wish worked differently?

During, think-aloud prompts 15. What are you thinking right now? 16. What are you looking at on this screen? 17. What would you do next? 18. You went quiet, what's going through your head? 19. What did you expect to happen when you clicked that? 20. How does this compare to what you expected? 21. Why did you choose that option over the others?

During, navigation and findability 22. Where would you go to [sub-task]? 23. How would you find [feature/info] from here? 24. Where do you think you are in the overall flow? 25. If you wanted to change [X], how would you do that? 26. What do you think this button/icon does? 27. Is this where you expected to end up? 28. What would you click first to get started?

During, comprehension 29. In your own words, what is this page telling you? 30. What does [term/label] mean to you? 31. What is this number/chart/status showing? 32. What would you expect if you [took an action] here? 33. Who do you think this product is for? 34. What's the main thing you're supposed to do here?

Post-test, overall experience 35. Overall, how did that go? 36. What stood out, good or bad? 37. Describe this product to a friend in one sentence. 38. What was the most frustrating moment? 39. What was the easiest part? 40. Was there a point you felt stuck or unsure? 41. If you could change one thing, what would it be?

Post-test, satisfaction and preference 42. 1 to 7, how easy or difficult was that task? (SEQ) 43. 1 to 5, how well did it meet your expectations? 44. 0 to 10, how likely to recommend it? (NPS) 45. SUS item: I'd like to use this frequently (disagree to agree). 46. Better, worse, or the same as what you use today? 47. What would make you switch from [current tool]? 48. How confident were you that you were doing it right?

Post-test, open-ended reflection 49. Anything you expected to see that wasn't there? 50. What would stop you from using this? 51. Who else would find this useful, or useless? 52. If it were yours, what would you fix first? 53. Was there anything that surprised you? 54. Anything we didn't cover that you want to mention?

Follow-up probes (use throughout) 55. Tell me more about that. 56. What do you mean by [their word]? 57. You said it was confusing, can you point to where? 58. What were you hoping would happen instead? 59. Has that happened with other tools before? 60. Why do you think that is? 61. Can you walk me through that again, slowly?

Run your next user test with Great Question. Recruit from your own customers, run moderated, unmoderated, and survey studies in one platform, and keep every answer searchable in one place. Start free.

FAQ

How many questions should I ask in a user test?

Fewer than you think. For a 30-minute moderated session, plan for 2 to 4 realistic tasks and roughly 8 to 12 spoken questions, leaving plenty of room for follow-up probes and silence. The tasks and the think-aloud are where the data comes from; the questions are there to fill gaps, not to fill time. For unmoderated tests, keep it tighter still, since there's no moderator to clarify a confusing prompt. Quality and neutrality beat quantity every time.

What's the difference between user testing and usability testing questions?

In practice they overlap almost completely, and most teams use the terms interchangeably. "Usability testing" questions tend to focus specifically on whether someone can use an interface, can they find it, understand it, and complete the task. "User testing" is a slightly broader umbrella that can also include attitudes, preferences, and desirability, not just task success. The questions in this guide work for both. If you want the full method, not just the questions, see our usability testing guide.

Should I use open-ended or closed-ended questions?

Both, at the right moments. Open-ended questions ("What are you thinking?", "How did that go?") are your default during tasks and exploration, because they invite the participant to tell you things you didn't know to ask. Closed-ended questions and rating scales (SEQ, SUS, NPS) come after, when you want comparable, trackable numbers. A good rule: open up to discover, close down to measure. And whenever you use a scale, always follow the number with an open "why" so you know what the rating actually means.