How to run a user interview

Interviews should collect facts, not opinions. A four-stage structure, four probes, and six things to avoid.

The goal of an interview is not to collect opinions. It is to reconstruct one real experience that actually happened. You want facts, not evaluations. "I think it's pretty good" is not data; "last Wednesday I spent forty minutes copying a table by hand" is. What people say and what they do are usually two different things — interviews should go after the second.nng-interview

What you'll run into:

• An hour in, your notes are full of "he thought it was fine"
• The person keeps evaluating your idea, and you keep explaining it
• You talk to five people and get five different answers you can't summarize

Four stages

An interview roughly runs in four stages, and each one has its own job.

Never bring up your solution during any of this. The moment it appears, the conversation stops being "their experience" and becomes "a review of your idea" — the rest of the hour is wasted.

Four probes to dig deeper

When they answer with a generalization, dig with these four. You have hit the right depth when they start telling specifics.

• And then? The simplest and most effective. Have them finish the steps — don't interrupt, don't comment. Use it to rebuild the process.
• Why did you do it that way that time? Ask about that one occurrence, not "why do you usually do it this way." Use it to dig for the motive.
• How did it feel at the time? Annoyed, panicked, indifferent — emotional intensity maps directly to the pain dimension. Use it to gauge the pain.
• Can you show me? Have them open that spreadsheet, that chat, that folder. What you see is ten times more reliable than what you hear. Use it to get facts.

The fourth is the most useful and the easiest to forget. People automatically polish and simplify their own workflow when they describe it — but the spreadsheet on their computer doesn't.

Six things to avoid

• Don't ask hypotheticals. "If there were a feature… would you use it?" The answer is always yes. Ask how they did it last time instead.
• Don't bake the answer into the question. "Do you find the input too slow?" He'll just nod along. Ask "how did that step feel?" instead.
• Don't rush to fill silence. A three-second pause isn't emptiness — it's recall. The moment you speak, that recall is gone.
• Don't correct them. Wrong feature name, wrong method — don't interrupt. How they understood it is itself information.
• Don't only ask about the smooth parts. Ask specifically about "the one time it went really wrong." The exception carries the most signal.
• Don't interview alone. Ideally one person just takes notes. Guiding and recording at the same time means you miss more than half.

After the interview

The value of an interview shows up when you organize it. Do it the same day — after one day, memory starts to warp. Split the notes into four columns: the exact quote, the fact that actually happened, the judgment you draw from it, and its credibility. The quote is what they said; the fact is whether it really happened; the judgment is your inference; credibility follows from whether a fact backs it up. For any row where the middle column is empty, the third column should have no conclusion — "I'd probably use it later" has no fact behind it, so mark it low. "It always takes forever" only earns high credibility when paired with "last Wednesday I spent forty minutes copying by hand." Keeping the columns separate is what stops you from treating "what they said" as "what happened."