How to write a discussion guide for user interviews
How to write a discussion guide that produces evidence: the research question, the arc, the warmup, the open-ended core, planned probes, and a pilot.
Most teams learning how to write a discussion guide write the same artifact on the first attempt: a numbered list of fifteen questions, in the order they were thought of, that lasts about four minutes in the actual interview. By question five, the participant has answered question seven. By question nine, the interviewer is reading from a script that no longer fits the conversation in the room, and the rest of the call is improvisation that the next reader of the transcript cannot reproduce. The guide that opened the call as a structured instrument finished it as a piece of paper nobody looked at.
This is a working playbook on writing a discussion guide that survives contact with a real participant: what the guide is for, the arc that holds it together, the questions you actually need (and the ones you can throw away), the probes you plan in advance, and the pilot that tells you whether any of it works.
What a discussion guide is
A discussion guide is the short document a researcher writes before a series of interviews to lock down the research question, the topical arc, the opening warmup, the open-ended core questions, the planned probes for each, and the close. It is not an interview script. The point is not to ask every question in order. The point is to walk into every conversation with the same shape in mind so the transcripts compare cleanly later.
A good guide fits on one or two pages. It names the research question at the top so the interviewer can decide, mid-call, whether a tangent is worth following. It groups questions by topic, not by importance, so the participant can move through a natural arc instead of feeling cross-examined. And it lists the probes the interviewer should reach for when an answer is too short or too polished to be useful.
Nielsen Norman Group's working description of user interviews as a method treats the guide as the difference between an interview that produces evidence and a conversation that produces opinions. The instrument is the guide. The interviewer is the operator.
Why most discussion guides break in the room
Three failure patterns show up across most teams writing a guide for the first time. They are worth naming because the fix is not "write a better guide", it is "write a different shape of guide".
The first failure is treating the guide as a questionnaire. Fifteen questions, fifteen answers, the interview is a survey read aloud. A questionnaire optimizes for coverage. An interview optimizes for depth on the few questions that matter, and the guide should encode that choice. A page of fifteen questions tells the interviewer to keep moving. A page with five questions and a probe list under each tells the interviewer to stay.
The second failure is writing the guide from the team's vocabulary. "How do you feel about our onboarding flow?" is a question the team understands. The participant does not call it "onboarding flow". They call it "when I signed up". A guide written in product language teaches the participant to answer in product language, and the transcript that comes back is a mirror of the assumptions the interview was supposed to test. The fix is in the question itself: see how to write user research questions for the prompt-craft side, and how to apply the Mom Test for the bias side.
The third failure is mistaking the guide for the research plan. The plan is strategic: what is the team deciding, who are we talking to, what evidence would change the decision. The guide is tactical: the next 45 minutes with one specific participant. Teams who collapse the two write guides that pretend to answer plan-level questions ("does the market want this?") with participant-level conversations, and end up with neither. Keep them separate. The plan lives in how to write a user research plan. The guide is downstream of that document.
How to write a discussion guide, step by step
Seven steps. They produce a guide that fits on a single page, holds shape under pressure, and gives the interviewer permission to follow the conversation rather than the list.
01 · Anchor the guide to one research question
Every guide opens with a single sentence at the top: the research question this round of interviews is meant to answer. Not three. One. "Why are new signups churning before they complete the second key workflow?" is a research question. "What do users think of our product?" is a survey topic. The first sentence is the rudder. When a tangent surfaces mid-call, the interviewer asks themselves whether it touches the question at the top of the page. If it does, follow it. If it does not, mark it and move on.
A surprising number of guides do not have this sentence at all. The team knows roughly what they are after, the questions get written from intuition, and the interviewer reads them in order. The transcripts come back interesting and unactionable, because there was no single question to organize them against during synthesis. Write the sentence first, and the rest of the guide gets shorter.
02 · Sketch the arc before the questions
Before you write a single question, sketch the arc of the conversation. Three or four topical blocks, in the order they would naturally unfold for a participant who has agreed to spend 30 to 60 minutes with you. A typical arc for a discovery interview: their context, the last time they did the relevant task, what got in the way, what they tried next. A typical arc for a usability interview: what they were trying to accomplish, the first three minutes inside the product, where they got stuck, what they would have done if you were not watching.
The arc is the participant's narrative, not the team's question list. Topics flow from neutral and broad to specific and sensitive. Pricing and willingness-to-pay live near the end, not the beginning. Anything emotional (frustration, churn reasons, organizational politics) lives after rapport is established, not in the opener.
Sketch the arc on a piece of paper. Five minutes. If the topics do not fit on the paper, the interview is too long for one session and the guide is doing two jobs.
03 · Write a warmup that disarms
The first three minutes of an interview decide the next forty. A cold opening on the strategic question produces a defensive participant who answers in headlines. A warmup that establishes the participant as the expert produces a different conversation entirely.
The warmup is two or three questions about the participant's everyday context: their role, the shape of their week, the last time they did the broad activity the study is about. None of them are about your product. They serve one purpose: to get the participant talking in specifics and in past tense before the interview proper begins. A participant who has just described a Tuesday morning in concrete detail is in the mental mode you want them in for the rest of the call. A participant who has just been asked "what do you think of our product" is not.
The warmup also gives the interviewer one cheap calibration: a participant who answers the warmup in vague generalities is going to need probes for the rest of the call. A participant who answers the warmup with specifics will mostly probe themselves.
04 · Build the open-ended core
The core of the guide is three to six open-ended questions, each tied to the arc and each capable of producing a paragraph rather than a sentence. Open-ended means the question cannot be answered with yes, no, or a number. "Did you find the dashboard easy?" is closed. "Walk me through the last time you opened the dashboard. What were you trying to do?" is open.
Two rules of thumb for the core questions, both covered in more depth in the prompt-craft guide. First: anchor every question to a specific past event, not a general opinion. The participant's memory of a real Tuesday is data. Their opinion about dashboards in the abstract is not. Second: never stack two questions into one. "What did you try, and why didn't it work?" reads as a single question and gets answered as half of one. Break it into two lines.
Three to six core questions is enough. A guide with twelve core questions is a guide that will be abandoned in the room. The interview's time budget is finite: a 45-minute call is roughly six minutes per core question after warmup and close, which is the right pace if you actually want the participant to think before answering. The longer essay on the asymmetry between what voice catches that text loses explains why those six minutes per question are worth more than the survey-style coverage they replace.
05 · Plan your probes in advance
Under each core question, write the probes. Three or four short follow-ups the interviewer can reach for when the participant's answer is too short, too abstract, or too polished. "Can you walk me through that?" "What were you trying to do at that moment?" "How often does that happen?" "What did you try first?" "Compared to what?"
Planned probes are the single largest delta between a guide that works and one that does not. The unplanned interviewer asks every probe in the same shape ("can you say more about that?") and gets the same shape of answer back. The planned interviewer reaches for the probe that fits the failure mode of the previous answer: vague gets a "compared to what", polished gets a "what was the part that wasn't perfect", short gets a "walk me through the last time it happened".
Probes are also what async voice interviews are built around. In a moderated call, the interviewer probes live. In an async voice interview, the probe has to be triggered by the model that just heard the answer, in roughly the same shape and with roughly the same restraint a senior researcher would use. Probing depth is a researcher decision per question, not a global toggle: shallow (at most one clarifying follow-up, best for low-friction in-product prompts), medium (a short chain when the answer stays vague, the default for most discovery work), and expert (the AI keeps probing until it has the context a senior researcher would dig out in a moderated interview). The mechanics live in how AI follow-up questions work in user research. The point for the guide is that planned probes belong on the page whether the call is live or async. The participant retains the right to skip on every probe.
"The probe list under each question saved the interview. The first time the participant said 'it's fine', I had a probe ready that turned 'it's fine' into a story about a Wednesday afternoon. I would have moved on without it."
06 · Add the curveball and the close
Two short sections wrap the core. A single curveball question near the end, designed to surface anything the rest of the guide failed to ask. Two reliable variants: "If you could change one thing about how this works today, what would it be?" and "What did I not ask you that I should have?" Both produce answers the structured questions would never have reached, because the participant has spent the last 40 minutes thinking about the topic and has now built up a thought they have been waiting to share.
The close is the last 90 seconds. Thank the participant, name the incentive payout if there is one, ask for permission to follow up if a question comes up in synthesis, and tell them what happens next with the research. The close matters because participants who feel heard during the close are the participants who answer the follow-up email three weeks later when you need a second round. Recruitment compounds across studies; the close is the recruitment step for the next one. The wider take is in how to recruit user research participants.
07 · Pilot the guide on one real participant
The first interview you run with a new guide is the pilot, regardless of whether you call it that. The participant is real, the recording is real, and roughly half of what the guide gets wrong becomes obvious in the first ten minutes: the warmup is too long, the core is in the wrong order, the third question is the same as the fifth, the curveball is producing answers that belong in the core.
Run the pilot, write notes against the guide in the margin during the call, and revise the guide that night. The revised guide is the one the rest of the round uses. Skipping the pilot is the single most common mistake in user research operations, and the cost is felt at synthesis time, not at the interview, which is why teams under-correct for it.
The async voice version of the pilot is structurally easier: send the prompt set to one or two participants the same week the guide is finished, listen to the recordings the same day, and revise before the wider round goes out. The same shape of mistake (a question that produces uniformly vague answers, a probe that the model never reaches for) becomes visible in 24 hours instead of a week of scheduled live calls.
From moderator script to async prompt set
The guide above is written for a live interview. The same artifact carries over to async voice work with two substitutions and one addition.
The substitutions: questions become prompts the participant records against on their own time, and the planned probes become adaptive follow-ups that fire when an answer is too short or too vague. The depth of those follow-ups is the researcher's choice per prompt, the same way a moderator would choose to dig harder on some questions than others. The shape of the prompt-set is covered in how to run voice user interviews, which walks through the operational details of running the async version.
The addition: a discussion guide for async voice work doubles as a standing instrument. A guide for a discovery round normally lives for a week and gets archived. The same guide, expressed as an asynchronous prompt set with a stable link, can sit inside the product (a settings-menu feedback affordance, a cancellation flow, a post-onboarding moment) for as long as the team wants signal on the underlying research question. The guide stops being a one-week campaign and starts being a continuous-feedback instrument. The framing is in how to build a customer feedback loop.
The third move is internal. A guide written for external participants is often the right artifact to share with engineering, design, support, and legal stakeholders before a launch. The same link, sent inside the company, returns a synthesized cross-functional view of objections and edge cases before the feature touches a customer. The same prompts, the same probes, a different audience. Used this way the guide is also a pre-launch sanity-check tool, not only a research instrument.
A note on synthesis: whatever shape the guide ships in, the transcripts that come back need a synthesis pass that clusters answers by theme, sentiment, and the research question at the top of the guide. The general method is in how to analyze user interview transcripts. The point for the guide is that the research question at the top is also the synthesis prompt at the bottom: themes are coded against that question, not against an open-ended "what did we hear".
When a discussion guide gets in your way
Three cases worth naming.
The participant is the expert and the team is not. When you are interviewing a domain expert (a clinician, a security engineer, a tax accountant) about their own world, the guide should be lighter, not heavier. Two or three open questions and a long list of probes. A heavy guide imposes the team's framing on a participant who knows more about the topic than the interviewer. The point of the conversation is to learn the participant's mental model, not to test the team's.
The interview is structurally short. If the conversation is 10 to 15 minutes (a hallway intercept, a post-onboarding survey with one open-ended question, a short async voice prompt set), the guide collapses to a single research question and one or two prompts. Trying to run a 7-step guide in 12 minutes produces an interview that feels rushed to the participant and shallow to the researcher.
The decision is already made. A guide written to confirm a decision that has already been taken is a guide that produces confirmation evidence and nothing else. The cleanest fix is upstream: revisit how to write a user research plan and check that the research question at the top of the guide is one whose answer could actually change the decision.
FAQ
What is the difference between a discussion guide and an interview script?
A discussion guide is a one-page document that lists the research question, the topical arc, the warmup, three to six core questions, and the probes for each. It is meant to be referenced, not read aloud. An interview script is a verbatim list of questions read in order, which produces a survey delivered by voice rather than a conversation. The guide gives the interviewer permission to follow the participant's narrative; the script gives the interviewer no such permission. Most working researchers write a guide, not a script.
How long should a discussion guide be?
One or two pages. Three to six open-ended core questions, each with three or four planned probes underneath, a short warmup, a curveball, and a close. A guide that runs longer than two pages is usually trying to do the job of a research plan or a survey. If the interview is 45 to 60 minutes, six minutes per core question is the right pace; that math caps the core at about six questions, including probes.
What is the difference between a discussion guide and a research plan?
A research plan is strategic: what the team is deciding, who to talk to, what counts as evidence, what would change the decision. A discussion guide is tactical: the next 45 minutes with one specific participant, anchored to a single research question taken from the plan. A plan can spawn several guides for different participant segments. A guide cannot answer plan-level questions; it can only produce the transcripts that feed back into the plan. The plan side is covered in how to write a user research plan.
How do you write probes for a discussion guide?
Under each core question, write three or four short follow-ups the interviewer can reach for when the participant's answer fails a specific way. Vague answers need a "compared to what" probe. Polished answers need a "what was the part that wasn't perfect" probe. Short answers need a "walk me through the last time" probe. The probes are not all asked; the interviewer picks the one that fits the failure mode of the previous answer. In async voice interviews, the same probes get triggered by the model in real time, and the researcher sets the probing depth (shallow, medium, expert) per question. The mechanics are in how AI follow-up questions work in user research.
Should I pilot a discussion guide?
Yes, every time. Run the first interview as a pilot whether or not you call it that, take notes against the guide in the margin during the call, and revise the guide that evening. Half of what a new guide gets wrong becomes obvious in the first ten minutes: the warmup runs too long, the third question is the same as the fifth, the curveball produces answers the core should have caught. Skipping the pilot is the single most common operational mistake in user research, and the cost shows up at synthesis, not at the interview itself.
The discussion guide is one instrument inside a wider research practice. The pillar piece (the complete guide to voice user research) covers how guides, plans, prompts, and synthesis sit together inside a continuous-feedback program, and where each one belongs in the operational loop.