A step-by-step guide to qualitative coding for insights teams (with a worked example)

Qualitative coding is a critical part of research, but it’s also one that’s notoriously difficult. Researchers often learn it on the job, so two people coding the same data can label responses differently and reach different conclusions. This makes findings harder to compare and leaves teams struggling to show stakeholders how they reached them.

In this article, you’ll learn when to use content analysis or thematic analysis, follow a seven-step coding process using a worked example, and see how to code video interviews, use AI and avoid common mistakes. Insights or market research teams will come away with a process they can follow to produce consistent findings backed by participants’ own words.

What is qualitative coding?

Qualitative coding is where you assign labels, or codes, to segments of qualitative data such as focus group or interview transcripts, so similar concepts can be grouped together.

With qualitative data coding, each code usually describes a recurring idea in the data. Say a researcher is coding interview transcripts from a product test for a new instant coffee that dissolves in cold water. The researcher might use the code “taste concerns” for any negative comment about the coffee’s flavor. They might use a second code, “convenience”, for any comment about the product saving time or effort.

Consistent qualitative research coding helps ensure that different researchers interpret the same responses in the same way. Without it, two analysts might assign different codes to the same comment, producing different results from the same interviews. This makes findings harder to compare and defend to stakeholders.

For example, when coding interviews about the new instant coffee, one researcher might label “It leaves a weird powdery taste” as a taste concern, while another codes it as a texture issue. If they apply these codes inconsistently across interviews, they could reach different conclusions about what puts consumers off the product.

When to use content analysis vs thematic analysis

Coding for qualitative data is the first step in two of the most common analysis methods: content analysis and thematic analysis.

Both start with labeling the data, but they use those labels differently. Content analysis counts how often each code appears, while thematic analysis groups codes into broader themes that explain what participants mean.

The right qualitative data analysis strategy depends on what your study needs to answer and what your stakeholders expect to see at the end. Here’s how the two compare:

It’s quite common to apply multiple coding schemes to the same data. Many teams run thematic analysis on early interviews to find the themes, then use content analysis on a larger round to measure how widespread each one is.

See it in action: how AI-moderated video interviews actually work.

The qualitative coding process: a 7-step workflow (with a worked example)

Having a set framework to follow for the process of qualitative coding makes it easier for different researchers to code the same way and surfaces disagreements while they’re still easy to fix.

Here are 7 steps to code your data and how they would work using the instant coffee test example (participants tried a new instant coffee that dissolves in cold water, then talked through their reactions).

Step 1: Prepare your data for analysis

Getting all your data into the same format at the very start helps you stay consistent throughout the process and makes scaling easier. For interviews, you would:

• Check the transcript against the recording, especially names and moments where people talk over each other. In the coffee study, make sure the product name is spelled the same way in every transcript.

• Label speakers consistently. For example, Interviewer and P07.

• Add timestamps so anyone can find a moment in the recording. If P07 says the coffee is bitter at 12:41, a stakeholder can jump straight to that moment.

• Note visible moments the transcript misses in square brackets. If a participant stirs the glass and holds it up to check whether the granules have dissolved, add [stirs, holds glass up to the light].

• Name files the same way across the study. For example, “coffee-test_US_P07”.

Step 2: Familiarize yourself with the dataset

Getting familiar with the data before you start coding helps you avoid introducing bias and helps your codebook reflect what participants genuinely talked about.

Read or watch a sample of interviews and note repeated comments, unexpected reactions, and questions participants seem to struggle with. In the coffee study, you might notice that several participants mention adding sugar or syrup, while others hesitate when asked whether they'd buy the product.

Turn these observations into questions to investigate during coding. Are participants finding the coffee too bitter to drink plain? Does the need to add something affect their willingness to buy it? Treat these as ideas to test against the full dataset.

Step 3: Develop your codebook

Draft a first list of codes from your research questions and the notes from Step 2. Keep it short to begin with, since it’s easier to add codes later than to merge overlapping ones. For each code, write:

• Definition: What the code means, in one sentence.

• Include: The kinds of comments that count.

• Exclude: Similar comments that don’t count, and which code they go under instead.

• Example: A real quote from the data.

For example, if you drafted the code “adds sweetener” in the coffee example, you might write:

• Definition: The participant says they’d add something to sweeten the coffee before drinking it.

• Include: Any comment where the participant says they would or would want to add sugar, syrup, flavor drops, or sweetened milk.

• Exclude: Comments that the coffee isn’t sweet enough, but the participant doesn’t say they’d add anything. For example, “it could be a bit sweeter” goes under “taste concerns.”

• Example: “I’d need a pump of caramel in it, honestly.”

Step 4: Code your first pass

The goal at this stage is to see where the draft codebook works and where it doesn’t. Have two researchers code the same two or three transcripts separately. Code only excerpts that relate to your research questions, and keep what participants said separate from what you observed. If an excerpt doesn’t fit any code, write a short note on it instead of forcing it into the closest one.

Here’s an example excerpt from the coffee study:

Interviewer: How did it taste?

P07: Honestly, it’s quite bitter. I’d want to put something in it.

Interviewer: Like what?

P07: Sugar, or one of those syrups. Then it’d be fine.

Interviewer: Would you buy it?

P07: Yeah... probably. [pauses for three seconds, looks at the pack] If it was on offer.

Both researchers code “it’s quite bitter” as “bitterness” and “sugar, or one of those syrups” as “adds sweetener”, so those definitions are doing their job.

But “if it was on offer” splits them. The codebook has codes for both price sensitivity and purchase intent, and the comment could fit either, so one researcher picks each.

Step 5: Refine codes and resolve disagreements

Get both researchers together to go through every excerpt they coded differently. For each one, read the full response again and check it against the codebook definitions to work out why you disagreed. Usually it’s because a definition doesn’t cover that kind of comment.

You can fix that in one of two ways. If the comment is close to an existing code, tighten that code’s definition so it clearly includes or excludes comments like it. If the same kind of comment keeps coming up and doesn’t fit any code, add a new one.

Either way, go back through the transcripts you’ve already coded and recode any similar responses, then record the decision, the revised definition, and the reason for the change. That gives everyone the same rule to follow for the remaining interviews.

In the coffee study, P07 answers “Would you buy it?” with “Yeah... probably. If it was on offer.” That’s an answer about buying, which fits purchase intent, but it depends on price, which fits price sensitivity.

Neither definition covers buying only under a certain condition. If this is a one-off, the researchers could add “would buy only at a lower price” to the include list for price sensitivity. If other participants also say they’d buy it only with a discount or in a different flavor, a new code like conditional purchase makes more sense.

Step 6: Group codes into themes

Look for codes that keep appearing together, in the same interviews or from the same participants. When you find a group, pull up the excerpts behind those codes and read them side by side. Then try to write one sentence that explains what connects them. That sentence is your draft theme.

Before you settle on it, check that it explains every excerpt in the group. If some don’t fit, the theme may be too broad, or those excerpts may belong to a different theme. Note which codes and excerpts each theme draws on, so anyone reviewing it can see how you got there.

In the coffee study, participants coded for bitterness were often also coded for adding sweetener. Reading those excerpts together suggests a theme: the coffee is too bitter for many participants to enjoy without adding something. But if some participants say they’d add syrup simply because they prefer flavored coffee, bitterness doesn’t explain their responses, and they belong in a separate theme.

Step 7: Validate themes against source data

For each theme, go back to the transcripts and check three things:

• Supporting evidence: Do participants’ actual words back up your interpretation, or are you reading more into them than they said?

• Contradicting evidence: Did anyone say the opposite? If so, account for those responses in the finding instead of leaving them out.

• Scope: Does the theme apply across many participants or only a small group? Say so in the report, so stakeholders know how far the finding goes.

Then write the theme up as a finding, with the quotes and timestamps behind it, so stakeholders can check it against the original interviews.

In the coffee study, that means checking that the participants who mention adding sugar actually link it to the bitterness, and looking for anyone who enjoyed the coffee plain. The finding might look like this:

Finding: Several participants who found the coffee too bitter said they’d add sugar or syrup before drinking it. Testing a sweeter or flavored version would show whether that improves its appeal.

• P07 [12:41]: “It’s quite bitter. I’d want to put something in it.”

• P12 [08:15]: “It’s a bit harsh on its own. With some vanilla syrup, I’d drink it.”

• P19 [10:02]: “It needs sugar. Black, it’s too harsh.”

These steps will help you work through most qualitative textual data. However, if you have video interviews, you can take your coding one step further.

How to code qualitative video data

Video interviews are a form of multimodal research: They tell you how people delivered responses and their facial expressions alongside what they said, giving you more information to code. Here are some guidelines to follow when coding video data:

• Only code nonverbal signals when they change the meaning: If a participant says they didn’t like the product and wouldn’t buy it, the transcript tells you everything you need. If they say “yeah, I’d buy it” in a flat voice while looking away, that’s worth coding, because it changes how you read the answer.

• Write down what you see and save interpretation for later. “Pauses for four seconds before answering” is an observation anyone can check, while “uncomfortable” is an interpretation two researchers could easily disagree on. Leave interpretation until you’re building themes.

• Add timestamps to your observations. That way, anyone reviewing a finding can watch the moment for themselves.

On Conveo, analysis covers speech, tone, and facial cues across every session, and each theme links to the clip behind it.

Many qualitative research software programs that offer video also have AI features to help with qualitative analysis. Before you use them, it’s important to know their limits.

Where AI fits in qualitative coding

AI can be a useful tool for qualitative researchers to take on some of the slow, repetitive parts of manual coding, like applying a codebook consistently across hundreds of responses. Tools built for AI thematic analysis can also suggest possible themes for the researcher to review.

However, a human researcher should still get the final say in how each response is coded and which themes make it into the report. That includes writing the codebook in the first place and judging comments that could be read more than one way. Text-only AI can't reliably tell whether 'it's fine' is genuine approval or a polite brush-off. Tone and facial cues in video help, but a researcher should still make that call.

Before you use AI-coded data, check it the same way you’d check a colleague’s work. Read the excerpt behind each code to make sure it fits what the participant said, and look out for codes in the wrong place, like “adds sweetener” applied to “it could be a bit sweeter,” which the codebook puts under taste concerns.

Keep a note of what you correct. If you find yourself making the same fix again and again, the code definition probably needs tightening.

3 common coding pitfalls and how to avoid them

Even with a framework, coding in qualitative research is inherently subjective, which can lead to a few common errors. Here’s what to look out for and how to fix it so a mistake doesn’t impact the validity of your findings.

1. Overcoding: tagging everything means tagging nothing

When you’re worried about missing something, it’s easy to code every sentence in a transcript. But participants say a lot that doesn’t relate to what you’re studying. In the instant coffee test, someone might talk about their commute, their office kitchen, and what they had for breakfast before they get to the product. If all of that gets a code, the themes you actually need end up buried under hundreds of labels that don’t answer anything.

Before you code an excerpt, check whether it relates to one of your research questions or shows how participants behave. If it does neither, leave it uncoded. You can always go back to it if a new question comes up later.

2. Vague codes: when definitions allow multiple interpretations

Codes can sometimes seem self-explanatory, but two people might apply them in completely different ways, leading to inconsistent findings. In the coffee example, one researcher might apply the code “temperature concerns” when a participant says the coffee didn’t fully dissolve in cold water, while another also applies it when they say it tasted flat served cold.

The fix is to define each code with what counts and what doesn’t, so every team member is clear on when it applies.

3. Confusing codes with themes: labels aren’t conclusions

Codes can help you develop themes, but they’re two different things:

• A code describes a specific response. “Bitterness” labels any comment where a participant disliked the coffee’s bitterness.

• A theme comes from looking at how codes connect. If participants who mentioned bitterness also said they’d add sugar or flavor drops before drinking it, that might point to a theme like “people don’t want to drink it plain, so a sweetened or flavored version could appeal more.”

The mistake is reporting a code as if it were a finding. “Twelve participants mentioned bitterness” tells stakeholders what came up and leaves them to work out what it means for the product.

Before anything goes into a report, check whether each point explains something or just labels it. If the team couldn’t act on it, it’s still a code, and you need to look at how it connects to other codes before it becomes a theme.

Keep your qualitative coding consistent with Conveo

It takes time to build a codebook that different researchers apply the same way. Keeping it consistent gets harder as the number of interviews grows and more people get involved in the analysis.

Conveo’s Consumer Understanding Infrastructure is built to take on that load. It runs AI-moderated video and voice interviews with consumers and does a first pass of the analysis, which researchers can inspect and correct before anything reaches a report. Here’s how it helps:

• Apply one codebook across every interview. Researchers add their codes as facets, and Conveo extracts them across every interview in the study and in later waves, so every analyst works from the same list. Researchers can inspect and correct the coding, and Talk to Your Data surfaces topics the code list didn't anticipate, which can become a new facet in one click.

• Build on what you already know. Recurring themes and facets are recognized across studies in a searchable insight library, so the next wave starts from what earlier ones established instead of a blank codebook. For questions that keep coming up, Conveo StoryLines runs interviews in waves, for example, monthly, and compares each wave against earlier ones to surface changes and emerging themes.

• Check any finding against the evidence. Every theme links back to the participants behind it, with the video clip and quote, so anyone reviewing the results can see where a finding came from.

• Meet enterprise security requirements. Conveo is SOC 2 Type II and ISO 27001:2022 certified, GDPR compliant, with EU hosting in Belgium.

For a Head of Insights, traceable findings make a recommendation harder to dismiss in a leadership review, because anyone who questions it can go straight to the interviews behind it.

More than 400 enterprises, including Google, Unilever, AB InBev and Canva, use Conveo to understand their consumers.