I Automated the Most Time-Consuming Part of Qualitative Research

A practical guide to automating qualitative data analysis with Claude Code

If you’ve ever sat with a stack of interview transcripts or long documents, a blank spreadsheet, and the sinking feeling that you’re about to spend the next two weeks reading and re-reading the same paragraphs, thematic coding needs no introduction. For everyone else, here’s why it matters and why I built a tool to handle it.

What thematic coding actually is

When you run interviews, deliver group exercises, or collect open-ended survey responses, you end up with a pile of unstructured text. People’s words, in all their messiness. The same applies when you do long literature reviews, with lots of text that needs making sense of.

Thematic coding is the systematic process of reading through that text, identifying meaningful segments, and labelling them with codes - short descriptive tags that capture what each text extract is about.

Do that across enough documents, and patterns emerge. Codes cluster into themes, which in turn are the foundation to build a story.

Thematic coding is fundamental to any serious qualitative work, and it underpins everything from academic research to policy evaluation to consulting projects where you need to make sense of what multiple people have said (as opposed to what the project sponsor thinks they said).

The standard process could look something like this:

📖 You read a transcript.

✍🏼 You highlight a passage where a participant talks about feeling unsupported by their manager.

👨🏽‍💻 You assign the code “Lack of managerial support.”

🖱️ You scroll down to the next bit of the conversation and keep coding.

📑 Three transcripts later, someone else describes the same thing in different words, and you apply the same code.

🗂️ Eventually you might notice that “Lack of managerial support” and “Insufficient training” and “No feedback mechanisms” all cluster under a broader theme of “Organisational culture gaps,” so you group them all together under this ‘parent’ code.

🔄 And so on and so forth…

Why it’s painful

If you're a consultant who regularly processes stakeholder interviews, or a (market) researcher managing qualitative data across multiple studies, you'll recognise this problem.

The intellectual part of thematic coding, meaning deciding what matters, seeing connections, and building an argument, is genuinely skilled work. The mechanical part that precedes it - reading every paragraph, typing out codes, copying verbatim quotes into a spreadsheet, keeping your codebook consistent - is often more tedious than it is difficult. Most importantly, it's very time-consuming, and it scales non-linearly with the size of your dataset.

If you’re coding five or six interviews, it’s perfectly manageable to do manually. You can hold the full codebook in your head, remember what you’ve already seen, and spot when a new passage echoes something from an earlier transcript. At that scale, a spreadsheet and a good memory will serve you well. This is especially true if you have done the research yourself, hearing findings first-hand from participants.

But qualitative projects don’t always stay small. Twenty interviews. Forty consultation responses. A hundred pages of open-ended survey comments. At that volume, the cognitive challenge changes in kind. We can no longer reliably remember whether we have already created a code for what we are reading, or whether the code we created for document 4 means the same thing as the similar-sounding one we created for document 19. This is when codebook drift sets in, and we can say goodbye to consistency. Experts can still keep things under control, but novices will struggle, which is where the analysis becomes harder to defend.

Tools like NVivo, ATLAS.ti, and MAXQDA exist to help. They give you a place to organise your codes, highlight text, and retrieve all the segments you’ve tagged with a particular theme - this is much better than using Excel manually, though there’s a price tag attached to the privilege. These tools are (very!) good at what they do, and for large-scale research projects they are essential. But they don’t reduce the core labour in coding. You still read every paragraph yourself and assign every code manually. Most of these tools now include AI functionality, which is nice - but I find that this is not sufficiently transparent and flexible for my own use.

So I created a custom approach that I can hold to account. This was developed to deal with large analyses where you need depth and a track record - but it works just as well for smaller projects where most of my work was manual.

---

Read more about responsible AI use in this article I wrote with Cécile:

AI Wrote It. You Signed It. Now What?

---

What I built

The tool I built is a Claude Code skill - a structured set of instructions that Claude Code follows when you invoke it.

The last time I used it, what would normally have been several days of manual coding took an afternoon of review. Here's what it does:

📂 It takes a folder of documents (interview transcripts, consultation responses, open-ended survey data - anything text-based).

🏷️ It codes each document systematically against a growing codebook.

📋 It produces three outputs: a coded evidence table (CSV), a thematic codebook, and a processing log.

The result is a verified, structured evidence base that's ready for synthesis, with every quote traceable back to its source document.

What makes it interesting is the architecture. I’ll start with an overview of the process, and then guide you through the full setup using Claude Code.