How to Analyze User Interview Data: Step-by-Step

Turn raw interview transcripts into actionable insights with this practical step-by-step workflow — covering coding, pattern recognition, synthesis, and

Why Analysis Is the Step Most Teams Rush
Step 1 — Prepare Your Raw Material Before You Touch the Data
Step 2 — Code Your Transcripts to Surface Raw Themes
Step 3 — Cluster Codes into Themes Using Affinity Mapping
Step 4 — Assess Frequency, Strength, and Novelty of Each Theme
Step 5 — Translate Themes into Insights and Opportunity Statements
Step 6 — Sense-Check, Document, and Store Findings
Common Mistakes and How to Avoid Them
Frequently Asked Questions

Why Analysis Is the Step Most Teams Rush

Most research value is lost not in the field, but at the desk. Teams wrap their final session, feel the momentum of having collected something, and jump straight to writing recommendations — skipping the structured work that turns raw conversation into defensible insight.

The failure modes are predictable. Researchers lean on memory instead of transcripts. One person filters everything through their own frame. “Themes” become whatever stood out in the last session. The output confirms what the team already believed, and the slides gather dust.

This guide treats user interview analysis as a repeatable, auditable process — not a creative leap. It picks up exactly where the interview session ends and walks through each step in sequence. If you are still planning fieldwork, start with running effective user interviews first, then come back.

Step 1 — Prepare Your Raw Material Before You Touch the Data

Before you code a single line, get your material into a stable, consistent state. Analysing from scattered files and half-remembered notes produces unreliable output.

Transcription decisions. Automated transcription (Otter, Whisper, Rev’s automated tier) is fast and good enough for most analysis work. Human transcription earns its cost when audio quality is poor, accents are varied, or domain-specific terminology matters. You do not need a verbatim, every-um transcript for thematic analysis — a clean, readable version is enough. Reserve verbatim for linguistic analysis or direct quotation in a formal report.

Canonical participant documents. Create one document per participant containing: a participant ID (P01, P02, and so on — not their name), the session date, a brief context note (role, relevant screener details), the transcript or cleaned notes, and any observer notes from the session. Keep recordings and timestamped notes as supplementary sources, linked from the canonical document rather than embedded in it.

Folder and naming conventions. A simple structure works: /study-name/participants/P01/ with consistent file names. The goal is that any team member can navigate to a specific quote’s source without asking you. Define this before analysis starts, not after.

Scope definition. Be explicit about which sessions are included in this round and why. If you ran ten sessions but two were with an out-of-segment participant, note that and exclude them deliberately. Scope decisions belong in your user research plan template and should be documented here for auditability.

Step 2 — Code Your Transcripts to Surface Raw Themes

Coding is the act of applying a short label — a code — to a meaningful unit of text. That unit might be a single sentence, a longer exchange, or an observed behaviour note. The code captures what that unit is about in a way that makes it retrievable later.

Inductive vs. deductive coding. For generative or exploratory research, start inductively: read the transcript and let codes emerge from what participants actually said, rather than from a pre-existing framework. Deductive coding — applying codes derived from a prior model or hypothesis — fits when you are testing a specific set of assumptions. Most user research benefits from an inductive first pass and a deductive second pass.

Practical process. Work through each transcript in turn. Highlight a meaningful unit, write a short code label beside it (two to five words), and log it in your chosen tool. A spreadsheet with columns for Participant ID, Quote, Code, and Section works well. Notion databases, Dovetail, and Atlas.ti offer more structure for larger studies or teams that need longitudinal retrieval, but the underlying logic is identical.

Two-pass approach. On the first pass, apply codes liberally — capture everything potentially relevant. On the second pass, review your code list and merge near-duplicates. “Difficulty finding settings” and “can’t locate preferences” are almost certainly the same code.

Provenance discipline. Keep the participant ID attached to every coded quote throughout the process. Stakeholders will ask “who said that?” and you need to answer without re-reading every transcript.

Expected volume. A set of 6–10 interviews will typically produce 20–60 distinct codes before consolidation. If you have significantly more, your first-pass codes are probably too granular — aim for codes that label a type of thing, not a unique moment.

Step 3 — Cluster Codes into Themes Using Affinity Mapping

Codes are granular. Themes are the higher-order patterns that emerge when you group codes that belong together. Affinity mapping is the method for getting from one to the other.

The method. Write each code (and optionally its representative quote) on a separate card or sticky note — physical or digital. Then move cards into clusters based on similarity of meaning. The spatial act of grouping forces you to make explicit decisions about what belongs together, which is more reliable than doing the same work mentally.

Tool trade-offs. Physical sticky notes on a wall are fast and tactile, but require co-location and leave no digital record. FigJam and Miro work well for distributed teams and preserve the artefact. Dedicated tools like Dovetail handle the linkage between codes and themes automatically, which saves time at scale. Choose based on your team’s working pattern, not on what looks impressive.

Collaborate. Run affinity mapping with at least one other person — a second researcher, a designer, or an informed stakeholder. Single-researcher affinity mapping is vulnerable to the same confirmation bias it is meant to guard against. Disagreements about which cluster a code belongs to are analytically useful; they reveal ambiguity in your coding or genuine tension in the data.

Name themes precisely. Use outcome or behaviour language rather than topic language. “Users struggle to track their progress after onboarding” is a theme. “Progress tracking” is a topic. The distinction matters: behaviour-language names encode the finding, not just the subject area, which makes them far more useful in reports and prioritisation conversations. We cover the mechanics in our post on affinity mapping in qualitative research.

Validate boundaries. A well-formed theme is internally coherent — all its codes clearly belong together — and distinct from adjacent themes. If two themes could plausibly merge without losing meaning, merge them. Aim for 5–12 themes from a typical study. More than that usually signals under-consolidated codes.

Step 4 — Assess Frequency, Strength, and Novelty of Each Theme

Once you have a stable set of themes, resist the urge to treat them as equally important. They are not. Three dimensions help you weigh them.

Frequency is the number of participants who contributed evidence to a theme — not the number of times a single participant mentioned it. One participant who returned to a topic five times counts as one data point, not five.

Strength is the degree to which the evidence is emotionally charged or behaviourally consequential. A participant who describes a workaround they built because a feature failed them is providing stronger evidence than one who mentions, in passing, that something could be clearer.

Novelty is whether the theme contradicts existing assumptions or confirms them. Both matter, for different reasons. Confirming evidence validates decisions already made; contradicting evidence is where the highest-value redirections come from.

Build an evidence matrix. A simple grid with themes as rows and participant IDs as columns, with coded quotes in the cells, makes all three dimensions visible at once. You can see which themes have broad coverage, which rest on one unusually strong data point, and which are genuinely surprising.

Handle outliers carefully. A single compelling quote from one participant can feel definitive in the moment. Flag it — do not discard it — but do not let it outweigh a quieter signal that ran across six participants. In one study examining how professionals in a specialist field made purchasing decisions, the most actionable finding turned out not to be the vivid story one participant told, but a hesitation about data provenance that nearly every participant mentioned briefly and then moved on from. The evidence matrix made that pattern visible; memory alone would have missed it.

By the end of this step, you should be able to rank your themes by evidential weight. If you cannot, the matrix is not complete.

Step 5 — Translate Themes into Insights and Opportunity Statements

A theme describes a pattern. An insight explains it in a way that suggests what to do next.

The structure of an insight. A well-formed insight has three parts: an observation, the context that produces it, and the consequence for the user or the business. Compare these two:

Theme: Users don’t trust the data.
Insight: Users don’t trust the data because they cannot see its source, so they export figures into a spreadsheet to verify them manually before sharing with colleagues — adding 20–40 minutes to a task the product was designed to make instant.

The insight is more useful because it contains a causal explanation and a consequence. A product team reading it knows what to investigate and why it matters.

Mapping themes to insights. One theme can yield multiple insights if it has distinct sub-patterns. One insight should map to one clearly bounded opportunity area, or prioritisation becomes muddled.

Write opportunity statements. Convert each insight into a “How might we…” question to make it actionable for product and design teams. “How might we help users verify data provenance without leaving the product?” is a brief that a designer can respond to.

Prioritise deliberately. Not every insight warrants equal investment. Apply an effort/impact frame to rank them against business outcomes. Our post on opportunity prioritisation in product research covers that process in detail.

Step 6 — Sense-Check, Document, and Store Findings

Analysis is not finished when you have written your insights. It is finished when those insights are reviewed, documented with their evidence chain, and stored somewhere they can be found again.

Peer review. Share your insight statements with one other researcher or a well-informed stakeholder before treating them as final. Ask them to challenge the logic, not just agree with the framing. Insights that survive scrutiny are more defensible in a findings read-out.

Document the chain of evidence. For each insight, record the path: raw quote → code → theme → insight. This is not administrative overhead — it is what lets you answer “what did participants actually say about that?” six months later, when the team is revisiting a decision.

Research repository. Store findings in a shared, searchable location tagged by date, study type, and product area. A finding that lives only in a slide deck is invisible to future research. Teams that maintain a repository stop re-discovering the same issues in successive studies — a direct saving in research cost and stakeholder goodwill.

Insight summary cards. Consider a one-page summary card per major finding: insight statement, supporting quotes, confidence level, and opportunity statement. These travel well to stakeholders who will not read a full report.

Timing. Schedule a findings read-out within five business days of completing analysis. Momentum matters; a team that has been waiting two weeks for output is harder to mobilise. For context on how this fits into broader research communication, see our post on win-loss analysis for B2B SaaS, which applies similar documentation principles to a different research type.

Common Mistakes and How to Avoid Them

Confirmation bias. Coding only the quotes that support an existing hypothesis is the most common failure in single-researcher analysis. A second coder working independently — even on a subset of transcripts — surfaces the discrepancy quickly.

Thematic drift. A theme that means something slightly different by the end of analysis than it did at the start will corrupt your evidence matrix. Write a one-sentence definition for each theme early, and check codes against it as you add them.

Analysis paralysis. Endless refinement is a form of avoidance. Timebox each step: coding, clustering, insight writing. Good-enough analysis delivered on time beats perfect analysis delivered after the product decision has already been made.

Over-claiming from small samples. Qualitative research supports pattern recognition and hypothesis generation, not statistical inference. Be explicit in your outputs about what the data can and cannot support.

Skipping storage. Findings that exist only in one presentation are lost to the organisation the moment that file is archived. The storage step is not optional.

Frequently Asked Questions

How many user interviews do I need before I can start analysis?

You can begin coding after the first two or three sessions. Starting early is useful — it helps you spot thematic saturation as it happens, rather than discovering it only after you have run ten interviews you did not need. Most studies with 5–8 participants drawn from a reasonably homogeneous segment reach saturation on core themes. Run analysis in parallel with fieldwork, not sequentially after it.

What is the difference between coding and affinity mapping?

Coding works on the text: you read a transcript and apply short labels to meaningful units. Affinity mapping works on the codes: you group those labels spatially to surface higher-order themes. The two steps are distinct and sequential. Conflating them — trying to jump from transcripts to themes in one move — is where important nuance gets lost.

Do I need specialist software to analyse user interview data?

No. A spreadsheet handles coding and the evidence matrix. FigJam or Miro handles affinity mapping. That combination is enough for most agency-scale or in-house studies of up to 20 sessions. Dedicated tools such as Dovetail or Atlas.ti earn their cost when you are managing large volumes of interviews, need longitudinal retrieval across multiple studies, or have a team large enough to benefit from built-in collaboration features.

How long does user interview analysis typically take?

A practical heuristic: allow one hour of analysis time for every hour of recorded interview. A six-session study with 45-minute sessions therefore needs roughly six to eight hours of analysis work, spread across coding, clustering, and insight writing. This assumes reasonably clean transcripts and a researcher already familiar with the topic domain. Add time if the material is technically complex or the team is new to qualitative methods.

About Glasgow Research — Glasgow Research helps B2B SaaS teams turn customer and market research into product decisions. Work with us.