How to Write a Customer Interview Research Plan

The short answer

A useful customer interview research plan does not need to be long. It should tell the team which decision the study will inform, what is already known, which uncertainties remain, who should participate, why a particular method fits, how research data will be handled, and when analysis will happen.

The common mistake is to begin with a large list of interview questions. That list can look productive while leaving the study directionless. Begin with the decision, turn the important unknowns into research questions, and only then write the discussion guide.

We will use one example throughout this guide. A SaaS team must decide whether to redesign its new-user setup next quarter. Some small teams register but never finish setup. The product team does not yet know where people stop, why they stop, or what they do instead.

Start with the decision, not the question list

Open the plan with one concrete statement: who will use the research, when, and to make which decision.

“Understand the new-user experience” is too broad. This version gives the work a boundary:

Before the next quarterly roadmap review, the product lead will decide whether to redesign the full setup flow or address one or two high-friction steps. This study will examine what happens when small-team users do not finish setup and identify points that deserve further validation.

It does not promise that six interviews will prove a solution. It connects the study to a real choice while leaving room for an unexpected answer.

If the decision is still vague, spend a short session with the sponsor. Ask what options could change when the study ends, when the result is needed, and what evidence the team would otherwise use. That conversation often prevents weeks of unfocused research.

Separate existing evidence from the real unknowns

Interviews are not the default answer to every question. Review what the team already has: funnel data, support tickets, sales notes, usability studies, cancellation reasons, and field notes from customer-facing teams. These sources have limitations, but they stop you from asking users to rediscover facts already in the building.

In our example, analytics may show that 38% of new accounts fail to reach a particular step. That number cannot usually explain what users were trying to accomplish, which information they lacked, who else needed to take part, or what workaround followed. Those are better interview topics.

Write down three columns: what the team knows or suspects, what remains uncertain, and which evidence could address it. Include boundaries. Interviews can help explain experience and context; by themselves, they do not establish causation or estimate how common a behavior is across a market.

Turn the unknowns into research questions

Research questions are written for the team. They are not lines the moderator reads aloud. Neutral questions for this study might be:

• What were small-team users trying to accomplish during their first setup?
• At which points did they need more information, help from another person, or a workaround?
• How did the process and success criteria differ between people who finished and people who stopped?
• After abandoning setup, how did they complete the original task?

“Did users leave because the invitation step was too complicated?” embeds the team’s theory. A cleaner version asks, “What judgments did users make during the invitation step, and what affected whether they continued?” The evidence can then support or challenge the original idea.

Merge duplicates and rank the remainder. Three to five core questions are usually easier to carry through one round than a page of equally urgent questions. For the next step—turning research questions into language that works in a conversation—use the customer interview questions guide.

Define who should take part, and who should not

“Talk to a few users” is not a recruitment brief. Describe the relevant experience, role or context, how recently it happened, and which differences the sample needs to cover.

For this study, the team could recruit small-team users who attempted setup during the past 60 days. Include people who completed it and people who stopped, plus both account owners making the decision and members asked to do the work. Enterprise administrators can be excluded for now because procurement, permissions, and implementation may create a different research problem.

There is no magic sample size. The GOV.UK Service Manual describes 4 to 8 participants as a common range for a qualitative round and recommends continuing in rounds as the work develops. That is a practical starting point, not statistical representation and not a guarantee of saturation. The right scope depends on variation in the audience, complexity, risk, and how the result will be used.

A workable plan might begin with six sessions, review after every two, and add another round if a critical role is missing or new evidence continues to change the team’s interpretation.

Match the method to the question

Interviews are well suited to understanding how someone describes a recent experience, the constraints around it, and the judgments they made. If the question is whether a person can complete a new interface, let them use it and observe what happens. If the team needs an estimate of prevalence, it will probably need analytics or a well-designed survey.

Methods can be combined. Ask a participant to reconstruct the last setup attempt, then—with permission—share their screen and show any pages or documents that still exist. Observed detail gives the follow-up questions something concrete to work with.

The plan only needs to explain the choice clearly:

Run 45-minute semi-structured interviews about the participant’s most recent setup attempt. When the workspace remains available and the participant agrees, ask for a short walkthrough. Use the sessions to understand experience and decision-making, not to estimate incidence.

Plan consent and data handling before recording

Audio, video, shared screens, and transcripts may contain personal or commercially sensitive information. Do not wait until five minutes before the first call to decide what happens to it.

Record in the plan what participants will be told, which forms of recording require consent, who can access raw material, whether a transcription or research processor will receive it, how reports will be de-identified, how long material will remain, and how withdrawal and deletion requests will be handled. Collect what the research requires, not everything that might one day be interesting.

Legal and policy requirements vary by jurisdiction, sector, contract, and data type. This guide is not legal advice. Research involving sensitive personal information, children, health information, or regulated data should be reviewed by the organization’s privacy or legal team.

ScribeFlash projects let a team select media and project-data retention periods. That setting helps execute the plan; it does not replace the team’s consent, access-control, or compliance decisions.

Schedule analysis before the first session

Some plans fill the calendar through the last interview and treat the report as if it appears automatically. The slower work often comes next: checking important passages, marking evidence, comparing participants, investigating contradictions, writing findings, and getting a review.

GOV.UK advises teams to allow explicit analysis time and offers at least one hour of analysis for every two hours of research as a useful rule of thumb. Complex work may need more. A practical schedule adds a short debrief after every two sessions and protects a continuous block for synthesis at the end.

Name the owners and outputs. Who reviews transcripts? Who can turn a quotation into evidence? Who checks a finding? Which decision-maker receives the report, and on what date? “The researcher will sort it out later” is where timelines and expectations usually break.

Do not discard contradictory material. If three of five people report the same difficulty, the other two may reveal a role difference, a different context, or a weakness in the original grouping. The customer interview analysis guide explains the later path from transcript to traceable finding.

A research plan template you can reuse

Copy this short structure and remove any prompt that does not apply.

Context and decision
By (date), we will decide (specific decision). The evidence or change prompting this study is (data, feedback, or business event).

Existing evidence and unknowns
We already know (sources and scope). We still need to understand (uncertainties that affect the decision). This round will not attempt to answer (causation, prevalence, or out-of-scope issues).

Research questions
List 3 to 5 prioritized learning questions. Do not assume that a preferred product idea works.

Participants
The relevant experience occurred within (time range). Cover (roles, states, or key differences) and exclude (conditions and reason). Begin with (sessions), then review at (checkpoint).

Method and procedure
Use (interview, contextual observation, usability test, or another method) for approximately (duration). State what the method can and cannot answer.

Consent and data handling
Document recording types, processors, access, de-identification, retention, withdrawal, and deletion. Route higher-risk data through privacy or legal review.

Analysis and delivery
Debrief every (number) sessions. (Owner) organizes evidence, synthesis ends by (date), and the team delivers (report, playback, or decision meeting) to (decision-maker).

Risks and limitations
Note recruitment bias, missing roles, schedule constraints, reliance on self-report, and the intended mitigation.

Set up the research project in ScribeFlash

Once the plan is agreed, transfer the fields that will guide later analysis into ScribeFlash. No local installation is required; sign in to the web product and follow these steps.

1. Open Projects and select New project.
2. Enter a recognizable name, such as “Q4 2026 small-team onboarding study,” rather than “User interviews.”
3. Add a client or company name when it helps. This field is optional for internal work.
4. In the objective, record the decision and scope. Do not paste the entire discussion guide into this field.
5. Enter the expected number of interviews. It is a planning value, not a claim of statistical representation.
6. Add the research questions one by one. Merge duplicates and keep the 3 to 5 core questions. A project requires at least one research question.
7. Select the original interview language and output language. For multilingual work, also agree whether the team will quote source text or translations and who checks important wording.
8. Choose media and project-data retention rules that match the participant notice and organizational policy. Ask a privacy or legal owner when uncertain.
9. If names, acronyms, product terms, or specialist vocabulary will recur, select an existing glossary to reduce repeated transcript corrections.
10. Create the project. After each session, upload the audio or video, wait for asynchronous transcription, and review passages that affect the findings. The create a research project guide covers the product workflow in more detail.

Project fields do not make research judgments for you. They give the objective, questions, transcripts, evidence, and findings a stable place to stay connected.

Sources

• GOV.UK Service Manual: Plan a round of user research
• GOV.UK Service Manual: Plan user research for your service
• GOV.UK Service Manual: Capturing research questions
• Department for Education: Writing a user research plan
• Nielsen Norman Group: Project Management for User Research: The Plan
• GOV.UK Service Manual: Getting informed consent for user research
• GOV.UK Service Manual: Managing user research data and participant privacy