How to Write a User Interview Guide That Produces Better Insights

A good interview guide is not a script

The quality of your interview guide shapes the quality of your insights. If the guide is vague, biased, or overloaded with questions, interviews turn into scattered conversations and analysis gets messy fast.

A strong guide does three things well:

keeps the study focused
gives every interviewer a consistent structure
leaves enough room to follow unexpected but useful threads

That matters whether you are a UX researcher, product manager, designer, or founder running customer discovery yourself.

One of the most common mistakes is treating the guide like a questionnaire to get through. In practice, a good interview guide is closer to a discussion map. It tells you what you need to learn, what order to explore topics in, and where to probe deeper. It should support a natural conversation, not force you to read every question word-for-word.

If you are still deciding whether interviews are the right method for the decision in front of you, start with When to Use Surveys vs Interviews for Product Decisions.

Start with the objective, not the questions

Before writing any interview questions, define the research objective in one or two sentences. This is the job the interview needs to do.

For example:

Understand how new team leads currently onboard to project management tools
Learn why trial users drop off in the first week
Explore how small business owners track invoices today and where the process breaks down

This sounds basic, but it prevents one of the most common failures in interview design: mixing multiple studies into one conversation.

A guide that tries to learn about onboarding, pricing, feature desirability, brand perception, and support experience all at once usually produces shallow answers across all of them. Stakeholders often want to “add just one more section,” especially in startups. Resist that urge unless the topics genuinely support the same decision.

Once the objective is clear, separate three layers that teams often blur together:

Layer	What it is	Example
Research objective	The decision or learning goal behind the study	Understand why activation rates are low
Research question	The thing you need to learn from participants	What blocks users from completing setup?
Interview question	The prompt you ask in the conversation	Can you walk me through the last time you tried to set up your account?

This distinction matters because good research questions do not always translate into good interview questions.

Participants cannot answer abstract prompts like “What are your onboarding barriers?” very well. They can, however, describe what happened, what they expected, where they got stuck, and what they did next.

A useful test: if your interview question sounds like something that belongs in a research plan or slide deck, it probably needs to be rewritten into plain conversational language.

Build the guide around topics, not a long list of questions

Once you know what you need to learn, organize the guide into sections. Most product and UX interviews work well with a simple arc:

Introduction and context
Warm-up questions
Core experience questions
Probing on behaviors, workarounds, and decisions
Wrap-up and final reflections

This structure helps interviews feel natural while still producing comparable data across sessions.

A practical guide usually includes 4 to 6 topic areas, not 25 standalone questions. Under each topic, write:

a short goal for that section
1 to 3 core prompts
likely follow-up probes
any notes for the interviewer, such as what to listen for

That gives interviewers enough support without turning the conversation into a rigid script.

Here is a simple structure you can reuse:

Section	Purpose	Example prompts
Intro	Set expectations and build comfort	Thanks for joining. I’m here to learn about how you currently handle this process. There are no right or wrong answers.
Background	Understand role, context, and relevance	Tell me about your role. How often do you deal with this workflow?
Recent experience	Ground the interview in real behavior	Walk me through the last time you did this. What triggered it?
Friction and workarounds	Find pain points and unmet needs	Where did it get difficult? What did you do when that happened?
Meaning and priorities	Understand impact	Why did that matter? How did it affect your work or outcome?
Close	Capture anything missed	Is there anything I should have asked about that I didn’t?

The key is to anchor the interview in specific past behavior. People are much better at recalling what they did than predicting what they might do in the future.

Write questions that uncover behavior, not opinions alone

Many weak interview guides rely too heavily on general opinions:

Do you like this process?
Would you use this feature?
Is this important to you?

These questions are easy to ask and hard to use. They produce broad attitudes, not evidence you can design around.

A better guide prioritizes behavioral questions:

Tell me about the last time this came up
What were you trying to get done?
What happened first?
Where did you hesitate or get stuck?
What did you do instead?
How did you decide between those options?

These prompts do two useful things. First, they generate concrete detail. Second, they make it easier to spot the gap between what people say they value and what they actually do.

A good rule: if a participant can answer your question without referring to a real situation, the question may be too abstract.

That does not mean opinions are useless. They are often valuable after you understand behavior. For example, once a participant has walked you through a recent workflow, you can ask:

What part of that felt most frustrating?
Which step mattered most to you?
If you could change one thing about that process, what would it be?

In other words, use opinions to interpret behavior, not replace it.

Remove leading language aggressively

Small wording choices can push participants toward the answer you expect. That is especially risky when interviewing about your own product, concept, or prototype.

Leading questions often contain hidden assumptions:

How helpful was the new dashboard?
What do you like about this feature?
Would this save you time?
Was checkout confusing?

Each of these nudges the participant. It assumes the dashboard was helpful, the feature had benefits, the concept saves time, or checkout was confusing.

Rewrite them to stay neutral:

Leading question	Better alternative
How helpful was the new dashboard?	What was your experience using the dashboard?
What do you like about this feature?	What stood out to you about this feature?
Would this save you time?	How, if at all, would this fit into the way you work today?
Was checkout confusing?	How did the checkout process feel to you?

Neutral questions do not mean weak questions. You can still probe directly. The difference is that you let the participant supply the judgment.

Also watch for:

Double-barreled questions: “Was it easy to use and useful?” If they say yes, you still do not know which part they mean.
Assumptive questions: “When do you use our reporting dashboard?” This assumes they use it at all.
Socially loaded wording: “Why didn’t you complete setup?” can sound accusatory. “What happened after you started setup?” is often better.

This matters even more when founders or PMs interview their own customers. If participants know you built the product, many will try to be polite. Neutral wording helps reduce that pressure.

Plan your probes before the interview

The best insights usually come from follow-up questions, not the first answer. But many interviewers either forget to probe or improvise inconsistently across sessions.

A better approach is to add planned probes under each core topic. For example:

Can you give me an example?
What made that difficult?
What were you expecting at that point?
How did you decide what to do next?
What happened after that?
Has that happened before?
How often does that come up?
Who else was involved in that decision?

These probes help you move from surface-level responses to causality, tradeoffs, and context. They are also what make the guide reusable across interviewers with different experience levels.

A practical habit is to probe for five kinds of detail:

Sequence — What happened first, next, and after that?
Context — Where were they, what were they doing, and what triggered the task?
Decision-making — Why did they choose that path?
Constraints — What got in the way?
Impact — What was the consequence for them or their team?

If you want to improve the live conversation skills that sit on top of the guide, How to conduct better customer interviews is a useful companion.

Keep the guide short enough to finish well

Most interview guides are too long. Teams write every possible question, then rush the last third of the session or skip the most important probes.

For a 30-minute interview, plan for about 5 to 7 core questions. For a 45- to 60-minute interview, aim for 8 to 12 core questions across your sections. That does not include follow-ups.

A simple way to pressure-test timing is to run a pilot interview with a teammate or friendly customer. If a participant gives detailed answers, your guide should still fit comfortably. If it only works when every answer is short, the guide is too long.

The simplest way to cut a guide is to label each question:

Must ask
Nice to ask
Only if time allows

This forces prioritization before the interview instead of during it. It also helps when multiple stakeholders want to add “just one more question.”

A shorter guide usually produces better evidence because it gives participants room to tell the full story.

Include an intro that builds trust and sets expectations

The opening minute of the interview affects the quality of everything that follows. If participants are unsure what the session is for, worried about being evaluated, or unclear about recording, their answers will be less candid.

Your guide should include a short, repeatable intro that covers:

who you are
why you are doing the research
how long the session will take
whether the session is being recorded
that you are interested in their experience, not testing them
that honest feedback is useful, including negative feedback

For example:

Thanks for taking the time today. I’m part of the product team, and we’re trying to understand how people currently handle this workflow. We’re not testing you, and there are no right or wrong answers. With your permission, I’d like to record the session so I can focus on listening instead of taking detailed notes. Please be as candid as you can — if something is confusing or frustrating, that’s especially helpful for us to hear.

This is a small detail, but it often improves the quality of responses, especially in usability interviews or founder-led research.

Tailor the guide to the type of interview

Not every interview guide should look the same. The structure stays similar, but the prompts should match the kind of decision you are making.

Here are three common cases:

Discovery interviews

Use these when you are trying to understand needs, workflows, pain points, or unmet demand.

Prioritize:

recent behavior
current tools and workarounds
triggers and motivations
consequences of the problem

Example prompt:

Walk me through the last time you had to prepare this report for your team.

Usability interviews

Use these when you want to see whether people can understand and use a product or prototype.

Prioritize:

task-based prompts
observation of behavior
moments of hesitation or confusion
interpretation of labels, flows, and feedback

Example prompt:

Please try to complete this task the way you normally would. What are you thinking as you go?

Post-launch or evaluative interviews

Use these when you want to understand adoption, satisfaction, or why a feature is or is not being used.

Prioritize:

frequency of use
fit with existing workflow
alternatives and fallbacks
reasons for drop-off or repeat use

Example prompt:

Tell me about the last time you used this feature. What were you trying to accomplish?

If you use the same guide structure for every study without adjusting the prompts, you risk collecting the wrong kind of evidence.

Make the guide reusable across studies and teams

A reusable guide is not a generic one. It is a structured template with the right fixed parts and the right flexible parts.

Keep these elements consistent:

Study objective
Participant type
Interview intro and consent language
Core sections
Standard probes
Note-taking fields
Debrief questions for the interviewer

Then customize the study-specific prompts inside each section.

For example, your team might use one shared template for founder interviews, one for product discovery, and one for usability interviews. Each template can preserve the same logic: background, recent behavior, friction, workarounds, impact, close.

This consistency pays off later during synthesis. When interviews follow a comparable structure, it is easier to review notes, compare patterns, and turn observations into decisions.

A useful addition is a short post-interview debrief section for the interviewer, such as:

What surprised you?
What themes came up strongly?
What needs follow-up in future sessions?
How confident are you in this participant’s relevance to the study?

Those notes are often valuable when you synthesize across interviews later. For that next step, see How to Analyze Customer Interview Data: Coding, Themes, and Turning Notes Into Decisions.

A practical interview guide template

If you want a starting point, this lightweight template works well for many product and customer research studies:

1. Study details

Research objective
Target participant
Key decisions this study should inform
Session length
Interviewer
Date

2. Intro script

Welcome and thanks
Purpose of the conversation
Recording permission
Confidentiality or note on how data will be used
Reminder that there are no right or wrong answers

3. Background

Tell me about your role.
How does this area of work show up in your week?
What tools or systems do you use today?

4. Recent experience

Walk me through the last time you did this.
What triggered it?
What were you trying to accomplish?

5. Friction and workarounds

Where did things get difficult?
What did you do when that happened?
Did you involve anyone else or use another tool?

6. Impact and priorities

Why did that matter?
What was the consequence of the issue?
If you could improve one part of the process, what would it be?

7. Wrap-up

Is there anything I should have asked about that I didn’t?
Is there anything else you think is important for us to understand?

8. Interviewer debrief

Top takeaways
Notable quotes or moments
Open questions
Confidence in fit and data quality

You do not need to use this exactly as written. The point is to create a guide that is easy to run, easy to compare across sessions, and clearly tied to a decision.

A simple checklist before you run the study

Before you finalize the guide, review it against this checklist:

Is the research objective clear and narrow?
Are research questions separate from interview questions?
Does the guide focus on past behavior over future speculation?
Are the questions neutral and free from assumptions?
Do you have planned probes for each core topic?
Can the guide realistically fit in the session length?
Does the intro set expectations and build trust?
Is there a clear structure that other interviewers could follow?
Have you piloted the guide at least once?

If the answer to any of these is no, fix the guide before recruiting starts. It is much easier to improve the instrument upfront than to salvage weak data later.

Better guides create better evidence

A user interview guide should do more than keep the conversation on track. It should help you collect evidence that is specific, comparable, and trustworthy enough to influence product decisions.

The practical standard is simple:

clear objective
structured flow
neutral wording
behavioral questions
planned probes
realistic timing

If your guide does those things, your interviews will be easier to run, easier to synthesize, and far more useful when it is time to make product decisions.