How to run in-depth user interviews

The interview runs for fifty minutes. The transcript reads clean. Three days later, the researcher opens the coding tool, scans the file, and cannot find the moment where the participant said the thing the team needed to hear. There isn't one. The conversation stayed a foot above the ground the entire time. The participant answered every question and revealed nothing. This is the failure mode of an in-depth user interview that was run as a checklist instead of a conversation, and it is the modal outcome the first four times a new researcher tries the method.

This is a working guide on how to run in-depth user interviews that produce specific, defensible evidence about how a person actually behaves: what the method is, when it is the right instrument, six steps that hold up when the participant drifts, the failure modes to catch in flight, and how async voice studies with configurable adaptive probing can reach the same depth without needing an hour of the participant's calendar.

What in-depth user interviews are

In-depth user interviews (often abbreviated IDIs, sometimes just "depth interviews") are semi-structured one-on-one conversations, usually forty-five to ninety minutes long, in which a moderator explores a small number of themes with a single participant using open-ended questions, active probing, and follow-up questions calibrated to what the participant has just said. The output is a rich qualitative transcript per participant, coded and synthesized into themes across the sample.

The method sits distinct from three neighboring formats. A structured interview asks every participant the same closed-ended list and behaves like an oral survey. A focus group runs many participants in one room and captures group dynamics rather than individual reasoning. A customer discovery interview is a specialized IDI shape used to test falsifiable business hypotheses before a product is built. An IDI is the parent method: long, individual, semi-structured, exploratory. The Nielsen Norman Group's primer on user interviews is the shortest authoritative overview if you want the textbook definition alongside this guide.

The unit of analysis is the participant, not the answer. A cross-tabulation of "seven of ten participants mentioned X" is not the goal of an IDI. The goal is a thick description per person: a coherent account of how one participant thinks about the problem, arrived at through enough probing that the account survives the participant's first three rehearsed responses.

When to run in-depth user interviews

Three cases where an IDI is the obvious right method.

• You need reasoning, not counts. The team already has behavior data (analytics, support tickets, quantitative surveys) telling them what is happening. What they need is why. IDIs are built for the mechanism, not the frequency.
• The behavior is rare or private. A specialist workflow, a life event, a decision that happens once a quarter. Any format that averages across many participants at once will bury the specifics. An IDI captures the specifics before the participant polishes the story.
• The team is deciding something big. A category entry, a repricing, a major redesign. An IDI produces the kind of evidence that survives a room full of skeptics because every claim is traceable to a specific participant on a specific day.

Two cases where an IDI is the wrong instrument.

• You need to see the cursor hover. Live usability testing needs eyes on the screen and swearing near the mic. An IDI is verbal; usability is embodied. Use usability testing instead.
• You need statistical claims. A team that needs to argue "sixty percent of paying customers do X" cannot get there from twelve interviews. A survey with a defensible sample is the right instrument. The IDI can inform the survey design.

How to run in-depth user interviews, step by step

Six steps. The first is the one most teams skip. The last is the one most teams give to a junior researcher and then wonder why the deck reads soft.

01 · Frame the decision the interviews owe evidence to

Before writing a single question, write down the decision the study is going to inform and the specific evidence that would move the team off its current position. "Understand our users better" is not a decision. "Decide whether next quarter's onboarding rewrite prioritizes activation for solo founders or team leads" is a decision. The IDIs owe evidence about the difference between those two segments, not a general understanding of anyone in the funnel.

Framing the decision up front does three things. It filters the participant list (who do we need to interview to answer this?), it filters the guide (which themes are we exploring, and which are we out of scope?), and it filters the synthesis pass at the end (what does a defensible answer to the decision look like?). Teams that skip the framing produce transcripts full of interesting quotes and no clear call. The longer treatment of framing sits in the piece on how to write a user research brief.

02 · Write a semi-structured discussion guide

The guide is not a script. It is a set of themes to reach, ordered from broad to specific, with one or two anchor questions per theme and a bank of probes for each. A common shape: an opening warm-up that gets the participant talking about themselves, three or four exploratory themes in the middle, and a closing question that gives the participant permission to add anything the guide missed.

The rule that separates a working guide from a bad one is that the guide is a list of what you want to understand, not a list of what you plan to say. The exact wording of each question gets rewritten in the moment based on how the participant has been talking. The full craft is covered in how to write a discussion guide and, at the question level, in how to write user research questions. The two pieces together are the prep work for step three.

03 · Recruit the segment, not the calendar

The biggest mistake in most in-depth user interview programs is that the participant list is whoever the recruiter can book that week. The right participant list is a small, deliberate cohort that maps to the decision from step one: two or three participants per segment, with a screener that rejects anyone outside it.

Cohort size for saturation on a homogeneous segment is well-studied. Guest, Bunce and Johnson's foundational paper found ninety-plus percent of themes surface in the first six interviews of a segment, and near-total saturation at twelve. The practical rule most product teams use is eight to twelve participants per segment, recruited to a screener that filters on the exact behavior or context the study needs, not on availability. The deeper treatment of sizing sits in how many user interviews do you need.

The screener is doing more than gatekeeping. It is the first place bias enters the study. A screener that filters on "regular users of a competitor" will produce a sample where every participant has already switched off the competitor. That is a valid segment. It is not a representative one. The team needs to know which segment they are actually interviewing before they draw conclusions from it.

04 · Moderate for depth, not coverage

The moment the interview starts, the guide stops being a checklist. The moderator's job is to follow the participant into whatever they said that was surprising, contradictory, or specific, and stay there long enough to understand it. If reaching theme three means abandoning theme two, abandon theme two. Coverage of all four planned themes at a foot deep is a worse interview than coverage of two themes at ten feet deep.

Three probing patterns carry most of the depth. The first is the behavioral anchor: whenever the participant answers in generalities, ask about a specific instance. "When was the last time that happened?" The generality dissolves and the specifics arrive. The second is the five-whys pattern, sometimes called laddering, in which each answer becomes the next question's target. Push it three levels; the fourth usually collapses into reasoning the participant has not verbalized before. The third is the silence probe: after the participant finishes an answer, wait. Four seconds of silence forces most people to continue, and the continuation is often the part they were editing out.

The behavior to avoid is what interview coaches call "the confirmatory follow-up": asking a leading question that hands the participant the answer you already expect. "So it sounds like the price was the main issue?" contaminates the transcript from that point forward. The recovery is to strike the answer and ask again with a neutral prompt. The full anti-bias playbook sits in how to reduce researcher bias in user interviews.

05 · Transcribe and code for themes

Once the interviews close, transcribe every session. Any modern speech-to-text pipeline produces a working first-pass transcript for a fraction of the cost of a human transcriber; the cost of skipping this step is that the researcher codes from memory instead of from the text, and memory over-weights the two interviews that ran on Friday. The trade-offs on the transcription pipeline itself are covered in how to analyze user interview transcripts.

Coding is where a thick description per participant turns into cross-cutting themes. The canonical method is Braun & Clarke's reflexive thematic analysis, which runs six phases: familiarization, initial code generation, theme construction, theme review, theme definition, and writing up. The practical shape is that a researcher reads each transcript end to end, tags passages with short codes ("switching cost", "team decision", "onboarding friction"), then clusters the codes into themes across participants.

Verbatim quotes are load-bearing at this step. A theme that cannot be evidenced with two or three verbatim quotes per participant is not yet a theme. It is an intuition the researcher held before the interviews began. Reject it and go back to the transcripts.

06 · Synthesize into the decision the team owes

The final deliverable is not a summary of the interviews. It is a set of claims about the decision framed in step one, each with the evidence that supports or contradicts it, ranked by the number of participants who spoke to it and the specificity of what they said.

A synthesis that reads "seven of twelve participants mentioned pricing" is not a synthesis. It is a table. The synthesis is the sentence after it: "The pricing objection lives specifically in the two-week trial extension request, is anchored to the moment the participant showed the tool to their manager, and reads as an approval-workflow problem more than a headline-price problem, based on the way five of the twelve narrated it." That sentence is what the roadmap decision needs. The full working method sits in how to synthesize user research.

Failure modes to catch in flight

Six patterns that eat in-depth user interview programs. Naming them makes them easier to catch mid-interview.

• The talking moderator. The moderator speaks more than the participant. The recovery is silence: the four-second pause after each answer.
• The rehearsed answer. The participant delivers a smooth story that has been told before. The recovery is a specific behavioral anchor to a moment before the story was polished.
• The confirmatory follow-up. The moderator asks a leading question. The recovery is to strike and re-ask with a neutral prompt.
• The abandoned probe. The participant says something surprising and the moderator moves on to the next theme. The recovery is to stay: the surprise is the interview.
• The unfalsifiable claim. The synthesis reads as a general truth that could have been written before the study started. The recovery is to force each claim to name the participants who support it and the participants who contradict it.
• The deck-shaped deliverable. The output is a slide deck that dies in the meeting it was presented in. The recovery is to keep the verbatim quotes, the audio, and the coded transcripts as the deliverable, and let the deck reference them.

"I thought the theme was pricing. It wasn't. It was that she had already burned her manager's trust on two failed pilots, and the price was the excuse she was going to give. If I had stayed with the pricing frame we would have redesigned the wrong screen."

How async voice studies scale in-depth user interviews

The hard cost of an IDI program is the calendar. Booking twelve one-hour calls across four time zones takes two weeks of coordination and produces twelve hours of audio and roughly two weeks of researcher time to code. Teams that need continuous evidence, not a quarterly study, cannot sustain that cost. The choice usually falls back on a survey, which loses the depth the IDI was there for.

The async pattern that closes the gap: a study link the participant answers on their own time, in voice, text, choice, or rating, with an AI interviewer that runs the probing chain the moderator would have run. Probing depth is configurable per question. On a shallow setting the AI asks at most one clarifier and moves on; on medium it probes a small chain when the answer is vague; on expert it keeps going until the participant has been walked through contradictions, prior alternatives, and the specific moment the behavior last happened. Expert depth is what carries an IDI's function into async. The general treatment of the pattern sits in AI-powered async user research; the probing craft in particular is in AI follow-up questions in user research.

Three things follow. The first is that the link is a standing instrument. Placed inside the product, at cancellation, on a docs page, or in an onboarding email, it collects IDI-shaped answers continuously instead of in a discrete study window. The team does not need to close a study and open the next one; the responses land as the surface produces them, and the synthesis engine streams themes back as they arrive. The second is that the same link works inside the company, not just for external customers. A prototype review, a contested launch decision, or a legal-security-finance sign-off can be run as an internal async IDI: share the link with the stakeholders, get a synthesized cross-functional view, and skip the meeting. The third is that the deliverable is structured, not a deck. Each response stays linked to the participant, each quote to a timestamp, each theme to the responses that produced it. That structure is what makes the output legible to the next researcher, the next decision, and the agents your product team is building on top of the same data.

For teams running IDIs today, this doesn't replace the ninety-minute call. It changes what the ninety-minute call is for. The synchronous IDI stays the right instrument for the two or three interviews per quarter where rapport, embodied response, and multi-turn expert conversation are structurally required. Everything else, the ongoing evidence a product team needs to keep making calls without burning out the researcher, moves to the async pattern. If you want to try it, Talkful has a free plan that will run a first study; the working guide to voice user research covers what to do once the responses start landing.

FAQ

What are in-depth user interviews?

In-depth user interviews are semi-structured one-on-one conversations, usually forty-five to ninety minutes long, in which a moderator explores a small number of themes with a single participant using open-ended questions and active probing. The output is a rich qualitative transcript per participant, coded and synthesized into themes across the sample. The method is exploratory rather than confirmatory: the goal is a thick, defensible account of how each participant thinks, not a cross-tabulation of answers.

How many in-depth user interviews do you need?

Eight to twelve participants per homogeneous segment is the practical range for thematic saturation, following Guest, Bunce and Johnson's finding that ninety-plus percent of themes surface in the first six interviews and near-total saturation lands at twelve. If the study spans multiple segments (say, solo founders and team leads), size the sample per segment, not across the whole study. Recruit roughly 1.3x your target to absorb dropoff. The deeper treatment is in how many user interviews do you need.

What is the difference between an in-depth interview and a focus group?

An in-depth interview is one moderator with one participant, exploring themes long enough to reach specific behavioral evidence. A focus group is one moderator with six to ten participants together in one session, exploring group dynamics and surfacing collective language. IDIs are better for reasoning and private behavior; focus groups are better for language patterns and normative reactions in a category. The two methods answer different questions and are not substitutes.

Can in-depth user interviews be run async?

Yes, with a caveat. A traditional live IDI depends on the moderator following the participant across surprising answers, and async formats historically lost that follow-up. The current async pattern is a link the participant answers in voice, text, choice, or rating, with an AI interviewer that runs a configurable probing chain (shallow, medium, or expert) on each answer. On expert depth the AI keeps probing until the participant has been walked through contradictions and specifics, which is the function the live moderator was performing. The two-turn expert interview still belongs in a live call; a lot of the rest can move async without losing signal.

How do you analyze the transcripts from in-depth user interviews?

The canonical method is reflexive thematic analysis, developed by Braun and Clarke in the Journal of Qualitative Research in Psychology. Six phases: familiarize with the data, generate initial codes, construct candidate themes, review themes against the transcripts, define and name themes, and write the synthesis. Verbatim quotes anchor each theme; a theme that cannot be evidenced with two or three verbatim quotes per participant is not yet a theme. The step-by-step working method is in how to analyze user interview transcripts.

How long should an in-depth user interview be?

Forty-five to ninety minutes is the standard range. Shorter than forty-five and the moderator does not have time to reach the specifics behind the rehearsed answers; longer than ninety and the participant's answers get shorter and more compliant as they tire. Sixty minutes is a good default. If the guide feels like it needs more, run two sessions with the same participant on separate days rather than one long session.

---

The version of the method that survives contact with a real product team is the one where the sixty-minute call is used sparingly and the ongoing evidence is captured with an async link the participant answers on their own time. The synchronous IDI produces the deepest single artifact; the async pattern produces the continuous stream. Both belong in a real research program. Neither is a substitute for framing the decision the interviews owe evidence to before the first participant is booked.