On this page
A good interview guide breaks one business question into three to five research questions, turns each research question into concrete questions participants can answer from their own experience, and arranges them into five timed sections: opening, warm-up, core topics, probes, and closing. This article walks you through how to write a user interview guide for a session of about 45 minutes, decide which questions are must-ask and which you can skip, and smooth out the questions with a pilot before your real interviews.
Step 1: From business question to research questions to interview questions
Many guides go wrong because they take the business question straight to participants. A business question is a decision the team has to make, such as "Should we launch the new membership plan?" Participants can't answer that, and they shouldn't be answering it for you. There are two layers in between.
- Write down the business question: what decision the team needs to make once the study is done. Write only one. If you can't write it, you don't need interviews yet.
- Break it into research questions: what the team still needs to understand to make that decision. Usually three to five, for example "How do users meet this need today?", "What has the current solution cost them?", "Under what circumstances would they switch?" Research questions are written for the team, not read to participants.
- Turn them into interview questions: each research question maps to two to four interview questions. Interview questions should ask about specific past experiences, not opinions or predictions.
| Level | Example | Written for |
|---|---|---|
| Business question | Should we switch the monthly membership to pay-per-use? | Decision-makers |
| Research question | How often and in what situations do users use their membership? | Research team |
| Interview question | When was the last time you used the membership features? What were you doing at the time? | Participant |
A test for interview questions: can the participant answer by recalling something that actually happened? Set aside questions that ask them to speculate, give a rating, or make a decision for you.
Step 2: Arrange the guide in five sections
Opening (about 3 minutes)
Explain the purpose of the study, how long it will take, whether you're recording, and how the notes will be used. Stress that there are no right or wrong answers and that it isn't a test. This part decides whether participants will feel safe telling you the truth later on.
Warm-up (about 5 minutes)
Ask easy background questions related to the topic, such as what they do for work or how they usually spend their day. The goal isn't to collect data but to get the participant used to talking about specifics.
Core topics (about 25–30 minutes)
Group your questions into two to four topic blocks by research question. Open each block with one open-ended question about the most recent real experience, then follow the story from there. Order topics from broad to narrow: first their overall approach, then specific steps, and only at the end their views on your product or concept, so you don't reveal too early what you care about.
Probes (woven into the core topics)
You don't need to script follow-up questions word for word, but under each topic, list what you want to dig into, for example "why they chose that approach", "how much time and money it took", "whether they ever gave up". When the participant touches on one of these points, you'll know to pause and ask a bit more.
Closing (about 5 minutes)
Ask "Is there anything I didn't ask about that you think is important?" It often surfaces something unexpected. Then thank them and explain next steps and how the incentive will be paid.
Step 3: Separate must-ask from optional questions
There's never enough time in an interview. Once the guide is written, mark each question as must-ask or optional. Must-ask questions map directly to research questions and need to be covered in every session, or you won't be able to compare across sessions later. Optional questions are a bonus: skip them when the participant is going deep, and use them to fill gaps when answers are thin.
- Keep must-ask questions to about 8–12. Any more and you won't get through them.
- Every research question needs at least one must-ask question tied to it. Otherwise that research question never actually gets studied.
- Put optional questions at the end of each topic block so they're easy to drop in the moment.
Step 4: Manage the time
Interviews of 45–60 minutes are typical. Past an hour, participants get tired and their answers get shorter. Write an estimated number of minutes next to each topic block and keep an eye on the clock during the session. If a topic clearly runs over, decide on the spot which of the later optional questions you'll drop. Don't cut the closing short.
A rule of thumb: plan only about 80% of the total session time in the guide, and leave the rest for follow-up questions and unexpected topics.
Step 5: Pilot before the real interviews
Don't use the guide as soon as it's written. Run through it once with a colleague or a real participant, and note where things get stuck. A pilot usually exposes three kinds of problems: questions participants don't understand, questions that overlap, and question order that gives away your hypothesis too early.
- Read each question aloud: can you say it in one breath? Does it contain jargon or internal names?
- Does any sentence ask about two things at once?
- Does any question hint at the answer you want to hear?
- Can the must-ask questions be covered in the time available?
- Does the opening clearly explain recording and privacy?
- [Background] Business question: ____; research questions for this study: 1. ____ 2. ____ 3. ____
- [Screening criteria] ____ (e.g., used a given feature at least 3 times in the last 30 days)
- [Opening, 3 min] Thanks for making the time. Today I'd like to hear about your real experience with ____. It'll take about 45 minutes. There are no right or wrong answers, so just tell me what you actually did. We'll record the session for internal notes only, and we won't share your personal information. Shall we get started?
- [Warm-up, 5 min] To start, could you tell me a bit about your work or what a typical day looks like for you?
- [Warm-up] How often does something related to ____ come up for you?
- [Core topic 1, 10 min, must-ask] When was the last time you ____? Can you walk me through what happened, from the beginning?
- [Probe areas] What were you trying to achieve / what did you use / how much time or money it took / which part was the most frustrating
- [Core topic 2, 10 min, must-ask] Before that, had you tried any other way of doing it? What made you switch?
- [Probe areas] What happened at the moment you switched / did you hesitate / who else was involved in the decision
- [Core topic 3, 8 min, must-ask] If you had to sum up in one sentence what bothers you most about how you do it now, what would it be? Can you give me a specific example?
- [Optional] Was there ever a time this problem didn't come up? What was different that time?
- [Optional] Do you ever talk to other people about this? What do you usually say?
- [Closing, 5 min] Is there anything I didn't ask about that you think is important?
- [Closing] That's all for today. Thank you so much. Your incentive will be sent via ____ within ____ days.
Common mistakes
- Asking participants the business question directly, such as "Do you think we should raise prices?": they can only guess. Ask instead about times they've paid for similar products.
- Writing the guide like a survey and reading out 30-plus questions one by one: the interview turns into form-filling. Keep only 8–12 must-ask questions and let follow-up questions do the rest.
- Showing the product or concept right away: participants will talk around your solution. Ask how they do things today first, and show the concept last.
- Writing questions without timings: you find out in the last ten minutes that you haven't finished the core topics. Put minutes on each section and leave a buffer.
- Skipping the pilot: your first real interview becomes the test. Run through the guide once with a colleague or a participant first.
How to do it in heari
In heari, enter your business question and the AI first breaks it into a research plan and research questions, then generates an interview guide with an opening, warm-up, core topics, probes, and closing, marking which questions are must-ask and which are optional. The research lead can review and edit the guide line by line. Once it's approved, the AI runs live interviews and asks follow-up questions based on each answer, with many sessions running at once. You can listen in when needed and exclude invalid responses.
FAQ
How many questions should a user interview guide have?
For a 45–60 minute interview, keep must-ask questions to about 8–12, with a few optional questions in reserve. Too many questions turn the interview into reading a survey aloud and leave no time for follow-up questions, and follow-up is where interviews get their depth.
Do you have to follow the interview guide word for word in every session?
No. Every must-ask question should be covered in every session so you can compare across participants, but you can adjust the wording and order to fit the conversation. Optional questions and follow-ups are entirely up to you in the moment.
What's the difference between research questions and interview questions?
Research questions are what the team wants to figure out, written for the research team, such as "Why do users abandon their current tool?" Interview questions are what you ask participants, and they focus on specific past experiences, such as "When did you last stop using a tool, and what happened?"
How many interviews is enough?
It depends on how different your participants are. Guest, Bunce & Johnson (2006) found that in a fairly homogeneous group, new themes largely stopped appearing after about 12 interviews. If your participants fall into several groups, make sure each group gets enough interviews.
Who should you pilot the interview with?
Ideally, a real participant who meets your screener criteria. If you can't find one, ask a colleague who isn't familiar with the project. What matters is that they don't know your hypothesis, so they can reveal questions that are hard to understand or an order that hints at the answer.
