To analyse interviews, first read the transcripts in full, then label relevant passages and examine how the labels connect. Develop candidate themes that answer your research question, check them against the wider dataset and explain your interpretation using appropriate extracts. A list of quotations is not yet an analysis.
This guide illustrates reflexive thematic analysis, drawing on Braun and Clarke's own methodological resources. Other approaches use different assumptions and procedures. Agree the approach with your supervisor before claiming to follow it.
Your findings chapter should explain your interpretation and show how it connects to the evidence. UniDraft helps organise the method, permitted extracts and analysis you confirm into an editable project document. Start your project documentation, then review every theme, quotation and claim against the material you are allowed to use. See the project workflow; developing the analysis remains your work.
Prepare material you are allowed to analyse
The analysis begins with material selected for a reason. Keep the eligibility criteria, recruitment route and relevant experiences alongside the transcripts. The purposive-selection worksheet helps document those decisions. It does not make a small interview group statistically representative of a wider student population. Explain whose accounts you could access and which perspectives may be absent.
Use interviews you actually conducted or a dataset you have permission to use. Follow your ethics approval, consent arrangements and institution's data-handling requirements. Replace identifying details appropriately and keep the connection between participant codes and identities secure.
Do not upload raw identifiable transcripts to a tool without the necessary permission. Removing a name may not anonymise an account that identifies a person through their job, location and a distinctive event.
Before coding, note your research question, who the interviews can represent and what the interview schedule actually asked. If your question is about how students experience feedback, a set of interviews only about transport costs will not answer it by clever coding.
Plan questions before collecting material
Before collecting material, use the interview-guide workflow to align questions with the study. The guide's topic headings should not automatically become the analysis's final themes.
Check transcripts before coding
A transcript is a representation of a recording, not a licence to improve what a participant said. Decide how much speech detail the analysis needs, and use consistent speaker labels and uncertainty markers. The UK Data Archive's example transcription instructions show why conventions depend on analytic purpose and why unclear speech should be marked rather than guessed. Its particular formatting and retention instructions belong to that example, not every student project.
Use this original handover checklist with your approved process:
| Check | Record or action |
|---|---|
| Completeness | Compare the transcript against the permitted recording; identify missing sections |
| Unclear speech | Mark the location, ideally with a timestamp; do not invent words |
| Speaker identity | Check attribution, especially where voices overlap |
| Meaning | Preserve qualifications, negation and uncertainty rather than rewriting the account |
| Privacy | Review indirect identifiers as well as names; keep any identity key separately and securely |
| Versions | Retain an appropriate record of corrections and use a clearly identified analysis copy |
If speech is translated, document the original language, who translated it and how meaning was checked. Keep translation decisions distinguishable from the participant's words. Automated transcripts still need checking; do not upload confidential audio without permission for that processing. Follow your approved retention arrangements rather than this example source's deletion instructions.
Worked transcript-checking exercise
Fictional teaching exercise: every line and timestamp below is invented. There is no recording or participant behind it. The exercise shows why checking a transcript can change the interpretation; it is not evidence to include in your findings.
Imagine that a draft transcript contains: P04: “I understood the comment. I asked my friend to explain it.” For this exercise only, the stipulated wording is: P04: “I did not understand the comment.” Interviewer: “Did someone help?” P04: “I asked [unclear, 02:18] to explain it.”
| Difference to check | Why it matters | Appropriate action with real material |
|---|---|---|
| “Did not” was omitted | The draft reverses the account from difficulty to understanding | Replay the permitted source at that point and correct the analysis copy only if the wording is confirmed |
| The interviewer's question disappeared | The answer loses the prompt that shaped its context | Restore the correct speaker label and question under the agreed transcription conventions |
| “My friend” replaced an unclear phrase | The draft invents who provided help | Mark uncertainty with a location; do not guess a relationship or use it to support a peer-help claim |
Until the unclear phrase is resolved, a possible code might concern seeking clarification. A claim specifically about friends providing support would exceed this stipulated text. If the recording remains unclear, preserve that limit rather than making the account fit the code you want.
Keep corrections separate from interpretation. A short original correction-log format is:
| Transcript / location | Issue | Source check and decision | Analysis copy / reviewer / date |
|---|---|---|---|
| Fictional example: P04 / 02:18 | Uncertain helper identity | Marked “[unclear, 02:18]”; identity not established in this exercise | Example v2 / fill with the real reviewer and date in actual work |
In your own log, record what you actually checked. Do not write “verified against audio” if you only reread a typed document. Keep access, storage and version retention consistent with your approved data-handling arrangements.
From checked material to an initial code
The extracts below are invented teaching illustrations. They are not research participants, collected data or findings to submit.
| Illustrative extract | Possible initial code | Reason for the label |
|---|---|---|
| “The comment said ‘develop this’, but I could not tell which sentence it meant.” | Unclear location of feedback | The difficulty concerns identifying what to revise. |
| “When my supervisor marked one example, I could correct the rest myself.” | Example enables independent revision | The student describes learning how to apply a change. |
| “I changed it because I wanted approval, although I still did not understand the reason.” | Compliance without understanding | Making a change is different from understanding it. |
These are possible interpretations, not an answer key. A different research question could justify different labels. Keep a note explaining why you chose a code and return to the original passage when the label becomes detached from its context.
Develop a candidate theme, then challenge it
An early candidate might be “Feedback becomes useful when students can act on it.” It connects clarity and worked examples, but the third extract complicates it: students may act without understanding.
That complication could lead you to distinguish visible compliance from learning. Or it may show that your first theme is too broad. You cannot decide from these three snippets alone. Read across the real dataset, including passages that do not fit your preferred account.
“Challenges” is usually a topic heading. A theme needs a more specific organising idea. Ask what your grouped extracts explain about the question, not just what subject they mention.
Keep a record of your analysis
Braun and Clarke describe an iterative process of becoming familiar with the data, coding, developing and reviewing themes, refining them and writing the analysis. Movement between activities is expected; the phases are not a mechanical checklist that guarantees a sound interpretation.
Your working record can be simple:
| Decision | Note to keep |
|---|---|
| Why an extract was coded | The passage, context and analytic reason |
| Why codes were grouped | The shared meaning you think connects them |
| Why a theme changed | Contradictory evidence, overlap or a better explanation |
| How your perspective matters | Assumptions you brought and how you questioned them |
| How a claim is supported | Relevant extracts and the boundary of the claim |
Do not add independent-coder agreement or a fixed codebook automatically and call it reflexive thematic analysis. If your chosen approach requires different procedures, explain that approach accurately rather than mixing incompatible quality criteria.
Write findings as an argument
Introduce the theme's central idea. Explain it, show a suitable anonymised extract, then interpret what the extract contributes. Include meaningful variation rather than choosing only quotations that make the account look neat.
Avoid turning a small interview sample into statements such as “all Nigerian students experience this.” Describe the context and limits of your participants. A count of people mentioning a topic does not, by itself, establish its importance or representativeness.
Use the methodology guide to explain your procedure and the results-chapter guide to position the findings. Your discussion then relates them to verified literature.
Final check
- Does the named approach match what you actually did?
- Can you trace every research extract to permitted original material?
- Have you explained meaning rather than pasted quotations?
- Did you examine contradictory accounts and your own assumptions?
- Are privacy, consent and the limits of the sample clear?
UniDraft can help organise a project around the findings and analysis you confirm. It does not turn these fictional illustrations into your evidence or replace your responsibility for interpreting real data. Explore the project workflow.
Methodological sources
- Braun and Clarke: Doing reflexive thematic analysis.
- Thematic analysis FAQs, including differences between approaches and their quality assumptions.
