User Interviews
Ask less. Listen more. A user interview is a structured conversation designed to understand how someone thinks, what they do, and why — not to validate what your team already believes.
01 — TL;DR
Two sentences.
A user interview is a structured one-on-one conversation in which a researcher asks open-ended questions to surface how a specific person thinks about, experiences, and navigates the domain your product operates in — with the goal of discovering things the team did not already know. The output is not a list of feature requests; it is observations about goals, behaviours, mental models, and frustrations that inform design decisions more reliably than any internal discussion.
User interviews became standard UX practice in the 1990s through work by Don Norman, Jakob Nielsen, and others who demonstrated that conversation with users produced better products than expert review alone. What makes interviews irreplaceable: no amount of analytics tells you what users were trying to do before they gave up, what alternative they considered, or what they tell colleagues when recommending or discouraging your product.
02 — When to Use
Apply this when…
When NOT to apply it
Skip it when you need statistical representativeness (five to eight interviews reveal patterns but not percentages), when the question is preference-based (use a survey), when you have no time to synthesise before the decision, or when participants are reluctant and would produce low-quality data.
03 — How It Works
The mechanism
User interviews create a structured conversation that draws out behaviour, context, and reasoning users would not surface unprompted. The researcher asks about what users actually do, how they do it, what has gone wrong, and how they have worked around it. The value is in the specifics that emerge from real experiences.
Not a focus group, not a usability test, not a survey
A focus group captures group dynamics and social consensus. A usability test observes task performance with a specific interface. A survey measures aggregate sentiment. A user interview reveals individual context, mental models, and real-world behaviour. Each answers different questions; none substitutes for the others.
04 — Real Example
Intercom's jobs-to-be-done interviews and the messaging pivot
In Intercom's early years, the team conducted interviews structured around past behaviour — "walk me through the last time you used Intercom to communicate with a customer." What emerged was that customers were using the same product for three fundamentally different jobs: reactive support, proactive onboarding, and marketing to existing customers. Each had a different mental model, workflow, and measure of success.
This finding came entirely from interviews and could not have come from analytics. The structural decision to reposition Intercom around three distinct jobs — and eventually build separate product lines — was a direct consequence of the interview programme. That is the class of decision user interviews exist to inform.
05 — In the Wild
Test yourself & see real examples
No examples yet — be the first.
Spotted a product decision clearly made without talking to users — or one where the depth of understanding suggests someone did the interview work? Submit what you observed.
Seen User Interviews skipped in a real product? Help grow the evidence base.
06 — Common Mistakes
Where teams go wrong
07 — Variations & Related Principles
Connected ideas
User interviews sit within a broader qualitative toolkit. Understanding the differences helps teams use interviews for the questions they are suited to answer.
The most important pairing is user interviews with affinity mapping. Interviews generate rich individual observations; affinity mapping reveals which represent shared patterns. Without affinity mapping, findings depend on the researcher's memory. Without interviews, affinity mapping has no data of sufficient quality. Together they form the complete generative research loop.
08 — 10-Min Exercise
Run it right now
⏱ 10 minutes · Solo · No prep
1. Write five questions you would typically ask in a user interview about your product. Write them exactly as you would ask them — do not idealise.
2. Classify each as Evaluative (E — asks to assess), Hypothetical (H — imagined future), or Behavioural (B — real past experience).
3. For every E or H question, write a Behavioural replacement: "Tell me about the last time you [did the thing]" or "Walk me through what happened when [the situation]."
4. Compare your originals to your replacements. If the replacements feel harder to answer — requiring real experience rather than opinion — that difficulty is the point. Research that works only on users with real domain experience produces real findings.