---
name: user-interview-guide
description: Use when asked to prepare questions for a user interview, customer interview, or discovery call — a qualitative conversation structured to surface real behavior and needs — as distinct from [[survey-design]], which is a standardized written instrument rather than an adaptive spoken conversation.
---

# User Interview Guide

A user interview guide is a prepared set of questions and prompts for a
qualitative conversation with a user or customer. Its purpose is to
surface what people actually do and actually struggle with, not to
collect opinions about hypothetical features. A guide is a support for
the conversation, not a script to be read verbatim.

## Key components

- **Open-ended questions** — questions that invite a story or a
  specific past example ("walk me through the last time you...")
  rather than ones answerable with yes or no.
- **A logical flow from broad to specific** — warm-up questions that
  build rapport and orient the conversation, moving toward specific,
  detailed questions about the behavior or problem being studied.
- **A plan for probing follow-ups** — prepared follow-up prompts
  ("what happened next," "why did you do it that way") for going
  deeper on an answer, rather than a fixed list of questions read in
  order regardless of what the interviewee says.
- **Questions about specific past behavior** — anchored to a real,
  recent, specific instance rather than general habits or preferences.
- **A close that leaves room for the unexpected** — a final "is there
  anything I haven't asked about that I should have" to surface
  whatever the guide's structure missed.

## Why asking about specific past behavior beats hypothetical features

People are unreliable predictors of their own future behavior. Asked
"would you use a feature that does X," most people will say yes to be
agreeable, to imagine a more organized version of themselves, or
because the question costs them nothing to answer positively — and
none of that predicts what they'd actually do if the feature existed.
Asking instead about a specific past instance — "tell me about the
last time you tried to do this" — gets a description of what actually
happened: what tool they reached for, where they got stuck, what they
worked around. That's evidence. A hypothetical answer is a guess.

## Common pitfalls

- **Leading questions** — phrasing that hints at the desired answer,
  such as "don't you find the current process frustrating?" instead of
  a neutral "walk me through the current process."
- **Asking about hypothetical features instead of past behavior** —
  "would you use a feature that..." invites polite speculation rather
  than evidence of actual pain points or workflow.
- **Following the guide too rigidly** — treating it as a script to read
  top to bottom regardless of what the interviewee says cuts off
  promising unplanned threads instead of probing them.
- **Skipping rapport-building** — jumping straight into specific,
  detailed questions before the interviewee is comfortable produces
  guarded, shorter answers.
- **Only asking about the product** — ignoring the broader context
  (what else the person tried, what alternatives exist) that explains
  why the product is or isn't being used.
- **Not leaving room for silence** — filling every pause with another
  question instead of letting the interviewee keep talking often cuts
  off the most useful part of an answer.

## Learn more

- [[survey-design]] for a standardized written instrument rather than
  an adaptive spoken conversation.
- [[research-proposal]] for the broader research plan a set of user
  interviews often serves as the method for.
- [[literature-review]] for reviewing what's already known before
  designing new interview questions from scratch.