Right after a user interview wraps, there’s a strange confidence that every hypothesis going in was correct. Read the transcript back, though, and it often turns out the questions themselves were doing the leading. “You’d say this feature is convenient, right?” isn’t a window into what the user actually thinks — it’s a tool for confirming what the interviewer already expected to hear. The point of a user interview isn’t to reconfirm what the team already believes. It’s to surface what nobody on the team knew yet.
1. Why Every Interview Seems to Confirm the Hypothesis
Confirmation bias starts at the design stage, before a single question is asked out loud. When a team already wants a particular conclusion, the question guide gets written to point that way, and the moderator — often without noticing — nods and moves on quickly whenever the answer lands where they hoped. When an answer runs the other way, it’s easy to wave it off as “an unusual case.” If every interview ends up supporting the hypothesis, that isn’t a sign the interview went well. It’s a sign the design was biased from the start.
2. A Broken Sample Breaks Everything Else
No matter how carefully a question guide is written, a biased participant pool distorts the entire result. The common mistake is recruiting whoever is easiest to reach — a colleague’s friend, a heavy user who already likes the product. Samples built this way tend to gather only the extremely satisfied or the extremely frustrated, which buries the behavior of the ordinary users who actually make up most of the base.
Choosing participants takes a deliberate effort to match the real user base as closely as possible. New users and long-time users, frequent users and occasional ones, all need to be represented, or the whole sample quietly tips in one direction.
3. How to Stop Leading the Witness
The simplest rule is to never name the feature first — ask about the behavior, then check the feature afterward. Hypothetical questions are just as dangerous. “Would you use a feature like this?” tends to get a polite “yes” from almost anyone, regardless of whether they’d actually use it. Asking about a specific situation the person has actually lived through is far more reliable. Nielsen Norman Group’s guidance on user interviews makes the same point consistently: favor open-ended, behavior-based questions over hypothetical ones.
Leading questions
“Have you tried the search filter feature?” “Would you use something like this?” — what comes back is polite agreement with the interviewer’s expectation, nothing more.
Behavior-based questions
“Walk me through how you actually search for something you want to buy.” — the real answer lives in a specific, past experience.
4. Sitting With the Silence, Splitting the Roles
The moment moderators find hardest to tolerate is the few seconds of silence right after a question. To fill that discomfort, it’s tempting to rush into the next question — or worse, to offer up a sample answer, which amounts to answering on the participant’s behalf.
Ask the question.
Wait at least three seconds without filling the gap yourself.
The real insight rarely lives in the first sentence — it shows up in the second or third, the part the participant adds unprompted.
💡 Pro tip — If the silence feels awkward and you fill it with a sample answer, you’ve effectively answered for the participant. Hold at least three seconds of quiet after every question before moving on.
Running an interview solo, while also trying to take flawless notes, is another common mistake. When the attention that should go to the question and the reaction gets split toward writing things down, the natural thread into a follow-up question breaks, and good follow-ups get missed. Where possible, split the moderator role from the note-taker role; where that isn’t possible, record the session and focus entirely on the conversation. Splitting the roles has a second benefit too: the note-taker can catch an interesting reaction the moderator missed and flag it as worth digging into, so two sets of eyes cover what one alone would let slip.
Closing thoughts
Even a well-run interview can get distorted at the writing-up stage — a summary quietly reshaped to fit the conclusion the team wanted, or two people who watched the same session walking away with completely different takeaways. The fix is to keep interpretation and fact separate on the page, and to build the habit of summarizing with the original quotes still attached rather than paraphrasing them away. Whatever insight comes out of that process should feed straight into the next design brief — otherwise the interview just ends up filed away and forgotten.
Does any question contain the feature’s name or hint at the answer you want?
Did you ask about past experience instead of a hypothetical (“would you use…”)?
Did you hold at least three seconds of silence after each answer before moving on?
Does the participant mix reflect the real user base, not just whoever was easy to reach?
Did you separate the moderator and note-taker roles, or at least record the session?
Does your summary still carry the original quotes alongside your interpretation?
Did you resist writing off an unexpected answer as just an unusual case?
A user interview isn’t a place to confirm an answer — it’s a place to ask the question again. Before your next one, read the question guide out loud and check what answer you’re quietly hoping to hear.
Design Daily Life · Notes on design, daily