How to prepare for user interviews

The interview is scheduled for Thursday. Wednesday afternoon, the PM opens a fresh doc, types "user interview questions" at the top, drafts nine questions in twenty minutes, and closes the tab. That is not how to prepare for user interviews; it is how to burn a participant. Thursday morning, the participant joins the call. Twenty minutes in, the researcher realises three of the questions are the same question phrased differently, one is leading, one is closed-ended, and the participant has been polite about it for a quarter of an hour. The interview finishes on time, the notes get filed, the study produces a summary nobody argues with, and no qualitative decision changes. The failure was not the interview. It was the twenty minutes on Wednesday.

This is a working guide on how to prepare for user interviews that produce evidence a product team can act on: the artefacts that need to exist before the first call, the failure modes to catch during prep so they do not surface in the room, seven concrete steps a product researcher or PM can run through in a couple of hours, and how the prep changes when the interview is async instead of live.

What preparing for user interviews actually means

Preparing for user interviews is the work that happens between "we should talk to some users" and "the recording is running". It is four separate artefacts held together as one act of preparation: a decision the interviews will inform, a research question the interviews will answer, a discussion guide the moderator will run in the room, and a recruitment plan that puts the right participants on the calendar in time. Prep is not the same thing as writing questions. Writing questions is a subset of prep, and it is the subset most teams start with and mistake for the whole.

The Nielsen Norman Group's primer on user interviews frames the same idea as a sequence: define the goal, choose the participants, plan the discussion guide, then run the interview. The order matters. A guide written before the goal is named is a list of favourite questions. A recruitment plan written before the participant profile is specified is a list of nearby users. Prep, done well, forces the four artefacts to line up before the moderator sits down.

Steve Portigal's Interviewing Users makes the case, in a slightly different vocabulary, that most of the craft happens before the interview starts. Erika Hall's Just Enough Research treats the prep step as the one that decides whether the room will be able to change its mind after the readback. The through-line across all three: prep is where an interview earns its keep, and the room where the interview happens is downstream of that work.

Why most user interview prep fails

Three failure modes show up across teams preparing for their first serious interview cycle. They are structural. Better questions do not fix them.

The prep skips straight to the questions

The most common failure. Someone opens a doc, types the topic at the top, and drafts eight questions off the topic. The decision is unnamed, the research question is implicit, the segment is "some users who use the product", and the discussion guide is nine leading closed-ended items in a row. The interview will happen. It will not tell the team anything it did not already suspect. The fix is to force the sequence: decision first, question second, participants third, guide fourth. Questions come last because they depend on the three above them.

The interview is scoped to convince the room instead of change it

A more subtle failure. The PM prepares for the interview because a specific stakeholder has been asking why the team is not shipping feature X. The interview gets scoped, quietly, as a vehicle to produce the quote that will settle the argument. The prep looks fine on paper. The discussion guide is competent. The participants are real. But the interview cannot fail, because the person preparing it has already decided which answer is the interesting one. This is the failure mode described in how to reduce researcher bias in user interviews: confirmation bias enters at the prep stage, not the moderation stage, and once it is baked into the guide it is impossible to moderate out.

The fix is a sentence-level test: could this interview surprise us? If the honest answer is no, the prep is scoped wrong. Rewrite the research question so a disconfirming answer is imaginable, and rewrite the questions so the participant has room to give one.

The pilot gets skipped because "we don't have time"

The third pattern is the interview that goes live without a pilot. The discussion guide has never been read aloud. The moderator has never heard themselves ask the third question. The recording setup has never been tested end-to-end. The consent flow has never been rehearsed. The first "real" interview becomes the pilot, the guide gets rewritten between calls one and two, and the team quietly discards the first participant's transcript from the analysis. That is a wasted participant, a wasted incentive, and a wasted forty-five minutes of the moderator's day. A pilot takes one hour. It saves the study.

How to prepare for user interviews, step by step

Seven steps. The first three are the ones most prep skips over. Steps four through seven are the ones that make the interview run smoothly on the day.

01 · Anchor the interview to a decision

Before the guide, the participant list, or the calendar invites: what will the team do differently after these interviews, depending on what we hear?

If the honest answer is "nothing, this is background context", the study is generative, and that is a legitimate answer. Write it down. Generative interviews want a broader research question, a looser guide, more participants, and a longer synthesis window than evaluative ones. If the honest answer is "we will ship variant A if users want it and variant B if they don't", the study is evaluative, the threshold for "want it" belongs in the prep, and the guide can be tighter and shorter. The distinction is covered in generative vs evaluative research; the choice made here determines the shape of every artefact downstream.

A brief that names the decision explicitly does most of this work for the interview prep. If the study is important enough to warrant a written brief, write one before the guide: how to write a user research brief covers the pattern.

02 · Sharpen the research question into one sentence

The research question is the rudder. It is one sentence. It names a moment, admits a disconfirming answer, and maps directly to the decision from step 01. "Understand user friction with onboarding" is not a research question. "What stops a user who finishes onboarding from inviting a colleague in their first session?" is.

Three tests for a good research question. First, is it specific to a moment? "Why do users leave?" is too broad; "why do users who reach the second billing cycle cancel within a week?" is the right size. Second, can you imagine an answer that surprises the team? If every plausible answer supports the same conclusion, the question is doing no work. Third, does it map cleanly to the decision from step 01? If the question can be answered without changing the decision, one of them is wrong.

The craft of writing questions themselves (open-ended phrasing, avoiding leading question patterns, checking for bias) is in how to write user research questions. At this stage you are writing the one question above the guide, not the eight questions inside it.

03 · Pick participants and build the recruitment plan

Who the interview needs to reach. Two layers: the segment the interviews draw from, and the criteria that qualify a participant inside that segment.

The segment follows from step 01. A study to inform a cancellation-flow decision recruits churners, not active users. A study to inform an onboarding redesign recruits users who joined in the last thirty days, not power users. The wrong segment is the failure mode that wastes more research budget than any other, because the transcripts sound plausible but describe a population the decision does not apply to.

Sample size is a function of the method, not of the company. Six to twelve participants per segment for thematic in-depth interviews. The full breakdown, with the saturation literature behind it, is in how many user interviews do you need. Screener design (the questions that filter respondents into the study) is in how to write effective screener questions; the operational side (sourcing, incentives, scheduling, no-show buffers) is in how to recruit user research participants.

Book more calendar slots than you need. A thirty percent no-show rate is normal for cold recruits. Rescheduling in the second week of a study kills momentum; over-recruiting in week one is the operational insurance.

04 · Write the discussion guide, not a script

The discussion guide is the tactical instrument the moderator runs in the room. It is not a script; a script would be read out loud. It is a structured prompt with room for the participant to lead. The full pattern for the guide itself is in how to write a discussion guide; for prep purposes, the guide has four sections.

• Warmup. Two or three low-stakes questions that get the participant talking about their context. Not "tell me about yourself", which is a job-interview reflex. Something concrete: "walk me through the last time you opened the product this week".
• Open-ended core. Three to five questions that carry the study. These are the ones the research question from step 02 depends on. Each one is a question, not a topic; each one is phrased so the participant has room to say something the moderator did not expect.
• Focus areas. Two or three deeper prompts on the specific behaviour the decision hinges on. This is where the guide narrows.
• Close. One reflective question ("what haven't we asked about that matters here?") and a graceful exit.

Rehearse the guide out loud with a colleague before you take it to a participant. Reading the guide aloud surfaces the leading questions, the double-barrelled questions, and the questions that sound clinical on the page and awkward in conversation. Twenty minutes of rehearsal saves the first two interviews.

05 · Plan probes for the moments that matter

Probes are the follow-ups a moderator has ready before the room starts drifting. They are not scripted; they are pre-loaded. A guide without planned probes produces a shallow transcript because the moderator has to invent the follow-up in real time, on top of listening, on top of keeping time. The moderator's attention runs out. The probe never happens. The moment passes.

For each of the three to five open-ended core questions, plan two probes in advance. One that widens ("say more about that"). One that narrows ("what specifically happened next?"). A third, situational, for the answers you already suspect will get rehearsed replies ("what would surprise you about that?").

Probes are how a good interview reaches the second story, the one behind the first. The pattern that governs when to widen and when to narrow is covered in AI follow-up questions for user research. In async, the same pattern shows up as configurable probing depth: shallow for a single clarifier, medium for a small chain of follow-ups, expert for the moments where the AI keeps probing until it has the context a senior researcher would dig out (contradiction, scope, who / when / how, prior alternatives tried). The prep decision is per question, not per study.

06 · Set up recording, transcription, and note-taking

Three technical pieces the moderator will regret not testing in advance.

Recording. Test the platform's recording end-to-end the day before, with the consent screen visible to a fake participant. Zoom's cloud recording sometimes silently fails on the moderator's first call after a settings change; Meet's caption stream stops rendering if the extension updates overnight; on-device recording depends on the participant approving mic access before the interview starts. If the pilot in step 07 is going to catch anything, it will catch this.

Transcription. Decide before the interview whether the transcript is the artefact of record or the field notes are. The right answer for in-depth interviews is almost always the transcript; the transcript analysis method depends on verbatim, and coding from memory produces the confirmation bias described in the failure modes above. Turn on the transcription tool, verify it captures the moderator's voice as well as the participant's, and verify the output is a plain text file the team can search.

Note-taking. If the moderator is note-taking during the interview, the notes will be shallow. The moderator's attention is finite. Book a note-taker for the important interviews (a second researcher, a PM, sometimes an engineer). If a note-taker is not available, restrict notes to timestamps and one-word tags: 12:41 · pricing, 18:03 · churn. The full notes get written after the call, from the transcript.

07 · Pilot the interview before the first real participant

The pilot is the step teams skip and then regret. Run one full-length interview end-to-end with a colleague, ideally someone who is not on the study team, playing the participant. The pilot tests three things at once: the guide (do the questions land?), the technical setup (does recording, consent, and transcription work?), and the moderator's timing (does the interview fit inside its slot?).

Expect the pilot to change the guide. It will change the guide. Two of the questions will be rewritten. One will get cut. One warmup will get replaced. The consent script will get shortened. The moderator will realise they were going to introduce themselves for ninety seconds and cut it to twenty. The pilot is the cheapest edit the study will ever get; the first real participant is the most expensive one.

How to prepare for async user interviews

The seven-step frame holds for async, with two shifts.

The first shift is that the discussion guide becomes a study, not a schedule. Instead of preparing to ask five questions inside a forty-five-minute window, the researcher prepares five questions that will stand on their own inside a link the participant opens on their own time. Each question needs to work without a moderator sitting in the same room. Warmups matter less; framing matters more. The how to write user research questions prep checklist applies twice as hard.

The second shift is that probe planning becomes probe policy. In a live interview the moderator decides in the moment whether to widen or narrow. In an async study the researcher decides, per question, how deep the AI should probe if the answer is vague. Set shallow for quantitative rating sweeps and low-friction in-product feedback surfaces where dropout matters more than depth. Set medium for context-rich discovery questions where a single clarifying probe is enough to make the answer actionable. Set expert for the moments where the team would otherwise schedule a moderated interview, and let the AI keep probing until the transcript has the level of context a senior researcher would extract in the room. Participants keep the right to skip on every probe.

The third, unmentioned shift is who takes part in the interview. A live interview is expensive enough that most teams reserve it for external participants only. An async study is cheap enough that the same instrument works inside the company. Drop the link into engineering, design, support, and finance before a decision is made, and get a synthesised view of every function's position on it. The prep for that internal use case is the same seven steps run for a much smaller audience, and the payoff is a room that arrives at the decision meeting already knowing where the real disagreement lives. The wider pattern is in how to build a customer feedback loop.

The half hour of prep that decides whether an interview produces evidence is not the half hour writing the questions. It is the half hour naming the decision, the segment, and the surprise the room is prepared to hear.

Where a Talkful study link fits in ongoing interview prep

Interview prep is often framed as a per-study act. In practice, the teams that get the most out of their prep treat it as continuous. The same Talkful study link can live on the in-product feedback surface, on the pricing page, inside the cancel flow, and on the post-onboarding email at the same time, and each surface produces its own prepared stream of participant answers, synthesised as the responses land. The prep for each surface is smaller (one or two questions, a fixed probing depth, a defined segment) and the payoff compounds: by the time the team sits down to prep a live interview cycle, they already know which hypotheses are hot and which have been quietly disproven by continuous signal. The full model is described in continuous discovery interviews.

FAQ

How long does it take to prepare for a user interview?

Two to four hours for the first interview of a study, and forty to sixty minutes for each subsequent one in the same cycle. The first interview absorbs the decision framing, the research question, the discussion guide, the recruitment brief, and the pilot. Interviews two through ten reuse those artefacts and only need a per-participant read: what does the intake form say about this person, and are there specific probes to add for their profile. Teams that budget less than two hours for the first prep in a study consistently produce interviews that need to be re-run.

What should be in a user interview prep checklist?

Seven items, in order. A named decision the interviews will inform. A one-sentence research question that admits a disconfirming answer. A segment definition with recruitment criteria. A one-page discussion guide with a warmup, three to five open-ended core questions, focus prompts, and a close. Two planned probes per core question. A tested recording, transcription, and note-taking setup. One pilot interview completed with a colleague before the first real participant joins. Missing any single item is survivable. Missing three of them is the profile of an interview the team will not be able to act on.

How do you prepare for a user interview when the topic is unfamiliar?

Do a two-hour desk-research pass before writing the guide. Read the last five support tickets on the theme, the last three sales calls with prospects who mentioned it, the analytics event trail if one exists, and any prior research the team ran adjacent to the question. Then, and only then, draft the research question. Preparing an interview on an unfamiliar topic without a desk-research pass produces a guide that asks the participant to teach the moderator the domain, which wastes the participant's time and produces a shallow transcript. The desk research does not need to be exhaustive. It needs to be enough that the moderator can recognise a surprising answer when they hear one.

Should the participant see the questions before the interview?

Not the full guide. A short pre-interview summary of the study (what the team is trying to learn, roughly how long the call will run, that the participant can skip any question) is appropriate and shortens the warmup. Sending the full list of questions in advance produces rehearsed answers on the questions the participant thinks matter most, which is the opposite of what an interview is for. The exception is when the topic requires the participant to bring evidence to the call (a recent invoice, a specific piece of work, a screenshot); in that case, the relevant prompt is shared in advance so the participant can find the artefact.

What's the difference between preparing for user interviews and preparing for a focus group?

The prep artefacts overlap: both need a decision, a research question, a segment, a guide, and a recording setup. The differences are in participant management and moderation load. A focus group prep needs a plan for balancing dominant participants against quiet ones, a warmup that reads across a room rather than to one person, and a moderator briefed on group-dynamic effects (groupthink, social desirability bias, the loudest voice setting the frame). In-depth interview prep, by contrast, invests more in per-participant probing depth and less in group facilitation. The two methods answer different questions; the prep should not be shared.

How do you prepare for async user interviews?

The seven steps hold. The differences are that the discussion guide becomes a self-contained study instead of a schedule, probe planning becomes a per-question depth setting (shallow, medium, expert) instead of a live moderation call, and the pilot is a test-run of the participant experience end-to-end (open the link, answer one question, receive a probe, submit) rather than a rehearsal of a moderated conversation. Prep for async takes about half the total time of prep for live interviews, mostly because the schedule variable falls away. The prep for probing itself is covered in AI follow-up questions for user research.

---

Preparing for a user interview is the work that decides whether the room ninety minutes later produces a transcript the team can act on or a summary nobody argues with. One decision. One research question. One segment. One discussion guide. Two probes per core question. One pilot. The prep does not need to be heavy; it needs to be sequential, and it needs to happen before the calendar invites go out. When it does, the interviews start earning their keep. The Talkful free plan is the cheapest place to try the async version of this against a real study attached to a real decision, and the wider voice user research guide covers where the interview sits in a continuous product-research rhythm.