Thematic analysis in six stepsছয় ধাপে থিম্যাটিক বিশ্লেষণ

What thematic analysis is doing

Thematic analysis finds patterns of meaning across qualitative data and reports them as themes. Braun and Clarke's version, taught most widely and the one this lesson follows, treats the analyst as an active participant in that finding rather than a neutral extractor of what was already there. Two people can code the same interviews well and come back with different themes, because a theme is an argument about what matters, built from codes, and an argument has an author. That is not a weakness to apologise for; it is why the write up has to show the reasoning and not only the result. The six phases are not a straight line walked once: you will return to phase two after phase four shows a code that should have caught something it missed, which Braun and Clarke call recursive.

Code against theme

A code is a short label on a passage: a word or phrase capturing one thing it is doing or saying. A theme is bigger: a pattern recurring across many codes, organised around a shared idea, and a claim you are making about the data rather than a tag found in it. Coding is close and mechanical, done first; theming is the interpretive step after, built out of the codes.

The commonest mistake is calling a topic a theme. "Money" is a topic: it names a subject people talked about and says nothing about what they said. "Money runs out before the harvest does" is closer to a theme, because it makes a claim the codes underneath can support or contradict. A theme should be arguable, not merely present.

The six phases

1. Familiarising yourself with the data. Read the whole transcript, or listen to the recording, before coding a single line. Note first impressions as you go, not codes yet.
2. Generating initial codes. Work through the data, giving a short label to anything interesting or relevant. Code inclusively: a passage can carry more than one code, and a pattern never labelled cannot be found again.
3. Searching for themes. Gather the codes into candidate groups by sorting: lay them out and ask which point at the same underlying idea. A candidate theme here is a working hypothesis, and it is normal for half to fall apart at the next step.
4. Reviewing themes. Check each candidate two ways: against its own coded extracts, asking whether they cohere, and against the whole data set, asking whether the theme fits it as a whole or only the passages pulled out. A theme that survives both is kept, refined, split, or merged; one that survives neither is dropped.
5. Defining and naming themes. Write, for each surviving theme, what it is, what it is not, and how it relates to the others. A theme you cannot define in two or three sentences is still a bundle of codes waiting for its argument.
6. Writing up. Choose extracts that carry the theme clearly, and write the analytic narrative around them rather than letting quotations stand in for it. Every extract should show the theme, not merely mention the topic.

Inductive against deductive

Inductive coding starts from the data with no framework decided in advance: codes are whatever the transcripts call for, and themes are built from those codes alone. Deductive coding starts from an existing framework, a theory or set of categories from the literature, and asks whether the data support, extend or contradict it. Most real projects sit between the two. Say plainly which way you leaned, because a reader needs to know whether they are reading what the data suggested or what the framework was looking for.

The reflexive stance

Reflexive thematic analysis does not treat researcher judgement as an error to be minimised: it treats it as the instrument doing the analysis, and asks you to be explicit about it. A reflexive note kept alongside the coding, a few lines after each transcript on what you noticed reacting to and why you changed your mind on a passage, lets a reader, and later you, tell a defensible interpretation from one you have simply gotten used to. This is also why two coders reaching different themes is not by itself a problem: Braun and Clarke say inter-rater reliability, from a tradition built for counting, is the wrong test here. Check instead whether the extracts support the claim, and whether you have said honestly where your own position shaped the reading.

Saturation, said honestly

Saturation is the point where further transcripts stop changing your account: new interviews confirm the themes you already have rather than adding new ones. It is a judgement from what the last few transcripts actually contributed, not a sample size fixed before fieldwork starts. A proposal stating "saturation will be reached at fifteen interviews" promises a number the data have not been allowed to decide. Say instead what was watched for: that the final few transcripts were coded to check whether they introduced anything the existing themes could not absorb, a claim checkable against your own coding record.

Where it goes wrong

• A theme that is really a topic. If it cannot be written as a sentence somebody could disagree with, it is not yet a theme.
• Themes drawn from the questions asked rather than the answers given. Every theme should trace back to codes, every code to an extract.
• Coding once and treating it as final, skipping the review against the whole data set.
• Claiming saturation as a number decided before fieldwork rather than a judgement from what later transcripts contributed.
• A write up that is mostly quotations with no argument connecting them.
• No reflexive note, leaving a reader no way to weigh how much of the theme is the data and how much is the reader of it.

Anonymise before an extract leaves your files. It travels into a codebook, an appendix, sometimes a published article, and should never carry a name identifying who said it.

The field room's codebook and coding are where this happens on real transcripts: initial codes go in one pass, candidate themes are grouped and reviewed in the next, and each is defined and named before it is written up.