In a user research interview, how do you ask questions that reveal real behaviour rather than opinions, predictions or answers you led the participant to?
answer
- past behaviour beats future promises
- the last time you did it
- open, neutral, one thing at a time
- show me, then why
- silence and no pitching
basics
~20 sAsk open, neutral questions about specific past events — 'tell me about the last time you built the weekly report' — then probe with why and what happened next. Avoid hypotheticals, leading wording and pitching your solution, and let the participant do most of the talking.
solid answer
~40 sPeople are poor at predicting their own behaviour and eager to please an interviewer, so the technique is built around **specific past behaviour**. Anchor questions in a real instance — "Walk me through the last time you prepared the weekly revenue report" — and ask to be shown the actual artefacts where possible. Keep questions **open** (how, what, tell me about), **neutral** (not "don't you find the filters confusing?") and **single** (one topic per question). Probe with "why", "what happened next" and "what did you do instead". Avoid **hypotheticals** such as "would you use scheduled reports?", and never **pitch** or explain the product mid-session. Tolerate silence, since the most useful detail often comes after a pause. In B2B settings, separate the official process participants describe from what they actually do.
go deeper
Recall the core rules: ask about specific past events, keep questions open and neutral, avoid hypotheticals, and let the participant talk.
Rewrite weak questions into strong ones on the spot, and explain why hypotheticals, leading wording and double-barrelled questions distort answers.
Handle real sessions: participants describing the official process, feature requests, silence, and B2B buyers versus daily users, and show how you keep evidence clean.
Set interview standards across a team — guides, note-taking, consent and who may interview — so evidence from different researchers can be trusted and compared.
## Why interviews go wrong A **user research interview** is a one-to-one conversation to understand a person's goals, behaviour and context. It fails in predictable ways, because people: - **Predict their future behaviour poorly**: "Yes, I'd definitely use that" costs nothing to say. - **Generalise and tidy up**: "I usually…" describes an idealised routine, not what happened. - **Want to please the interviewer**, especially if they sense which answer is hoped for. - **Describe the official process** in B2B settings, rather than the workarounds they really use. Good technique designs around all four. ## Anchor on specific past behaviour The strongest question shape asks about **one real, recent instance**: | Weak question | Why it is weak | Stronger version | |---|---|---| | Would you use automated report scheduling? | Hypothetical, easy to say yes | Tell me about the last time you sent a report to your team. | | How do you usually build reports? | Invites an idealised routine | Walk me through the report you built on Monday. | | Don't you find the filters confusing? | Leading, signals the wanted answer | What happened when you set up the filters? | | How often do you export data, and why do you like it? | Two questions, and assumes liking | When did you last export data? What made you do it? | Where possible, ask participants to **show** the artefact: the spreadsheet they export to, the email they send, the dashboard they built. Screens contradict memory surprisingly often. ## Probe without leading - **Why?** and **What made you do that?** uncover motivations. - **What happened next?** keeps the story moving through the real sequence. - **What did you do instead?** reveals workarounds, which are the richest findings. - **Can you say more about that?** is safe after almost any answer. - **Echo their words** rather than substituting your product's terms. ## What the interviewer must not do 1. **Pitch or explain the product.** Once you explain how a feature works, you are testing your explanation, not their experience. 2. **Correct the participant.** A misunderstanding is data. 3. **Fill silences.** A pause usually means they are thinking; waiting often brings the detail that matters. 4. **Ask for design solutions as the goal.** Requests like "add a button" are clues to an underlying need, which you probe instead of recording as the answer. ## Running the session - **A discussion guide** lists topics and key questions, but the interviewer follows the participant's story rather than reading a script. - **A second person takes notes**, so the interviewer can listen; recording, with consent, protects against memory bias. - **Warm up** with easy context questions about role and responsibilities before the core topics. - **Close** by asking what you should have asked but did not. ## B2B specifics: the analytics dashboard For a B2B analytics dashboard, interviews involve people doing their jobs, not consumers at leisure: - The **buyer** who signed the contract and the **analyst** who uses the product daily have different goals; interview them separately. - Participants may be **cautious about criticising** tools their company chose, or about showing internal data, so agree in advance what can be shown. - The interviewer should **not be the account manager**, whose presence invites diplomatic answers. ## After the session - **Debrief within the hour** with the note-taker: the most surprising things heard, and anything that contradicted expectations. - **Write up observations, not conclusions**, tagged with the participant, while memory is fresh. - **Adjust the guide** if a question consistently confused people, and record the change so later sessions are read in that light. - **Follow through**: send the incentive promptly and, in B2B, tell the customer contact how the research will be used. These habits keep each interview usable in synthesis rather than a vague memory of a good conversation. The result is evidence about what people actually do and why — the input that synthesis turns into findings.
- What do you do when a participant asks for a specific feature during an interview?Treat it as a clue, not a requirement. Ask what they were trying to do when they wanted it, what they do today instead, and what happens if they cannot do it. The request points to an underlying need, and the team may find a better way to meet it than the feature the participant imagined.
- Why is a discussion guide not read word for word?Because the goal is to follow the participant's real story, which rarely matches the guide's order. A scripted reading makes the session feel like a questionnaire and cuts off threads that turn out to matter. The guide ensures the key topics are covered by the end, and keeps question wording neutral where it counts.
A careful investigator asks a witness 'what did you see?' rather than 'was the car red?', because the second question plants the answer it hopes to hear.
saying these in an interview costs you the question
- Asking users whether they would use a feature is good validation.
- Interviewers should explain how the product works when users seem confused.
- Participants' feature requests are the main output of an interview.
- Silence is awkward and should be filled with the next question.
- Reading the discussion guide word for word keeps interviews unbiased.