tesifyUK
Start writing free
How it worksFAQBlogHelpContactLog in

Tag: qualitative research

  • You Have 40 Interview Transcripts and No Findings Chapter: Writing Up Qualitative Management Research (2026)

    You Have 40 Interview Transcripts and No Findings Chapter: Writing Up Qualitative Management Research (2026)

    Forty interviews. Somewhere over 300,000 words of transcript. A coding frame that started with eight categories and now has ninety. A supervisor who asked what your findings are, and an answer that took four minutes and did not land. The findings chapter is due in three weeks and you cannot write the first sentence.

    This is not a discipline problem or a data problem. It is a structural one, and it has a specific cause: coded data is organised by category, and a chapter has to be organised by argument. Nothing in the coding process converts one into the other. That conversion is a separate piece of intellectual work, and almost nobody is taught to do it.

    Turn your transcripts into a findings chapter with Tesify

    What it costs to stay stuck here

    Postgraduate management researchers lose more time at this point than at any other stage, and the losses compound in ways that are worth naming plainly.

    The obvious cost is calendar. A findings chapter that should take six weeks takes five months, and on a one-year masters that is the difference between submitting and applying for an extension. On a funded doctoral project it eats into the write-up period you were relying on for the discussion chapter.

    The less obvious cost is analytical. A findings chapter written under time pressure defaults to the safest available structure — one section per theme, each opening “Participants reported that…” followed by two quotations and a paragraph of paraphrase. That chapter passes, usually. But it is also the chapter that produces the worst discussion chapter, because there is no argument in it for the discussion to develop. Examiners describe this as descriptive rather than analytical, and it is the single most common criticism of qualitative management dissertations.

    The third cost is that the work never becomes a paper. A theme-by-theme description has no thesis, and journals in management reject on exactly that basis.

    Why interview data resists becoming a chapter

    Three specific mechanisms, all fixable once you can see them.

    Codes multiply and never resolve. Coding is a divergent process — every pass generates distinctions. Nothing in the method forces convergence, so a frame grows until it has more categories than the chapter can carry. Ninety codes is not analysis; it is deferred analysis.

    Themes are nouns, and arguments are claims. “Trust”, “middle management resistance” and “communication breakdown” are topic labels. They can be listed but not argued. A chapter needs statements that could be wrong: trust in senior leadership was rebuilt through operational reliability rather than through communication, and middle managers were the mechanism. That sentence has a shape. A noun does not.

    The quotations start driving. Everyone has three or four transcripts where a participant said something unusually articulate. Those quotations begin to organise the chapter around themselves, and the analysis quietly becomes an anthology of your best interviews rather than an account of all forty.

    The four moves that produce a findings chapter

    Move 1: Collapse the coding frame to between four and seven themes

    Do this before writing anything. Take the ninety codes and group them by what they are evidence of, not by what they are about. Codes about email volume, meeting frequency and reporting lines may all be evidence of the same underlying finding about information asymmetry between head office and sites.

    Anything that cannot be grouped either belongs in a different chapter or is not a finding. Four to seven themes is the range a chapter can develop properly; ten becomes a list.

    Move 2: Write each theme as a claim, in one sentence

    For each surviving theme, write a single declarative sentence stating what you found — not what the topic was. Test each one against two questions: could a reasonable person disagree with it, and does your data actually support it across the sample rather than in three interviews?

    These sentences become your section headings, or at minimum the opening line of each section. Most researchers find that two of their themes fail this test and merge into a stronger third. That is the process working.

    Move 3: Sequence the claims into an argument

    Themes are not independent. Order them so that each prepares the next — condition first, then mechanism, then consequence, then the exception that qualifies it. Write a single paragraph at the top of the chapter that states all four claims in order. If that paragraph reads as a coherent account, your chapter has a spine. If it reads as a list, the sequencing is not done yet.

    This paragraph is also the answer to the question your supervisor asked, and the answer you will need in a viva.

    Move 4: Build each section on evidence, not illustration

    Within each section, follow the same shape: state the claim, establish its distribution across the sample, present evidence, interpret it, and mark the boundary.

    Distribution matters more in management research than students expect. “Fourteen of the twenty operational managers described this, while none of the six head-office participants did” is a finding with structure. “Participants reported…” conceals whether you mean three people or thirty-eight. You are not counting to make the work quantitative; you are being precise about your own evidence, and examiners read that as confidence.

    Quotations should be doing evidential work rather than decorating a point you have already made in your own words. Two well-chosen extracts beat six. And every section needs its boundary stated — the participants for whom this did not hold, and what that tells you.

    Keeping findings and discussion separate

    In management dissertations the two chapters bleed into each other constantly, and the fix is a clean division of labour. The findings chapter reports what is in your data, using your participants’ terms and your own analytic categories. The discussion chapter puts that into conversation with the literature, and that is where theory names appear.

    If you find yourself citing Weber in the findings chapter, you have started the discussion early — and you will then have nothing left to say in the chapter that is supposed to make the contribution. The structure that chapter needs is set out in the seven-move guide to writing a discussion chapter. The relationship also runs backwards: your findings should answer questions your literature review chapter actually raised, and if they do not, one of the two chapters needs revisiting.

    Where the tooling actually helps

    Analysis software does the part it is good at and no more. Coding, retrieval and querying across forty transcripts is genuinely faster in a dedicated tool, and the options — including a free one — are compared in the review of NVivo, ATLAS.ti and Taguette. What none of them does is tell you which four claims your chapter is making. Researchers who expect the software to produce themes end up with a tidier version of the same ninety-code problem.

    The same applies upstream. Transcription tools save real hours, but what your ethics approval permits is the binding constraint, as set out in the comparison of research transcription tools.

    How Tesify handles the part that is actually hard

    The gap is between having coded data and having a chapter, and it is a writing problem with an analytical core. Tesify is built for that gap.

    You bring your themes and your evidence into a workspace where the drafting and the sources sit together, so a claim in your chapter stays attached to the material it rests on rather than to your memory of it. You can work a theme into a claim sentence, test how it reads in sequence with the others, and see immediately where a section has interpretation but no evidence behind it. Structural feedback tells you when a section is describing rather than arguing — the criticism examiners make most often, and the one that is hardest to see in your own draft.

    What it will not do is decide what you found. That judgement is the contribution, it has to be yours, and any tool that offers to make it for you is offering you something an examiner will take apart in a viva. Tesify is built to keep the reasoning in your hands and take the friction out of everything around it.

    There is a free tier, so you can put a single chapter through it before deciding whether it earns a place in your workflow.

    Start your findings chapter with Tesify

    Frequently asked questions

    Is using an AI tool to write a findings chapter allowed?

    Policies differ by institution and you must check your own before using any tool. The line most UK universities draw is between support for your writing and substitution for your thinking. Structuring, drafting assistance and feedback are generally permitted where declared; presenting generated analysis as your own findings is not.

    Will an examiner be able to tell?

    An examiner will establish in a viva whether the analytical judgements are yours by asking why you grouped codes as you did and what you rejected. A chapter whose reasoning you cannot reconstruct out loud fails that test regardless of how it was produced, which is why the analysis has to remain your own work.

    Is my unpublished interview data safe in an AI tool?

    This is the right question to ask before uploading anything, particularly where participants consented under specific conditions or an organisation granted access commercially. The legal position and the five questions to put to any tool’s terms are set out in our article on putting unpublished thesis data into AI tools.

    How much does Tesify cost?

    There is a free tier that lets you work through a chapter before committing, with paid plans for sustained use across a full dissertation. Current pricing is on the Tesify site; check it at source rather than relying on figures quoted elsewhere.

    How many themes should a findings chapter have?

    Four to seven is the range most chapters can develop with adequate evidence and interpretation. Beyond that, sections become too short to argue anything and the chapter reads as a list. If you have ten, at least three are usually sub-themes of others.

    Should you count how many participants mentioned each theme?

    Report distribution without turning it into pseudo-quantification. Saying that a view was held by operational managers but not head-office participants is analytically useful. Presenting percentages from a purposive sample of forty implies a generalisability the design does not support.

    How long should a qualitative findings chapter be?

    Your programme’s word limit governs, and it varies widely. As a working proportion, the findings chapter is often the longest single chapter in a qualitative dissertation because quotations consume words. Check whether your regulations count extracts within the limit.

    What if your data does not answer your research question?

    This is common and usually recoverable by revising the question to match what the data addresses, in consultation with your supervisor. A dissertation that honestly reports what it found against a revised question is examined far better than one that forces unwilling data toward the original one.

  • Best Transcription Tools for PhD Research Interviews (2026): Accuracy, Ethics and Cost Compared

    Best Transcription Tools for PhD Research Interviews (2026): Accuracy, Ethics and Cost Compared

    Transcription sits at an awkward junction: it is the most automatable drudgery in qualitative research, and it involves shipping your participants’ voices — personal data by definition — to whatever service you picked at midnight. So this comparison runs compliance first, capability second: the fastest transcriber in the world is the wrong choice if your ethics approval and data-management plan never named it.

    Local AI (Whisper-class) Otter.ai Your university’s Microsoft 365 tenant Human transcription services Doing it yourself
    Where audio goes Nowhere — processed on your machine Otter’s cloud Institutional cloud, inside existing agreements The service’s staff and systems Nowhere
    Cost Free (open-source) Free tier 300 min/month; Pro $8.33/month annual (1,200 min); 20% student discount via .edu email Usually included Per audio hour; the premium option Your time: ~4–8 hours per audio hour
    Accuracy on clear audio Strong Strong Good Best, especially accents and crosstalk Perfect, eventually
    Accuracy on messy audio (cafés, dialect, jargon) Degrades; better with larger models Degrades Degrades Holds up best Holds up, slowly
    Ethics-form friendliness Highest — no third-party processing Requires naming a third-party processor High — often pre-approved infrastructure Needs confidentiality agreement Highest
    Best for Most doctoral interview studies Meetings and low-sensitivity recordings Institutionally cautious projects Difficult audio, funded projects Small N, analytic immersion

    Start with the rule, not the tool

    Interview recordings are personal data — a voice is identifiable even before the content is — and your handling of them is governed by what your ethics application, participant information sheet and data-management plan actually said. Universities increasingly publish lists of approved transcription routes or require a data-protection assessment before audio leaves institutional systems, and sending recordings to an unapproved consumer cloud service can put you in breach of commitments you signed, whatever the tool’s own privacy page says. The sequence that keeps you safe: name your transcription route in the ethics application; describe it in the information sheet (“recordings will be transcribed using…”); and if your plans change mid-project, amend the approval rather than improvising. If you are before that stage now, write the transcription paragraph today — it is ten minutes that removes the whole class of problem, and the same logic applies to every tool that touches participant data.

    The shortlist, ranked for a doctorate

    1. Local AI transcription — the new default

    Open-source speech models of the Whisper family changed this decision: strong automatic transcription that runs on your own computer, so the audio never leaves your possession. That single property collapses most of the compliance analysis — there is no third-party processor to name, justify or trust — and the price is zero. Costs: you need a reasonably capable machine, a small amount of setup (your university’s research computing team or a colleague has almost certainly done it already), and accuracy still degrades on poor recordings. For a typical doctoral interview study — sensitive-ish data, dozens of hours, no transcription budget — this is the recommendation.

    2. Your university’s Microsoft 365 transcription — the institutional route

    If your university runs Microsoft 365, transcription inside Word or Teams processes audio within the institutional tenant — infrastructure your university has already contracted for, which is why data-protection teams often point students here first. Accuracy is serviceable rather than stellar, and speaker separation is basic, but “the recording never left university systems” is a sentence that makes ethics reviewers relax. Check your institution’s own guidance for what its licence covers.

    3. Otter.ai — capable, for the right recordings

    Otter is polished and fast, with live transcription, speaker labelling and a workable free tier (300 minutes a month; Pro at $8.33 a month billed annually raises it to 1,200 minutes, with a 20 per cent student discount via a .edu address). The catch is precisely its cloud nature: for research interviews it is a third-party processor of participants’ personal data, which your approval must cover. Where it fits: low-sensitivity recordings, your own research memos, supervision meetings — and interview studies whose approval explicitly names it.

    4. Human transcription services — buy them for the hard cases

    Professional transcribers still beat every machine on strong accents, overlapping speech, poor recordings and specialist vocabulary, and offer the choice of intelligent verbatim versus full verbatim done judgementally rather than mechanically. They cost real money per audio hour and add a confidentiality step (a signed agreement, a reputable service, an approval that mentions outsourcing). Rational uses: a funded project, a handful of unusable-by-machine recordings, or Deaf/accessibility workflows.

    Audio recorder and consent forms after a research interview
    The consent form and the transcription route are one decision: participants agreed to a specific handling of their voices.

    Recording well is half the transcription problem

    Every tool in the table performs a tier better on good audio, and good audio is mostly free. Use a dedicated recorder or a decent phone app rather than a laptop microphone across the table; put the device nearer the participant than yourself, since their words matter more than your questions; choose the quiet room over the atmospheric café whenever the participant allows; record thirty test seconds and listen back before the interview proper; and for remote interviews, use the platform’s own recording rather than re-recording speaker audio through the air. One more habit that saves projects rather than minutes: duplicate the file to institutional storage before you leave the building or close the call. A machine transcript of a clean recording plus a light correction pass beats a human transcript of a bad one — and the recording is the only stage you can never redo.

    The step everyone skips: correction is analysis

    Whatever produces your first draft transcript, the checking pass — you, headphones, audio against text — is not optional overhead. Automatic transcripts fail exactly where interviews are most interesting: jargon, names, emotional speech, overlaps. And the correction hours are quietly the first analysis pass; researchers routinely report their best early codes emerging while fixing transcripts. Budget roughly one to two hours per audio hour for correction of machine output — against four to eight for typing from scratch — and log your conventions (how you marked pauses, laughter, redactions) because your methods chapter will need them. From there the transcripts flow into coding — NVivo, ATLAS.ti or Taguette — while the conceptual notes they generate belong in your notes system, not a folder of stray documents.

    The recommendation

    Run local Whisper-class transcription as your default; use your university’s Microsoft 365 transcription where institutional processing is the path of least resistance; pay humans for the recordings machines cannot handle; and use consumer cloud tools only where your ethics approval names them. In every case, the tool appears in your ethics paperwork before it appears in your workflow.

    And when the transcripts are coded and the findings chapter looms, the bottleneck moves back to the writing itself. Tesify structures and drafts the thesis with you — chapters, methods documentation and bibliography in one workspace, 100% written by you — so the months you saved on transcription arrive intact at the examination.

    Frequently asked questions

    What is the best free transcription tool for research interviews?

    Local Whisper-class transcription: free, strong on clear audio, and — because it runs on your own machine — the easiest route to justify in an ethics application. Your university’s included Microsoft 365 transcription is the runner-up.

    Can I use Otter.ai for PhD interviews?

    Only if your ethics approval and participant information cover a third-party cloud processor — name it, justify it, and check whether your university restricts it. For meetings and non-participant audio it needs no such ceremony.

    Is it a GDPR problem to upload interviews to a transcription site?

    It is a data-processing decision that must match what participants consented to and what your university permits. Voices are personal data; an unapproved upload can breach your own signed commitments even where the service itself is reputable.

    How long does transcription actually take?

    Typing from scratch: commonly four to eight hours per audio hour. Machine-first with human correction: the machine minutes plus one to two hours of checking per audio hour. The correction time is real work — and doubles as first-pass analysis.

    Do I have to transcribe every interview in full?

    Methodologically, it depends on your analysis: some approaches require full verbatim transcripts; others defensibly work from full transcripts of core interviews plus indexed partial transcripts elsewhere. Whatever you choose, state and justify it in the methods chapter.

    Should I use intelligent verbatim or full verbatim?

    Full verbatim (every um, repair and overlap) where the interaction itself is analysed, as in conversation-analytic work; intelligent verbatim (cleaned for readability, meaning preserved) for most thematic work. The decision belongs to your method, not your transcriber.

    How should I store recordings and transcripts?

    Exactly as your data-management plan says: institutional storage, not personal devices; recordings and identity keys separated from transcripts; pseudonymisation applied at transcription time; deletion on the schedule you promised participants.

    Can AI transcription handle strong accents and dialects?

    Less well than clear standard speech — error rates rise, and rise most on precisely the participants whose voices are least represented in training data. Pilot your tool on your hardest expected audio before committing, and budget human help for what fails.

    Do I need participants’ consent to use AI transcription?

    You need consent that covers your actual processing. The clean practice is to describe the transcription route in the participant information sheet; a vague “recordings will be transcribed” plus a later cloud upload is where problems start.

    What should the methods chapter say about transcription?

    The route (tool or service, and where processing happened), the verbatim convention, the correction process, anonymisation practice, and the storage arrangements — three or four sentences that jointly demonstrate the data was handled as approved.

  • NVivo vs ATLAS.ti vs Taguette for Qualitative PhD Research in 2026 (They Are Not All Rivals Any More)

    NVivo vs ATLAS.ti vs Taguette for Qualitative PhD Research in 2026 (They Are Not All Rivals Any More)

    Start with a fact that reframes most of the comparisons you will find online: NVivo and ATLAS.ti are now products of the same company. Lumivero acquired QSR International, NVivo’s publisher, with the legal entity consolidation taking effect on 1 July 2023, and announced its acquisition of ATLAS.ti on 12 September 2024. Lumivero lists both under its research and qualitative data analysis portfolio.

    This matters for two reasons. Older head-to-head comparisons were written when these were competing companies with an incentive to differentiate, so their framing is now dated. And a market where the two dominant tools share an owner is one where you should think harder than usual about lock-in.

    NVivo ATLAS.ti Taguette
    Owner Lumivero Lumivero Rémi Rampin and contributors
    Licence Proprietary Proprietary Open source (BSD 3-Clause)
    Cost to you Commercial; often a university site licence Commercial Free
    UK site licences Common Less common Not applicable
    Feature depth Very high Very high Deliberately minimal
    Access after your registration ends Usually lost Usually lost Retained
    Best suited to Large mixed-method projects in NVivo departments Visual, network-oriented analysis Interview coding where simplicity is a feature

    NVivo

    NVivo is the most widely licensed qualitative analysis package in UK universities, and that institutional footprint is its main practical advantage. The University of Manchester, for example, announced in June 2025 that NVivo 14 and 15 are available for all staff and students working in the UK or Ireland. Where a site licence exists, so usually do local training sessions, library guides and colleagues who can help when something breaks — support that is worth more mid-project than any feature.

    Strengths at doctoral scale. It handles large and heterogeneous datasets well: interviews, focus groups, documents, survey open-text and media in one project. Its matrix and comparison queries are genuinely useful when you want to examine how coding varies across participant attributes, which is exactly the kind of analysis a doctoral project reaches in its second year and an undergraduate project never does.

    Weaknesses. The interface rewards investment; expect to lose real time early. Licensing is the sharper issue — student licences are typically time-limited, and access normally ends with your registration. Lumivero states that it supports two previous versions, which matters if you return to a project after a gap.

    ATLAS.ti

    ATLAS.ti has a long lineage — the company behind it was founded in 1993 — and a distinct analytical character. Where NVivo’s mental model is a hierarchy of codes, ATLAS.ti’s is a network: it is built around linking quotations, codes and memos and then visualising those relationships.

    Strengths. If your analysis is genuinely relational — grounded theory work where you are building connections between concepts rather than counting occurrences within them — the network view is not decoration; it is the analysis. Its quotation-level linking is more natural than NVivo’s for this style of work.

    Weaknesses. UK institutional licences are less common than for NVivo, so you are more likely to be paying yourself or working within a departmental allocation. Its published pricing page was unavailable at the time of writing, so confirm current student licensing directly with the vendor rather than relying on figures quoted in older guides.

    The ownership point again. Two products under one owner may converge, and the differentiation between them may narrow over time. Nothing about that is sinister, but it argues against choosing on the basis of a feature gap that may not persist for the length of your candidature.

    Colour-coded thematic codes applied across qualitative data
    Software organises coding; it does not perform it. The interpretive decisions remain entirely yours.

    Taguette

    Taguette is free and open source, released under the BSD 3-Clause licence and maintained by Rémi Rampin with contributors. It is actively maintained — its repository showed commits in 2026 at the time of writing — and a hosted version is available alongside a local install.

    One caution when assessing it: its GitHub mirror lists releases only up to 2019, because releases are cut on GitLab rather than the mirror. Read that as a packaging artefact, not as abandonment, which is a mistake some comparison articles make.

    Strengths. It does the core job — importing documents, highlighting, tagging, exporting coded extracts — and it does not expire. Your project remains yours after submission, after your viva and after your registration ends. For interview-based doctoral work with a manageable number of transcripts, the feature gap against the commercial tools is smaller than their marketing implies.

    Weaknesses. Deliberately minimal. No sophisticated query language, no attribute-based matrix analysis, no substantial visualisation. If your project needs to interrogate coding patterns across participant characteristics, you will hit the ceiling. Institutional support is unlikely to exist, so you are your own help desk.

    The criterion doctoral researchers under-weight

    Ask what happens to your project files when your licence ends.

    This is a doctoral problem specifically. Undergraduate projects finish and are never revisited. A doctoral project generates papers for years afterwards — and returning to your coded data to check a claim for a reviewer, eighteen months after submission and six months after your account closed, is a genuinely common scenario.

    Three mitigations, whichever tool you choose. Export your coded extracts in an open format at every major milestone rather than only at the end. Keep your codebook as a separate document, not only inside the software. And before your registration ends, export everything and check the export actually opens.

    The recommendation

    Use NVivo if your university holds a site licence and your department teaches it — local support outweighs feature differences, and it comfortably handles doctoral-scale projects.

    Use ATLAS.ti if your analysis is genuinely network-oriented and you have funded access.

    Use Taguette if your project is interview coding at a moderate scale, if you have no institutional licence, or if long-term access to your own coded data matters more than query features. It is a legitimate scholarly choice, not a compromise.

    And do not overlook the fourth option: coding by hand, in a spreadsheet or a word processor with a disciplined codebook. For a project with fifteen interviews and a reflexive thematic approach, this remains entirely defensible, and some methodologists prefer it on the grounds that it keeps you closer to the data.

    What the software will not decide for you

    No package chooses your analytical approach, and examiners assess the approach rather than the tool. Naming your software in the methods chapter is necessary; it is not a methodology. “Data were analysed using NVivo” describes a container, not a method — you need to state the analytic approach, how codes were generated, how themes were developed and who was involved.

    Nor will any tool tell you when you have enough data, or what your findings mean once coded. That interpretive work is what the discussion chapter exists to carry, and what ultimately supports the claim examined in our guide to stating an original contribution to knowledge. If you are earlier in the process, your analytical strategy is also one of the things a panel probes at the upgrade or confirmation review — and naming a package there without describing a method is a reliable way to invite a difficult question.

    If the coding is done and writing it up is the bottleneck, you can draft those chapters in Tesify from your own themes and extracts — the interpretation stays 100% written by you.

    Frequently asked questions

    Do examiners care which qualitative software I used?

    No. They care that your analytic procedure was systematic, transparent and appropriate to your methodology. A thesis that names a package but cannot describe how codes became themes is weaker than one that coded by hand and explains the process fully.

    Is it acceptable to code a PhD by hand?

    Yes, and it remains common in some methodological traditions. Describe your procedure carefully and keep an auditable codebook. Software makes management easier at volume; it does not confer rigour.

    Can I move a project between these tools?

    Partially, and expect loss. Coded extracts and codebooks usually survive export and import; memos, links and network structures often do not. Choose early and commit, rather than planning to migrate mid-analysis.

    Does using software mean my analysis is quantitative?

    No. These tools organise qualitative data; they do not convert it into numbers. Counting code frequencies is possible but is a choice you make, and in interpretive traditions it is often inappropriate — say what you did and why.

    Will my university licence work on my personal laptop?

    Usually yes, for the duration of your registration and for academic use only. Terms vary, so check your IT services pages, and plan for the licence ending when your registration does.

    Is Taguette still maintained?

    Yes. Its repository showed activity in 2026 and the hosted service was accepting registrations at the time of writing. The stale release list on its GitHub mirror reflects where releases are published, not the state of the project.

    How many transcripts can Taguette handle?

    Enough for a typical interview-based doctoral project. The constraint you will meet is analytical rather than technical — the absence of attribute-based querying — so if you plan to compare coding systematically across participant groups, choose a fuller package from the start.

    Should I mention the software in my methods chapter?

    Yes, with the version number, alongside a full description of the analytic approach. The software belongs in a sentence; the method deserves several pages.