Usability Testing vs User Interviews: When to Use Each Method for Better Product Decisions
A practical framework for choosing usability testing or user interviews based on the product decision you need to make.
If you choose the wrong method, you get the wrong answer
Teams treat usability testing and user interviews as interchangeable because both involve talking to users. They are not. A user interview helps you understand a person's world: their goals, constraints, and decision criteria. Usability testing helps you observe whether they can actually use a product to complete a task.
That distinction matters because of the say-versus-do gap. In interviews, people tell you what they remember or prefer; in usability tests, they show you what they actually do. Interviews surface themes and unmet needs but risk treating stated preferences as behavior. Usability tests surface failure points but risk showing friction without context. They answer different questions.
Use interviews when the decision is about the problem
Interviews are the better choice when you are still deciding what to build, who it is for, or which problems matter most. If a PM wants to know why new customers stall after signup, start with interviews — the issue may not be the onboarding flow at all, but that users lack data access or do not know who owns setup internally. A usability test alone shows on-screen confusion without revealing that cause.
Good interview evidence is grounded in specific past behavior, not hypotheticals. Instead of "Would you use this?", ask "Tell me about the last time you handled this," "What did you try first?", and "Who else had to approve it?" Those produce real constraints and decision criteria a team can act on. A strong interview guide matters more than most teams realize.
Use usability testing when the decision is about task performance
Usability testing is right when you already have something to evaluate: a prototype, a live feature, a checkout flow. The question is not whether users like the design — it is whether they can use it. For a new billing flow, an interview yields weak evidence like "this seems straightforward," while a test shows whether users can actually update payment details and recover from an error.
Strong usability testing uses realistic tasks based on actual goals, representative participants, minimal moderator interference, and clear success criteria. Instead of "What do you think of this dashboard?", give a task:
Find which campaign drove the most qualified leads last month and share that result with your manager.
That reveals whether the navigation, labels, and reporting flow work together. General opinions do not.
A decision framework by stage
Use interviews in early discovery and opportunity sizing, when you need to know whether you are solving a real problem. Use usability testing at the prototype and pre-launch stages, when you need to know whether users can complete key tasks. When post-launch adoption is low, use both.
A simple rule: if the team is debating the problem, interview; if the design, test; if both, sequence them. For the survey-vs-interview tradeoff, see When to Use Surveys vs Interviews.
Common mistakes
The biggest interview mistake is asking people to predict future behavior; ask about past behavior instead. The biggest usability mistake is turning the session into a feedback interview: "Do you like this?" makes participants switch from doing to commenting. Start with tasks and save reflective questions for the end. Other errors: recruiting participants who do not match the decision, and testing polished UI when the uncertainty is still about the problem. Good recruitment often separates useful research from misleading.
Combine both, and recruit enough of the right people
The strongest programs sequence methods: start with interviews to understand goals and unmet needs, prototype from those insights, then run usability tests to see whether it works. The reverse also works — when a test reveals hesitation at a step, follow-up interviews explain why.
For sample size, recruit enough to hear patterns: roughly 5–8 interviews per meaningful audience, and 5–7 participants to uncover major usability issues in a focused flow. Comparing segments or validating high-risk workflows needs more — the point is recruiting enough of the right people, not hitting a number.
So when your team says "we need to talk to users," ask first: what decision are we trying to make? The best teams are not loyal to methods — they match evidence to the decision at hand.