Skills on AI

Active theme: Light

User Interview Guide

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.

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.

View user-interview-guide/SKILL.md on GitHub