Thematic analysis coding - how to code qualitative data using Braun & Clarke’s Reflexive Thematic Analysis (RTA)
Okay, you’re doing Braun and Clarke’s reflexive thematic analysis and the whole coding thing is totally boggling your brain. What is coding? How do you know you’re doing it “right”? How do you know when you’ve coded enough or when you’ve done too much coding? What things should you look out for so you don’t end up having to throw it all in the bin and start over? You might have done that already, don’t worry – that’s fine – most people do.
If you’re new here, I’m Dr. Elizabeth Yardley, and I help PhD students navigate the choppy waters of qualitative research.
Braun and Clarke’s reflexive thematic analysis is a very common analytical technique It’s great, it’s super helpful, but there are some common hurdles that can be super frustrating.
Coding is one of them – that’s what we’re covering in this blog. If you want more of a general introduction to Braun and Clarke, please check out this blogpost.
Before we get into it make sure you download my free Starter Kit for the Braun and Clarke method. It does what it says on the cover, it helps you get started with this method. There are some super simple, straightforward steps and examples in it, it’s totally free, it will help you set off on the right track so go check it out - click here to get yours.
Braun and Clarke Starter Kit - Free PDF guide. CLICK HERE to get yours.
Now, let’s get into i!
What Is Coding?
So, what exactly is coding? In simple terms, it’s the process of tagging your data with labels - what we call “codes” - that capture something interesting or meaningful. Think of it like putting Post-it notes in a book to mark your favourite quotes.
Coding is the process of tagging your data with labels - what we call “codes” - that capture something interesting or meaningful.
But here’s the important thing: a code isn’t the whole story; it’s just a snippet, like catching a glimpse of the big picture. For example, let’s say you’ve got this quote from a participant:
“I felt ignored during meetings.”
You might code that as “exclusion,” or “lack of communication.” See how that works? It’s about capturing the essence of what’s being said.
Let’s take a look at another couple of examples.
Quote:
"The training sessions were really confusing, and I didn’t know who to ask for help."
Possible Codes:
“unclear guidance”
“lack of support”
“confusion”
Here, the codes focus on different aspects of the participant’s experience. You’re not summarising their whole statement - just tagging key points like confusion and lack of support that stand out as meaningful.
One more example…
Quote:
"I really appreciated how my manager checked in with me regularly. It made me feel valued as part of the team."
Possible Codes:
“regular check-ins”
“feeling valued”
“team inclusion”
This time, the codes capture positive aspects of the participant’s experience.
Coding isn’t just about identifying problems - it’s also about tagging strengths, patterns, and insights that matter to your research question.
What to do with your codes - refining
The codes you come up with during your first go might not be the ones you finish with. And that’s absolutely fine - it’s all part of the process!
Think of coding as a first draft, not the final masterpiece. As you go back through your data, you’ll start to notice overlaps between codes, areas where they could be clearer, or places where they just don’t quite fit anymore. That’s totally normal and to be expected.
Let’s look at an example of how codes can change:
Original Quote:
"The training sessions were really confusing, and I didn’t know who to ask for help."
Initial Codes:
“unclear guidance”
“lack of support”
“confusion”
Now, as you go deeper into your analysis and start looking at more data, you might realise that “unclear guidance” and “confusion” are really describing the same underlying issue. So you decide to merge them into a single code like “lack of clarity.”
But then, later on, you notice that “lack of support” keeps coming up alongside this. After thinking it through, you decide to split “lack of support” into two separate codes:
“lack of technical support”
“lack of emotional support.”
By refining your codes in this way, you’re getting closer to understanding the nuances in your data. This might feel messy at first, but it’s actually a sign that you’re peeling back the layers to uncover more precise and meaningful insights.
Be okay with letting your codes evolve as your understanding deepens. Sometimes, a code you loved at first might feel redundant later, or you might realise two codes are really saying the same thing. That’s not a mistake - it’s progress.
What I said earlier about feeling like you want to throw it all in the bin and start over? There will absolutely be moments like that! When that happens, step back and remind yourself: refining your codes is a sign that you’re digging deeper into your data and getting closer to the real insights.
A helpful tip? If you’re overwhelmed by the changes, keep a version of your earlier coding - it’s like a safety net so you can experiment without fear. You haven’t thrown it all away. And remember, this refining process is where the magic happens, embrace the mess!
Common Pitfalls
Overcoding
You don’t need a code for every single word. There may be chunks of data that aren’t coded. That’s fine. Focus on what’s relevant to your research. You’re done when your codes cover everything meaningful in your data and you’re not spotting new patterns anymore. It’s a bit of a gut feeling - but it comes with practice! A lot of getting good at coding is knowing what NOT to code. So know you don’t need to code it all, okay?
Vague codes
Avoid things like “miscellaneous” or “other.” Or “not sure”. Call it SOMETHING, okay? You can always change it later. Be specific, even if it’s messy and clumsy at first.
Confusing codes with themes
Remember, codes are not themes. Themes come later when you step back and look at the bigger picture. A code is a snippet - it’s like a puzzle piece. A theme is the picture you see once the puzzle comes together.
Not taking breaks
Coding marathons lead to burnout. I have memories of doing my coding in the small hours of the morning and spilling coffee and food all over my desk. And then crying for literal hours. I can laugh now but it was not funny at the time so if that’s you, I feel you! So, let your brain breathe – go do something else. The number of times I made HUGE breakthroughs and had lightbulb moments on a walk or doing laundry or whatever. Coding is heavy stuff, you can’t just keep going and going for hours and hours, so, give yourself a break, set a timer if you need to. Code for 45 minutes, break for 15, whatever.
Not checking out my FREE Braun and Clarke Thematic Analysis Starter Kit!
It’s helpful it really is! Grab it now and start making progress today.
Braun and Clarke Starter Kit - click here to get yours.