Interview design
How to Write Customer Interview Questions Without Leading Users
Turn research questions into a practical interview guide with neutral prompts, useful follow-ups, informed consent, and a pilot session before fieldwork.
The short answer
A useful customer interview guide is a route through a conversation, not a survey read aloud. Define the decision the study needs to support, turn it into a small set of research questions, and organize those questions into topics. Give each topic one or two open prompts plus a few neutral probes. During the session, change the order when the conversation calls for it, but keep the research objective in sight.
Questions about a recent, specific event usually produce more useful detail than questions about preference or future intent. “Tell me about the last time you prepared this report” can reveal tools, handoffs, delays, and workarounds. “Would you use an automated report?” mostly asks for a prediction.
Research questions are not interview questions
A research question describes what the team needs to learn, such as “Why do new customers stop during initial setup?” It belongs in the research plan. Asked directly, it is too abstract and may use language that only the product team understands.
Turn it into prompts a participant can answer from experience:
- “Think back to the first time you used the tool. What were you trying to get done?”
- “Where did you begin, and what happened next?”
- “Was there a point when you stopped or looked elsewhere for help?”
- “What did you do then?”
None of these assumes that setup was difficult. After the sessions, the researcher compares concrete accounts and uses them to answer the broader research question.
The GOV.UK guidance on capturing research questions makes the same distinction: research questions describe what a team needs to learn; they are not necessarily the words used with participants.
Build a guide that can breathe
Start with everything the team wants to know, then cut hard. Twenty main questions in a 45-minute session usually produce twenty thin answers. Five to seven topics leave room for an actual story and the follow-ups that make it understandable.
A practical flow moves from the participant’s role and routine into one recent event, then explores friction, current workarounds, and outcomes. Place sensitive topics after some rapport has formed. Keep a few minutes at the end for anything the participant thinks the team failed to ask.
Write the guide in two layers. A broad starter opens each topic: “Walk me through the last time you prepared the monthly report.” Optional probes sit underneath: who was involved, what information was used, and where time was lost.
Those probes are not a checklist. A semi-structured interview works because the interviewer can follow an important detail instead of breaking a useful story to satisfy the next line in a script.
Ask about real events before future intentions
“If we built automatic reporting, would you use it?” is easy to answer and hard to trust. A participant may want to be encouraging, or may honestly misjudge what they will do later. Interviews collect reported experience and attitudes; they are weak predictors of future behavior.
Try questions grounded in the recent past:
- “What tools did you use the last time you delivered this report?”
- “What happened between starting the work and sending it?”
- “Which step required another person’s approval?”
- “What have you tried to make the process faster? Do you still use it?”
The phrase “last time” matters. It pulls the answer toward a date, a sequence, and actual choices. When someone says, “We always review it,” ask who reviewed the most recent one and what they found.
Be honest about the method’s limit. Memory leaves gaps, and reported behavior is not observed behavior. If the study needs to know whether someone can complete a task in an interface, watch them try it and combine the observation with appropriate behavioral data.
Remove leading language, bundled questions, and team jargon
Leading questions are often accidental. Product teams know the interface too well, so their interpretation slips into the wording.
“Did the new summary save you time?” suggests both an improvement and the expected answer. A neutral version is, “How did the two ways of organizing the material affect your work?” If the participant has not used the feature, ask about the current process instead of requesting an opinion about an imagined one.
Bundled questions cause a different problem. “Was uploading and editing straightforward?” asks about two stages at once. A vague “mostly” gives no clue which stage worked. Separate the stages, or let the participant walk through the process and probe the exact point that needs clarification.
Replace internal terms as well. Instead of “How do you manage your insight repository?” ask, “After an interview, where does the useful material go, and who looks at it later?” If the participant uses the term “insight repository,” you can then adopt their language.
On a final editing pass, check each question: Does it imply that something is good or bad? Does it assume the participant did something? Does it ask two things? Would a person outside the company understand the vocabulary?
Follow up without explaining the answer for the participant
Good probes are usually short:
- “Can you give me a recent example?”
- “What happened next?”
- “You called that frustrating. What part was frustrating?”
- “Who else was involved?”
- “Why did you choose that approach?”
When a participant pauses, leave a little room. Two or three quiet seconds can produce the detail they were trying to remember.
Avoid disguising an interpretation as a follow-up. “So you stopped because it was too expensive, right?” supplies a cause and a conclusion. “What made you decide not to continue?” leaves the explanation with the participant.
Probing also has a boundary. For health, income, conflict at work, or other sensitive subjects, participants should know that they can skip a question. If the information is not needed to answer the research question, do not collect it simply because it might be interesting.
Explain consent and data use before recording
Before recording or taking detailed notes, obtain informed consent and explain the purpose of the study, what will be collected, how it will be stored, who can access it, where it may be shared, and how participation can end. Requirements vary by jurisdiction, industry, and organization, so sensitive studies should be reviewed by the appropriate privacy or legal specialist.
Agreement to join an interview should not be treated as automatic agreement to audio recording, video recording, screen capture, and broad internal playback. Explain those uses separately. If a participant declines video, the session may still be possible with notes or another recording mode within the consent they provide.
GOV.UK’s research guidance recommends obtaining informed consent before notes or recordings begin and using the material only for the agreed purposes. It also recommends minimizing identifying data and setting appropriate retention and deletion arrangements.
Pilot the guide before fieldwork
Reading a guide silently will not reveal its pacing. Run it with a colleague, keep time, and ask them to interrupt whenever a phrase is unclear. This catches long questions, company jargon, and abrupt topic changes.
A colleague can test the language and flow, but not whether the guide works with the intended participant. When possible, run one realistic pilot session. Moderate it as a real interview, then review whether the main questions produced specific material, which probes repeated one another, and whether any wording revealed the answer the team hoped to hear.
Leave space between sessions too. A full day of back-to-back interviews looks efficient, but it gives the moderator little time to revise the guide and makes careful listening harder later in the day.
A 45-minute guide you can adapt
This structure works for exploring an existing workflow. It is not a universal script; remove or change sections to fit the research question, participant group, and sensitivity of the subject.
Opening, about 5 minutes
Explain the study and timing. Confirm that the participant understands how their data will be used, and ask separately for recording consent when needed. Begin with their role and working context.
One recent event, about 15 minutes
“Think about the last time you completed this work. What triggered it?” Follow the timeline with “What happened next?”, “What did you use?”, and “Who was involved?”
Friction and current workarounds, about 15 minutes
Probe moments that already appeared in the story: “What made you pause there?”, “How do you usually deal with that?”, and “Have you tried another way?” Avoid reading a list of problems the team already suspects.
Outcome and judgment, about 5 minutes
Ask how the participant knows the work is complete, who checks it, and what happens when it is wrong. The goal is to understand real evaluation criteria, not to ask the participant to design features.
Close, about 5 minutes
Clarify anything still unclear, ask what the team missed, explain what happens to the research material, and thank the participant. Write a short debrief immediately afterward while keeping researcher interpretation separate from the participant’s words.
In ScribeFlash, the project setup guide shows how to record the objective and research questions before uploading interviews. Continue with the customer interview transcription guide and the interview analysis workflow.
Sources
Keep interview questions and source evidence in one research project
Record the study objective and research questions, then review transcripts and connect later evidence to the participant's exact words.