Designing and Conducting User Interviews

Premise — what an interview can and cannot confirm

A user interview is a means of understanding the background and context of "why someone took an action"; it is not a means of directly telling you "what to build so it will sell." Respondents cannot accurately predict their own future behavior, and user-research practice widely notes that answers to hypothetical questions such as "If there were a feature like X, would you use it?" correlate almost not at all with actual usage intent. Where interviews are strong is in reconstructing concrete events that have already happened. Conversely, interviews are poorly suited to questions that require measuring "quantity," such as reactions to pricing or the prioritization of features. Leave those to surveys and log analysis.

Procedure

1. Decide your recruiting criteria first

If you reach out while leaving "who to ask" vague, your insights will scatter. Set criteria by "behavior," not "attributes." For example, narrow by actual behavioral history, such as "people who have tried to solve a similar problem on their own within the last 30 days." As for numbers, a common approach in qualitative-research practice is to keep each round to roughly five to eight people and begin synthesis once patterns start to emerge. Nielsen Norman Group's usability-study rule of thumb likewise holds that repeated small rounds are more efficient than a single large-scale study. That said, when your target spans multiple segments, you need to secure at least three to five people per segment; otherwise one loud voice will skew the overall conclusion.

2. Design questions that don't lead

Build questions around "past, concrete, behavior" rather than "future, hypothetical, opinion."

Bad: Would you use it if there were this feature?
Bad: What do you think about X?
Good: When did you last face that problem? What did you do then?
Good: At the time, were there other approaches you considered? Why didn't you choose them?

"What do you think" questions put the respondent in the position of a critic and make it easy to elicit socially desirable answers. "What did you do then" questions, by contrast, make them recount concrete events from memory, so there is less room for embellishment.

3. Conducting it — the respondent talks, the interviewer digs

For a one-hour session, a good guideline is to keep the interviewer's total speaking time under ten minutes. Just two habits — waiting three seconds when the other person struggles to answer, and digging one level deeper with "specifically?" when a vague term comes up — go a long way toward preventing tangents and over-generalization. Assigning a separate person to take notes together lets the facilitator concentrate on listening.

4. Synthesis — converting notes into insights

Immediately after the session, while your memory is fresh, organize your notes by separating "what was said" from "interpretation." Lay out the statements from multiple sessions side by side, group together paraphrasings of the same problem, and adopt as insights only the contexts that recur. A statement that only one person made stays as a "candidate hypothesis," to be confirmed in the next round.

Applied example — an interview guide template

Intro (3 min): Explain the purpose, confirm consent to record
Warm-up (5 min): Confirm recent work and usage context
Main body (35 min):
  - Tell me about a specific situation where you recently faced that problem
  - What was the first thing you did at that point?
  - Were there other options you considered? What were the reasons you didn't choose them?
  - Did you consult anyone? Who, and why that person?
  - What happened as a result? Are you still using the same approach now?
Closing (5 min): Check for anything missed, ask for referrals

Keep the main-body questions to about five. An overstuffed guide turns into the task of reading questions aloud and robs you of room to dig deeper.

Verification — checking what you've produced

Confirm that a synthesized insight meets two conditions: "did it emerge independently from multiple respondents?" and "is it grounded in a concrete event?" If even one of these is missing, treat it not as an insight but as a hypothesis, and corroborate it in the next interview round or with behavioral data.

Common pitfalls

The most frequent failure is that the person who wrote the questionnaire unconsciously leads respondents toward the "answer they hope for." Phrasings that seek agreement, such as "Don't you think this is convenient?", change the direction of answers even if used only once. Another trap is organizing an interview with the motive of validating someone internal's opinion. In this case you tend to pick up only the convenient statements. An interview should be designed not as an occasion to prove a hypothesis but as an occasion where the hypothesis can be broken. That said, it is also dangerous to finalize decisions on qualitative interviews with a small number of people alone. You need to combine them with quantitative data, dividing the labor between confirming direction and confirming scale.

Read next

How to organize the collected statements into the Jobs to be Done format is covered in Using the Jobs to be Done Framework Correctly. A mechanism for maintaining contact with users continuously on a weekly basis, rather than ending with a one-off study, is explained in Continuous Discovery and the Opportunity Solution Tree.