Qualitative Coding Without the Chaos: How to Analyze FGD and KII Data Without Losing Your Mind

You've just wrapped up a round of Focus Group Discussions and Key Informant Interviews. You have ten transcripts, a stack of field notes, and the quiet dread of knowing you now have to make sense of all of it. If that sounds familiar, you're not alone.

Qualitative analysis is one of the most underestimated tasks in MEL work. It's not hard because the concepts are obscure. It's hard because it's genuinely messy, iterative, and judgment-intensive. There's no formula that spits out findings. But there is a process that keeps you grounded, and that's what I want to walk you through here.

What "Coding" Actually Means (And Why It Matters)

At its core, coding is just a labeling exercise. You read through your data, identify meaningful segments (a phrase, a sentence, a paragraph), and assign a short label to describe what that segment is about. According to Delve's qualitative research guide, coding "allows you to interpret, organize, and structure your observations and interpretations into meaningful theories" [1].

Think of codes as handles. They help you grab and group similar ideas across dozens of pages of text so you're not holding everything in your head at once.

📝 Note: Coding is not the same as analysis. It's the preparation for analysis. The actual analytical work happens when you start asking why certain codes cluster together and what that means for your research questions.

Two Approaches: Deductive vs. Inductive

Before you start labeling anything, you need to decide your direction of travel.

Deductive coding means you come in with a pre-defined framework: your logframe outcomes, your evaluation questions, your theory of change. You're essentially looking for evidence that speaks to what you already set out to measure. This is common in monitoring work and structured evaluations where the questions are fixed in advance.

Inductive coding means you let the data lead. You read without a predetermined lens and let patterns emerge. This is more common in exploratory assessments, needs analyses, or when you suspect the most interesting findings weren't in your original questions (which, honestly, is often the case in humanitarian contexts).

Most real MEL work uses a hybrid. You start with your evaluation questions as anchors (deductive), but you stay open to unexpected themes along the way (inductive). Grad Coach's qualitative coding tutorial describes this combination well: start with what you need to know, but don't close the door on what participants are actually telling you [2].

The Four-Stage Process I Actually Use

Stage 1: Read Before You Code

This sounds obvious but is routinely skipped. Before you assign a single code, read through all your transcripts once, just to absorb them. Note anything that surprises you. Jot rough impressions in the margin. This "immersion" pass prevents you from coding too narrowly and missing things that only become significant once you've seen the full picture.

Stage 2: Initial (Open) Coding

Now go back and label segments. Keep codes close to the language of the data at this stage. Grad Coach's tutorial highlights a technique called in vivo coding: using the participant's own words as the code label [2]. This is particularly powerful in FGDs and KIIs because it preserves the voice of the community and reduces the risk of projecting your own interpretations too early.

You will end up with a lot of codes. That's fine. A hundred codes from a ten-transcript dataset is not unusual. The goal here is comprehensiveness, not elegance.

⚠️ Warning: Avoid collapsing codes too early. Merging "lack of information" and "poor communication from health workers" into one code at this stage loses a distinction that might matter a great deal when you're interpreting findings.

Stage 3: Focused Coding and Theme Development

This is where the real work happens. You now look across your initial codes and ask: which ones belong together? What's the bigger idea they're all pointing toward?

This is the reduction problem that most people struggle with. A useful video on this exact challenge describes the process as moving from granular codes to "categories" and then to "themes," with each level of abstraction requiring a deliberate check: does this grouping still represent what the data actually says [3]?

A simple way to do this is a three-column table:

Doing this in a spreadsheet (or even on paper with sticky notes) keeps you honest about what you're actually merging and why.

Stage 4: Connect Themes to Your Research Questions

The final step, and the one that turns coding into analysis, is mapping your themes back to what you set out to answer. Quirkos puts this simply: "figure out how [themes] connect [to your questions] by asking which codes and themes correspond to your questions" [4].

This is where your analytic memo becomes essential. For each theme, write two to four sentences explaining: what the theme is, what data supports it, and what it means in the context of the program or evaluation question. This is your analysis, not just your description.

💡 Tip: If a theme doesn't connect to any of your research questions and isn't significant enough to add a new finding, it's okay to set it aside. Not every code needs to appear in the final report.

A Note on FGDs Specifically

FGD data has a particular complexity that KII data doesn't: group dynamics. What someone says in a group is shaped by who else is in the room. When you're coding FGD transcripts, it's worth flagging not just what was said but how it was said. Was it a dominant voice? Was it challenged or affirmed by others? Was something said only after the facilitator probed?

ResearchGate discussions among practitioners have flagged this dimension repeatedly: FGD analysis should account for the social construction of the conversation, not just the content of individual statements [5]. That doesn't mean over-complicating your coding scheme. It means noting context where it matters.

Practical Tips to Keep the Process Manageable

• Code in short sessions. Two focused hours beats eight distracted ones. Qualitative coding requires sustained interpretive attention.
• Keep a code log. Write a one-line definition for every code you create. When you revisit two weeks later, you'll thank yourself.
• Code one transcript fully before touching the others. This lets you stabilize your initial code list before applying it across the dataset.
• Discuss disputed codes with a colleague. Having a second person code a subset of the same transcript and then comparing is a simple credibility check.
• Don't wait for perfection to start writing. Analytic memos written during the coding process are often better than memos written after it, because your thinking is live.

From Codes to a Report That Actually Says Something

The difference between a mediocre qualitative findings section and a good one is not the number of codes. It's the quality of the interpretive leap from "here's what participants said" to "here's what this means for the program." That leap requires you to have stayed close to the data throughout, resisted over-generalizing, and kept your research questions visible at every stage.

If you're managing a baseline, endline, or rapid assessment right now and want help structuring your analysis approach or turning coded data into a clean findings report, that's exactly the kind of work I do. Come work with me at vera.ignex.io.

Qualitative data is rich. It's also unruly. But with a clear process, it stops being something you dread and starts being one of the most insightful parts of the whole evaluation cycle.

Follow Vera for more on MEL & project management: LinkedIn · Instagram · Facebook · X