How to Analyse Qualitative Data

Themes do not emerge from data on their own — they are constructed, and your job is to show the construction was disciplined.

Qualitative analysis is where many dissertations lose marks, usually not because the analysis was poor but because it was not made visible. Examiners cannot see your thinking; they can only see the account you give of it. Rigour in qualitative work is largely a matter of documenting how you moved from transcript to claim.

Choose an approach and commit to it

Thematic analysis, framework analysis, grounded theory, interpretative phenomenological analysis and discourse analysis are not interchangeable labels for “looking at interview data”. Each carries assumptions about what counts as a finding.

Pick the one that fits your question and your epistemological position, cite the version you are following, and apply it consistently. Claiming grounded theory while doing thematic coding is a frequent and easily spotted mismatch.

Prepare the data properly

Transcribe to a standard appropriate to your method. Discourse analysis may need pauses, overlaps and intonation marked; thematic analysis usually needs accurate verbatim text. Decide the convention in advance and apply it uniformly.

Anonymise at transcription, replacing names with consistent pseudonyms or codes. Doing it later is error-prone and risks identifiable material persisting in working files.

Read before you code

Familiarisation is a stage, not a preliminary. Read every transcript through without coding, making notes on impressions and questions. Coding too early anchors you to the first few interviews and makes later data fit categories built from an unrepresentative start.

Code systematically

Work through the data assigning short labels to segments that are meaningful for your question. Early coding should be generous — it is easier to merge codes later than to notice something you never marked.

• Descriptive codes summarise what is being talked about.
• Interpretive codes capture what you think it means.
• In vivo codes use the participant’s own words.
• Keep a codebook with definitions, so a code means the same thing in interview twelve as in interview one.

Software such as NVivo or Atlas.ti helps manage volume but does not analyse for you. Coding by hand on a small dataset is entirely legitimate.

Build themes that do analytical work

A theme is not a topic. “Communication” is a topic; “communication failures were attributed to individuals rather than to the handover system” is a theme, because it makes a claim. If your themes could serve as interview questions, they are topics and need developing.

Test each candidate theme against the data: is there enough evidence, is it coherent, is it distinct from neighbouring themes, and does it help answer the research question?

Use quotations as evidence, not decoration

Each quotation should demonstrate the claim it accompanies. Introduce it, present it, then interpret it — the same pattern as evidence in any argument. Attribute consistently with pseudonyms and enough context for a reader to judge relevance.

Avoid stacking three quotations to make the same point. One well-analysed extract is worth more, and a results section that is largely quotation has described rather than analysed.

Look for what complicates the pattern

Deviant or negative cases — participants who do not fit the emerging story — are analytically valuable. Reporting and explaining them is a mark of serious work, and concealing them is the qualitative equivalent of omitting inconvenient data.

Demonstrate rigour explicitly

Credibility, transferability, dependability and confirmability each need evidence rather than assertion. Say what you actually did: kept an audit trail, coded a subset with a second researcher, returned findings to participants, maintained a reflexive journal recording how your position shaped interpretation.

Write reflexively

Your background shapes what you notice. Stating your position — professional role, prior assumptions, relationship to participants — is not a confession of bias but a condition of interpretive work. Do it briefly and concretely, and connect it to specific decisions rather than offering a general disclaimer.

Decide inductive or deductive before coding

Inductive analysis builds codes from the data; deductive analysis applies a framework derived from theory or prior research. Many studies use both — a framework for structure, with room for codes that emerge. What matters is stating which you did, because it determines how a reader should judge your themes.

Silently switching between them mid-analysis is a common weakness and produces themes that neither follow the framework nor arise from the data.

Know when you have enough data

Saturation — the point at which new data stops generating new codes — is the conventional justification for sample size in qualitative work. It is frequently asserted and rarely evidenced. If you claim it, show the basis: at which interview did new codes stop appearing, and how many further interviews confirmed it.

Where your sample was determined by practical constraints rather than saturation, say so honestly. Examiners prefer an acknowledged limitation to an unsupported claim.

Present the analysis so it can be followed

A results section built only from quotations under theme headings leaves the reader to do the analytical work. Introduce each theme with a claim, present evidence, interpret it, and connect it to the other themes. A table showing the progression from codes to sub-themes to themes makes the construction visible and is frequently rewarded.