A useful user interview script is a flexible guide, not a questionnaire to read word for word. Start with the decision you need to make, choose a small set of things you need to learn, and ask about one recent event in enough detail to understand what actually happened.
The template below is designed for a 30-minute problem-discovery conversation. The timing is a worked example, not a research benchmark. Adapt the wording to your audience and topic, then pilot the guide before using it with your target participants.
Copy this user interview script template
Replace the text in square brackets. Keep the main prompts stable within one round of interviews, but use the probes only when they fit what the participant has said.
# Research setup — do not read aloud Decision this study should inform: [The concrete decision you expect to make or defer] Research question: [What you need to understand before making that decision] Target participant: [Who has recent, relevant experience] Evidence this interview cannot provide: [For example: market prevalence, observed usability, or proof of future demand] ## 1. Welcome and consent — about 2 minutes Thanks for taking the time. I am trying to understand how people currently handle [activity or problem]. This is not a sales call and there are no right answers. I am interested in what actually happened, including anything that was frustrating or did not work. You can skip any question or stop at any point. [If recording:] Is it all right if I record this conversation so I can review it accurately later? [Explain who can access it and how it will be used.] ## 2. Context — about 4 minutes 1. Tell me about your role and how [activity] fits into your work. Optional probes: - Who else is involved? - How often does this situation come up? - What tools or processes are already part of it? ## 3. One specific recent event — about 12 minutes 2. Tell me about the most recent time you [did the activity / encountered the problem]. Optional probes: - When was that? - What triggered it? - What happened first? - What did you do next? - What information or tools did you use? - Where, if anywhere, did you get stuck? - How did you handle that? - What was the outcome? 3. What was the hardest part of that specific experience? Optional probes: - What made that difficult? - What did it cost in time, money, effort, or risk? - What was easier than you expected? ## 4. Workarounds and alternatives — about 8 minutes 4. What, if anything, did you try to make the situation easier? Optional probes: - What had you tried before? - How did you choose that approach? - Did you spend money or significant time on it? - What worked well? 5. What did not work well about the approaches you tried? Optional probes: - Can you give me a recent example? - What did you do instead? - What would happen if you changed nothing? ## 5. Close — about 4 minutes 6. Looking back at that experience, which part would you most want to make easier, and why? 7. What have I not asked that would help me understand this better? Thank the participant, explain what happens to their responses, and confirm any follow-up you have agreed.
Seven main prompts are enough here because the probes carry most of the conversation. Nielsen Norman Group describes five to eight open-ended questions as typical for an interview guide, followed by open or closed follow-ups. That is a useful editing constraint, not a rule that every topic or 30-minute interview must fit the same count.
Start from the decision, not a list of questions
Before writing the spoken script, write the decision at the top of the document. Jane Davis frames research around the decisions that findings need to inform and recommends identifying roughly three to five things you want to leave knowing.
Suppose the decision is:
Should we build automated failed-payment recovery for small SaaS teams this quarter?
Your research questions might be:
- How do small SaaS teams notice a failed payment?
- What happens between the alert and a resolved payment?
- Which steps create enough cost or risk to justify changing the workflow?
- What have teams already tried?
Those are useful planning questions, but they are poor interview questions. Asking “Which steps create enough cost to justify changing the workflow?” makes the participant summarise your framework. A spoken prompt such as “Tell me about the last failed payment you handled” gives them a concrete event to reconstruct.
Teresa Torres makes this distinction explicit: research questions describe what the team wants to learn; interview questions are what the participant can answer from experience. The move from one to the other is the heart of writing a good guide.
Use the guide as a checklist, not a questionnaire
Consistency matters, but consistency does not mean identical conversations. Keep the core prompts and their order recognisable across a batch. Follow a useful detail when it appears, skip a probe the participant has already answered, and allow silence before asking the next question.
Erika Hall recommends treating the question list as a checklist rather than reading it mechanically. That flexibility is what separates an interview guide from a survey: the guide defines the territory, while the participant’s story determines the route through it.
The funnel technique gives each topic a reliable shape:
- Begin broadly: “Tell me about the last time…”
- Let the participant describe the event in their own order.
- Probe gaps with neutral questions such as “What happened next?”
- Use closed questions only to confirm a detail you genuinely need.
- Move to the next main prompt and open the funnel again.
This approach preserves unexpected information. A flat list of narrow questions can only retrieve what you thought to ask.
Ground the conversation in one recent event
“How do you normally handle failed payments?” invites a tidy summary. “Tell me about the most recent failed payment you handled” points to a real account, alert, tool, sequence, and outcome.
Specific past behaviour is not automatically perfect evidence. Memory can be incomplete, and an interview still records what a participant reports. But a recent event usually gives you more context to examine than a general opinion or a prediction about what someone might do. See the separate guide to observed versus reported behaviour for the limits of interview evidence.
When the participant drifts into generalities, do not correct them. Wait for a pause and return gently to the event:
- “Can we go back to that last occasion?”
- “What happened immediately before that?”
- “What did you do next?”
- “Can you show me where that happened?” — only if the method and consent allow observation or screen sharing.
This is also the practical core of The Mom Test for founders: ask about lived specifics instead of collecting compliments or promises.
Rewrite leading and speculative questions
Run every main prompt through one test: could the participant answer honestly while still telling you what you hope to hear? If so, widen or ground it.
| Avoid | Ask instead |
|---|---|
| “Do you find the export slow?” | “Walk me through the last time you exported a report.” |
| “Would you pay for automatic recovery?” | “What have you spent to handle failed payments so far?” |
| “Did you switch because the price was too high?” | “What led to the switch?” |
| “What features would you want?” | “What does your current approach not handle well?” |
| “How do you normally manage onboarding?” | “Tell me about the most recent person you onboarded.” |
| “What did you decide and why?” | “What did you decide?” Then: “What shaped that decision?” |
The last example avoids a compound question. Ask one thing at a time so the participant does not have to remember half the prompt while answering the other half. The guide to avoiding leading questions includes more rewrites and neutral probes.
Keep screeners and known facts out of the session
Recruitment questions belong in the screener when possible. If you already know the participant’s role, team size, plan, or recent activity, do not spend live minutes collecting it again. Use the opening to build context that is relevant to the story.
This separation also reduces accidental exclusion. Define who you need before recruitment, collect only the information necessary to assess fit, and do not improvise eligibility decisions during the interview. The participant recruitment guide covers screeners, sampling, incentives, and privacy in more detail.
Pilot the script before the first real session
Read the guide aloud and answer it yourself. Then run a realistic pilot with someone who resembles the target participant. A pilot can reveal that a question is ambiguous, the order is awkward, a probe assumes knowledge the participant does not have, or the guide simply does not fit the available time.
Use this checklist:
- Does the opening explain the purpose without revealing the answer you want?
- Is consent clear, including recording, access, and follow-up?
- Can every main prompt be answered from experience?
- Does each question ask one thing?
- Are hypothetical and solution-focused questions removed or clearly reserved for evaluative research?
- Are the most important story questions early enough that you will not rush them?
- Does the close explain what happens next?
- Does the session fit the promised length when spoken at a natural pace?
Time the pilot. Do not assume a word count predicts interview length: follow-up depth and participant verbosity matter more. For choosing a session length, use the guide to 15-, 30-, and 60-minute user interviews.
What to change during a batch of interviews
Fix defects, not findings. If participants repeatedly misunderstand a prompt or the guide consistently overruns, revise it and record the date and version. If interview three produces an exciting theme, park the idea rather than rewriting the rest of the guide to confirm it.
Davis recommends resisting the urge to chase emerging themes and deliberately looking for evidence that would weaken them. Keeping the core guide stable makes differences between interviews easier to interpret. If you make a material change, treat the earlier and later versions as distinct enough to note during synthesis.
For a practical audit, ask:
- Did I add a question because the guide was unclear, or because I liked an answer?
- Would this new wording make disagreement easier or harder?
- What would I expect to hear if the apparent pattern were wrong?
- Have I preserved the original transcript, guide version, and participant context?
That discipline helps limit the confirmation-bias trap in user research.
How Maren uses the same structure
In Maren, you set a research objective, choose an interview style, and review or edit the generated discussion guide before collecting responses. The interviewer then asks one question at a time and probes short or vague answers while staying within the guide. Completed conversations receive per-interview analysis, and a separate synthesis can compare themes and tensions across interviews.
That workflow does not choose the research decision for you, recruit the right sample automatically, or turn reported experience into observed behaviour. You still own the objective, participant selection, consent, and interpretation. Use a skilled human researcher when the study depends on visual observation, sensitive human judgement, live co-creation, or a method that cannot be reduced to an asynchronous conversation.
For a focused interview study, Maren can remove the scheduling and moderating work while keeping the objective and guide visible. See how Maren runs AI-moderated interviews.
Frequently asked questions
How long should a user interview script be?
Use the fewest main prompts needed to address the research objective. Five to eight open-ended questions is a useful typical range from Nielsen Norman Group, but it is not a universal duration formula. A guide with five questions and deep probes can take longer than a guide with eight narrow questions.
Should I use the same script for every participant?
Keep the core prompts stable within a research round so you can compare coverage. Adapt follow-up probes to what each participant says, fix genuine defects, and version any material changes.
Can AI write the interview script for me?
AI can generate a useful first draft from a clear objective and a suitable methodology. You should still check every question for assumptions, leading language, relevance, privacy, and fit with the decision. A polished script cannot repair a vague objective or the wrong participant sample.
Is an interview script the same as a discussion guide?
People often use the terms interchangeably. “Discussion guide” is usually the better mental model because it encourages flexible listening rather than reading a fixed questionnaire. Your consent language may be scripted exactly; the research conversation should not be.
Write the decision first
Do not begin by collecting clever questions. Write the decision you cannot yet make, the three to five things you need to understand, and the kind of experience a participant must have to help.
Then turn those learning goals into a small number of prompts about real events. Add neutral probes, cut anything you already know, and pilot the guide aloud. The result will feel less like a polished questionnaire and more like a conversation — which is exactly the point.