How to Transcribe and Analyze Focus Group Data: A Research Workflow

By the YumiLM Team

A step-by-step coding workflow for focus group data: read for interaction first, open-code by speaker, add interaction codes, build the codebook, analyze convergence, cross-check outliers, write up with the unit explicit

Focus group transcripts are harder to analyze than one-on-one interview transcripts because the unit of analysis is ambiguous by default — a comment can matter as an individual's view, as a group's converged position, or as a moment of group dynamics (agreement, pushback, someone going quiet after being interrupted). A workable analysis plan resolves that ambiguity before coding starts, tags every speaker turn consistently so the interaction itself stays visible in the data, and treats convergence and disagreement between participants as findings in their own right, not as noise to average away.

Key Takeaways

Analyzing focus group data reliably requires deciding your unit of analysis up front, tagging every speaker turn (not just content) during transcript preparation, and coding group dynamics — agreement, dissent, shifts after social pressure — as data rather than discarding it.

Point	Details
Decide the unit of analysis first	Individual-level, group-level, or both — this choice shapes your codebook and cannot be retrofitted cleanly after coding starts.
Tag every speaker turn	A focus group transcript without consistent speaker tags loses the interaction data that separates a focus group from a set of stapled-together interviews.
Code group dynamics as data	Agreement, disagreement, and opinion shifts after another participant speaks are analytically meaningful, not noise.
Track saturation per topic, not per transcript	A 6–8 group study can reach thematic saturation on some questions well before others; check group-by-group, not just overall.
YumiLM for faster transcription prep	YumiLM turns a recorded session into a timestamped transcript and Insight Guide, but does not automatically separate or label speakers — plan a manual speaker-tagging pass for any multi-participant recording.

Why focus group transcripts need a different analysis plan than interviews
Preparing a focus group transcript for analysis
Choosing your unit of analysis: individual, group, or both
A step-by-step coding workflow for focus group data
Coding group dynamics: what to flag beyond content
Reliability and validation for group data
Common mistakes when moving from interview to focus group analysis
How YumiLM fits into a focus group workflow
Sources

Why focus group transcripts need a different analysis plan than interviews

A one-on-one interview transcript is a sequence of question-answer pairs from a single participant. A focus group transcript is a record of an interaction — participants respond to each other, build on comments, contradict one another, and sometimes revise a position mid-discussion after hearing someone else's view. That interaction is not incidental; in many studies it is the reason a focus group was chosen over individual interviews in the first place.

Two consequences follow directly. First, coding a focus group transcript as if it were several interviews spliced together throws away exactly the data that justified the group format — who influenced whom, where consensus formed quickly versus where it never formed at all, and which topics generated genuine disagreement versus polite non-engagement. Second, a small methodological choice made before analysis even starts — how speaker turns are tagged in the transcript — determines whether that interaction data survives into the coded dataset or is lost at the transcription stage.

The literature on this is consistent on one point even where methods diverge: while there is extensive published guidance on how to run a focus group, there is comparatively little specific guidance on how to analyze the resulting transcript, and the techniques that do transfer well from individual interviews — constant comparison, content analysis, thematic analysis — still need adaptation for group-level phenomena like conversational influence and shifting agreement.

Preparing a focus group transcript for analysis

Before any coding begins, a focus group transcript needs a few things an interview transcript does not:

Consistent speaker tags for every turn — not just "several participants agreed," but which specific participant (P1, P2, P3...) said what, in order. Losing this at the transcription stage cannot be recovered later without re-listening to the full recording.
Overlap and cross-talk markers — focus groups produce far more simultaneous speech than interviews. Mark segments where two or more people spoke at once, even if only one voice was intelligible enough to transcribe.
A moderator/participant distinction — moderator prompts, follow-up probes, and redirections should be visibly separate from participant responses, since they shape what participants say next and matter for interpreting the data.
Non-verbal and reaction notes — laughter, groans, a pause after a pointed comment, or someone visibly disagreeing without speaking are all analytically relevant in group settings in a way they less often are in one-on-one interviews.

A note on speaker labeling and AI transcription tools: most AI transcription tools, YumiLM included, return the audio as sequential timestamped text in the order it was spoken — YumiLM does not automatically detect, separate, or label individual speakers. For a one-on-one interview this rarely matters, since context usually makes clear who is speaking. For a focus group with four, six, or eight participants, it matters a great deal: without manual speaker tagging, a raw AI transcript reads as one long, undifferentiated block of dialogue with no way to trace a comment back to a specific participant. Plan for a manual tagging pass — using the audio, participant seating notes, or a moderator's running log of who spoke when — as a required step before coding, not an optional cleanup task.

Pro Tip: If you know in advance you'll need speaker-level analysis, have the moderator or an assistant keep a simple running log during the session — timestamp plus participant initials, noted every time the floor changes — even a rough one. Matching that log against an AI-generated timestamped transcript afterward is far faster than tagging speakers from audio alone with no reference points.

Choosing your unit of analysis: individual, group, or both

This is the single decision that shapes everything downstream, and it needs to be made before coding starts, not discovered partway through. Three options exist, and each implies a different codebook structure:

Individual as the unit of analysis — you code what each participant said, then look across participants (and across groups, if you ran several) for patterns, much like you would across a set of interviews. This suits research questions about the range of individual experiences or beliefs present in a population.
Group as the unit of analysis — you code the group's discussion as a single conversational unit, tracking how a topic was collectively worked through: where consensus emerged quickly, where it never formed, and how the group's framing of an issue shifted over the course of the discussion. This suits research questions about shared or contested meaning-making, not individual attitudes.
Both, explicitly separated — many studies genuinely need both layers: individual-level codes for who said what, and a parallel set of group-level codes for interactional moments (agreement cascades, someone visibly backing down after pushback, a moderator having to actively solicit a dissenting view). This is more coding work but avoids conflating "what most people in the room said" with "what most people privately believe," which are not the same thing in a group setting shaped by social pressure.

Methodological reviews of focus group research note there are still comparatively few established models for treating the group itself as the unit of analysis, compared with the abundance of guidance available for individual-level qualitative coding — one more reason to decide this deliberately rather than defaulting to interview-style individual coding out of habit.

A step-by-step coding workflow for focus group data

The core coding mechanics — open coding, a versioned codebook, theme development — carry over from interview transcript analysis. What changes for focus groups is what gets added on top:

Read for interaction, not just content, on the first pass. Before assigning any codes, read straight through noting where the conversation shifted direction, where a comment visibly changed the room's tone, and where the moderator had to intervene. This becomes an interaction memo, separate from your content codes.
Open-code content as you would for an interview, but keep every code attached to its specific speaker tag, not just the transcript as a whole. Losing the speaker attribution here means you cannot later separate "one vocal participant said this" from "the group converged on this."
Add a parallel layer of interaction codes. Common categories include agreement (explicit verbal agreement with a prior speaker), dissent (explicit disagreement), build (elaborating on a prior comment without disputing it), and shift (a participant visibly changing their stated position after hearing others).
Cluster content codes into a codebook, following the same definition–inclusion–exclusion–example structure used for interview coding, but calculate at least one round of frequency by how many distinct participants raised a code, not only how many times it appears — a code that eight different participants raised once each is a different finding than one participant raising it eight times.
Analyze convergence and divergence explicitly. For each major topic, note whether the group reached apparent consensus, remained split, or never substantively engaged — and log this per group if you ran multiple sessions, since consensus patterns often vary by group composition.
Cross-check surprising individual comments against the group context. If one participant's coded response looks like an outlier, check whether it came before or after a dominant voice spoke — social pressure and moderator sequencing both shape what gets said and when.
Write up findings with the unit of analysis explicit. State clearly whether a finding describes individual-level variation, group-level convergence, or an interactional pattern (e.g., "consensus formed quickly on X but only after the moderator directly solicited dissenting views on Y") — collapsing these into one undifferentiated "participants felt that..." statement is one of the more common ways focus group findings get overstated.

Coding group dynamics: what to flag beyond content

Group dynamics are not a methodological footnote in focus group research — they shape which data you actually collected. A few patterns worth building explicit codes for:

Dominance and airtime imbalance — one or two participants accounting for a disproportionate share of the discussion, which can crowd out other perspectives without any single comment looking problematic in isolation.
Social desirability and go-along effects — participants revising or softening a position after a more assertive participant states theirs, sometimes visible only as a shift in tone or hedging language rather than an outright reversal.
Silence as data — a participant who stops contributing after being interrupted or contradicted is itself a finding worth noting, not a gap in the transcript to skip past.
Moderator influence — how a probe was worded, or which participant the moderator turned to next, can shape what gets said afterward; coding moderator turns separately makes this visible rather than invisible in your data.

Reviewers of focus group methodology have specifically flagged that power dynamics — coercion, passivity, or participants simply going along to avoid conflict — can shape apparent group consensus in ways that look, on the transcript surface, indistinguishable from genuine agreement. Coding interaction patterns alongside content is the main defense against mistaking one for the other.

Reliability and validation for group data

The reliability checks used for interview coding — a second coder, percent agreement or Cohen's Kappa on a coded subset, disagreement logs — still apply and should still be run. Two additions matter specifically for group data:

Code a full transcript, not a fragment, for the reliability check. Because interaction context matters (a comment's meaning can depend on what was said immediately before it), pulling isolated excerpts for a second coder to check — a common shortcut for interview reliability checks — is less reliable for focus group data than having the second coder work through at least one complete session transcript.
Check reliability on interaction codes separately from content codes. Agreement/dissent/shift codes are often harder to apply consistently between coders than straightforward content codes, since they require judgment calls about tone and context. Report reliability figures for both code types rather than one blended number that could hide a real gap in either.

Common mistakes when moving from interview to focus group analysis

Treating the transcript as N stapled-together interviews. This discards the interaction data and defeats the purpose of running a focus group instead of individual interviews in the first place.
Losing speaker attribution during transcript cleanup. Once a transcript has been "cleaned" into an undifferentiated block of dialogue, individual-level analysis becomes impossible to recover without re-listening to the recording.
Averaging away disagreement. Reporting "participants generally felt X" when the group was actually split, or converged only after visible social pressure, overstates the finding's strength.
Assuming one group's dynamics generalize to the next. Group composition (who happens to be assertive, who knows whom outside the session) shapes dynamics session to session; a pattern seen in one group is a hypothesis for the next group, not a confirmed finding until it recurs.
Checking saturation only at the study level. A study can reach saturation on some discussion topics well before others depending on how many groups actually engaged deeply with each one — check topic by topic, not only "have we run enough groups overall."

How YumiLM fits into a focus group workflow

The most time-consuming part of preparing a focus group transcript for analysis is rarely the coding itself — it's getting from raw audio to a clean, speaker-tagged, timestamped document you can actually start coding against. YumiLM handles the first part of that: upload a recorded focus group session (or paste a YouTube link, or record live), and YumiLM returns a full transcript with timestamps preserved throughout, plus an Insight Guide that summarizes the session's premise, key points, and conclusion for a fast first orientation before you dive into formal coding.

What YumiLM does not do is separate or label who is speaking. As covered above, that's a deliberate limitation worth planning around rather than discovering mid-analysis: for any multi-participant recording, budget time for a manual speaker-tagging pass using the timestamped transcript alongside a moderator's session notes or the original audio, before coding begins. For studies where speaker-level attribution is essential to the analysis — which is most focus group studies — this tagging pass is not optional cleanup; treat it as the first real step of analysis, not preparation you can skip.

Once speaker tags are in place, YumiLM's translation and PDF export can help multi-site or multilingual studies keep a consistent transcript format across sessions, and the SRT subtitle export is useful if a session recording itself needs to be shared with co-researchers or reviewed alongside the video.

Start with a short focus group recording at YumiLM to see the timestamped transcript and Insight Guide format before committing a full multi-session study to the workflow, or read the full transcription and export guide to confirm the output formats fit your analysis software.