Thematic analysis in a dissertation goes wrong most often in the write-up, not the coding: themes that only name a topic, quotations left to speak for themselves, and a method section that mixes approaches without saying so. Here is what a careful examiner looks for, and how Esmond reads that part of your work.
Check my analysisThematic analysis is a family of methods, not one procedure. Many student projects cite Braun and Clarke's 2006 paper, and in their later work they call their approach reflexive thematic analysis: the researcher's interpretation is the analytic tool, and themes are developed rather than found. Codebook approaches such as template analysis or framework analysis work with a more structured coding frame, and coding reliability approaches aim for agreement between coders.
The problem is not choosing one over another. It is citing one and doing another. A method section that cites Braun and Clarke and then reports agreement scores between coders, or claims that coding stopped at data saturation, mixes assumptions that the authors themselves argue do not fit their approach. Name your approach, say whether your coding was mainly inductive or deductive, and stay consistent.
Listing the familiar phases (familiarisation, coding, developing themes, reviewing them, defining and naming them, writing up) shows you know the procedure. It does not show what you did. A strong method section explains how you moved through your own data: how you coded, how codes were grouped into candidate themes, what you merged, split or dropped, and why. That account is what lets a reader trust your themes.
A theme is a pattern of shared meaning organised around a central idea: it makes a claim about your data. A topic summary collects everything participants said about one subject. Headings that mirror your interview questions are a warning sign, because they usually mean the analysis has organised the answers rather than interpreted them.
A quick check for each theme: can you state, in one sentence, what it claims? If the sentence only names a subject, the theme is probably still a topic.
Extracts from your data illustrate a point; your commentary makes the point. A paragraph that introduces a quotation and moves straight on to the next one leaves the reader to do the analysis. Watch, too, for one articulate participant carrying a whole theme, and for words like 'most' or 'many' in a small sample, where they suggest a frequency your design was not built to measure.
In reflexive thematic analysis, your perspective shapes what you see in the data. Examiners look for a reflexive passage that is specific: how your role, for example as a student nurse interviewing nurses or as a member of the community you studied, may have shaped access, the conversations and your reading of them. A general statement that bias was minimised does not do that job.
Esmond reads your text. It does not see your transcripts or your coding, so it cannot tell whether a theme is well grounded in the data. It can show where the write-up does not yet demonstrate that it is.
A review costs from €3.99, with a free preview first. The price follows the length of your document and you see it before you pay. No subscription, no account.
It depends on the approach. Coding reliability approaches use it; Braun and Clarke argue it does not fit reflexive thematic analysis. Name your approach and report quality checks that match it, and follow your supervisor's guidance.
There is no correct number. A few well-developed themes usually say more than a long list of thin ones, but it depends on your data and your question.