Inductive Thematic Analysis: From Codes to Themes

Inductive thematic analysis starts with close reading of your sources. You write codes, or short labels, for key passages. Then you build themes that help answer your question. Check each theme against the source text and revise it as you learn more.

A list of frequent topics is not yet a set of themes.

Imagine an interviewee says, “I waited for a reply because I did not know who could approve the request.” You might code that passage as unclear approval route. A second interviewee knew the route but waited because the approver was away. The two accounts may point to different parts of a process.

Keep that complication in view before naming a theme.

In Braun and Clarke’s account of reflexive thematic analysis, themes are made through the researcher’s engagement with data. They are not objects that appear on their own.

The method below follows that interpretive position. Other schools of thematic analysis make different choices about coding and agreement.

What makes the analysis inductive?

An inductive approach lets the words and context in the sources shape your first codes. You do not force each passage into a fixed list of labels. Your question still guides what you look for, and your past work affects what you notice. Explain both in your report. For a first pass that ties each label to its source, see the open coding guide.

A code is a short label for something in a passage. A theme is an account of a meaningful pattern across the material in relation to the research question. “Waiting” is a topic. “Staff waited because the approval route was unclear” is a more specific candidate theme that the source passages can challenge.

Induction is not a promise of neutrality. If the research question asks about obstacles to a service, the analyst is already reading for obstacles. Record that starting point and stay open to accounts that shift it.

Braun and Clarke’s interview describes reflexive analysis as time spent making connections and asking what the data mean.

Inductive and deductive approaches

The difference is where the first ideas come from. Both paths use evidence. Your question and prior knowledge shape each path.

Table 1: A study can move between these paths. Say how you coded instead of claiming the work was purely inductive. Abductive coding takes another path: a surprise in the data prompts you to test more than one explanation.

If the study needs a case-by-theme table based on shared questions, see the framework analysis guide. It shows how to chart each case and keep the source context.

Delve’s method comparison explains where each path starts. You still need to explain your own choices.

Braun and Clarke compare reflexive analysis with other pattern-based approaches. If several reviewers must use one fixed code list, describe that design on its own terms. An agreement score does not test the quality of a reflexive theme.

For a wider look at AI-assisted coding, see our qualitative coding guide. For interview sources, our AI interview analysis guide covers how to compare sources before you draw conclusions.

Code the source passages

Read the full interviews, notes, or open responses before extracting snippets. Write a short memo about the question, your expectations, and anything surprising. Then mark passages that seem relevant, keeping the speaker or source ID and the nearby context.

Make codes brief enough to compare but precise enough to return to the passage. “Approval was unclear” says more than “process.” One extract can carry more than one code. A useful coding record contains the source ID, passage location, code, and a note about why you chose it.

Read again after you code a few sources. A code that fit one interview may be too broad for another. Split it, revise it, or note why the cases differ.

The worked reflexive analysis in Quality & Quantity shows the back-and-forth between coding and building themes. The work does not follow one straight path.

Your dataset has a boundary. Say which interviews or notes were included, what was missing, and how they were produced. A short interviewer summary cannot support the same level of quotation or context as a full transcript.

If your sources include exit interviews, keep what the speaker said apart from the HR analyst’s view. Check permission before reuse.

Construct and challenge themes

Group codes around an idea that helps answer the question. Ask what the group says about the process or experience, rather than collecting all passages that share a noun. Write a one-sentence candidate theme, then return to every excerpt you placed under it. If you first need to sort observations in a group workshop, affinity mapping can make clusters visible. Those clusters still need researcher interpretation before they become themes.

Read the material that did not fit. Does another account narrow the claim? Does a passage belong to a different group? Does the theme describe the whole dataset, or only one subset? A strong revision may split a broad claim into two clearer ones.

Sometimes the best choice is to drop it.

Check each candidate at two levels: the passages gathered for it and the wider dataset. A theme should have a coherent central idea, a clear boundary from other themes, and an answer to why it matters for the question.

The CASRAI thematic-analysis guide distinguishes a meaningful theme from a topic summary.

Keep a brief decision memo when you revise the candidate. Record the earlier wording, the passage that complicated it, and what changed. Frequency can help you describe a reviewed set, but a common code is not automatically an important theme. A rare account may expose the limit of the main interpretation.

Build a code-to-theme evidence table

This fictional example illustrates the decision trail. The passage IDs and wording are invented, not participant quotations or Atlas test data. Suppose the question is: How do staff experience a request-approval process?

Table 2: The table does not prove the process failed for all staff. It shows how one analyst can narrow a claim without hiding an exception. In real work, link each row to an allowed source and keep the nearby text for review.

The practical test is whether you can explain the candidate theme in one sentence, show the passages that support it, and say what the contrary cases do to the claim. If you cannot, revise the grouping before drafting a finding.

For a deliberate search for contradictions and a documented revision decision, use the negative case analysis guide.

Check proposed themes in Atlas

Atlas can compare material already added to a project. Add only sources you are allowed to use, along with your own code notes. Select the transcripts or notes you want to compare and ask for evidence on both sides of a candidate theme. For example:

In these selected interview sources, find passages that support or complicate the proposed theme “unclear approval route.” Keep each source separate, give the cited passage and context, and flag cases where a different obstacle better explains the account. Do not decide the final theme for me.

Open each citation and read the source passage. Check who spoke, the question they answered, and any nearby text that changes the meaning. If the answer misses a relevant source, return to the files and refine the question. A missing result is not evidence that the passage does not exist.

Compare the chosen sources and open each cited passage. Save only the findings you checked, along with your own decision memo.

The screenshot shows an Atlas answer beside an open paper. It shows where you can check cited text. It does not show interview data or a finished theme analysis.

Atlas does not read every file for you. It has no native coding system and cannot promise to find each relevant passage. You decide if a theme makes sense. For tool-selection questions, see our AI thematic analysis guide.

Next steps for inductive thematic analysis

Braun and Clarke’s design paper asks researchers to explain their approach and its assumptions. Name the kind of theme analysis you used, your question, and your sources. Show how you read the sources, wrote codes, formed possible themes, checked opposing cases, and revised your claims. Say how your own view shaped the work.

Show enough cited extracts that readers can see how a claim follows from the material. Also show a case that pushed you to refine it. Do not present all accounts as interchangeable when they came from different prompts, time periods, or source types.

Say what you could not resolve. A small set of sources can support a close reading of those accounts. It cannot show how common an experience is in the wider group. Software may help you find and compare passages. It cannot decide whether your final account is sound.