How to turn interviews and case studies into findings

What is a report-ready finding?

A report-ready finding is a clear claim drawn from analysed evidence that someone else can check. It says what the evidence shows, where it came from, how strong it is and what the reader should do with it.

Compare a working note with a finding. The note says: "Several interviewees mentioned delays." The finding says: "Delivery delays were most often linked to unclear approval points between delivery teams and senior reviewers. Interviewees described repeated rework at handover, and project records showed approval gaps in most of the cases reviewed."

The second version gives the reader a claim, an evidence base and a likely cause. It is also checkable: a reviewer can ask which interviews and which records, and the analysis file should answer at once.

A finding is not report-ready if it is only a memorable quote, a loose theme or a polished sentence with no source trail. The method below is the one we use across qualitative work, and the same logic applies when the material is public comment rather than interviews: see our guide to analysing public submissions.

Why start with the report question?

Start with the question the report must answer, because it decides what counts as evidence. Without it, findings drift towards the loudest quote, the longest interview or the most recent case.

Write the question down before you code anything. For example:

• What helped participants complete the programme?
• What barriers affected delivery at each site?
• How did different sites experience the same intervention?
• What should change in the next phase?

Then set out what evidence would answer it and where that evidence is likely to sit.

This frame gives every later step a simple test: does this piece of evidence help answer the question?

What should you set up before analysing interviews?

Set up two things before analysis: a source log so every interview, case study and document has a stable ID, and an extraction table where evidence is captured in the same fields every time. Together they are the route from a finding back to its source.

The source log can be short. What matters is that the IDs never change and that someone else could find the source again.

The extraction table is the working layer between raw material and the report. Each row is one piece of evidence:

Quotes that come out of this table are the raw material for a quote bank organised by theme, which saves writers going back into transcripts.

How do you code interview and case study data?

Read for meaning first, then code against a shared codebook that mixes planned codes from the brief with codes that emerge from the material. Coding is useful only if it serves the report.

Read before you tag. On a first pass, read whole transcripts or cases and note early patterns, questions and contradictions. Do not settle findings yet.

Use planned and emerging codes. Planned codes come from the brief, the research questions or the report structure. Emerging codes come from the material. If you only use the brief, you miss what you did not expect; if you only follow the data, the report drifts from the decision it has to support.

Keep one codebook. A codebook defines each code, says when to apply it and gives an example. The CDC Field Epidemiology Manual recommends a standard codebook, with definitions and coding rules, to stop codes shifting over time or between coders (CDC, Collecting and Analyzing Qualitative Data, 2024). That matters most when more than one analyst codes the same material.

For case studies, define each case the same way before coding: who or what the case is, the period it covers and the sources behind it. Cross-case comparison only works when every case follows one structure.

How do codes become themes?

A code is a label; a theme is a pattern that answers the report question. Group related codes, then test each candidate theme: does it answer the question, is there enough evidence behind it, and does it have a clear implication for the reader?

Reports go weak at this step when every topic becomes a finding. A theme that fails one of the three tests stays in the analysis file.

How do you test whether a finding is strong enough?

Test each draft finding against its evidence before it reaches the draft: apply a quote-per-claim rule, lay the evidence out in a matrix and label the finding's strength. This is where overclaiming gets caught.

Quote-per-claim. Every draft finding keeps at least one supporting quote, excerpt, case example, document reference or record link beside it in the analysis file. Not every sentence in the final report needs a quote, but the trail must be visible before the finding is final. The rule is simple: no finding without a source, no recommendation without a finding.

Evidence matrix. One row per draft finding, so a colleague, client or reviewer can challenge the interpretation without reading every transcript.

Strength labels. Not every finding carries the same weight. Label each one so reviewers can see what is ready and what needs more work.

How do you write a finding for the report?

Write each finding in four parts: the claim, the evidence, the interpretation and the implication. Quotes support the finding; they do not carry the explanation.

This structure keeps the report from turning into a quote dump, and it keeps evidence and interpretation separate, which is what reviewers look for. Published reporting standards ask for the same transparency. The Standards for Reporting Qualitative Research (SRQR) set out 21 items, including how data were analysed and the evidence, such as quotes or field notes, that substantiates each finding (O'Brien et al., 2014). COREQ, a 32-item checklist for interviews and focus groups, groups its items into three domains: research team and reflexivity, study design, and data analysis and reporting, and asks whether participant quotations are presented to illustrate the findings (Tong et al., 2007). Both are designed for journal articles, but they make useful checklists for evaluation and programme reports too.

Recommendations come after the findings are checked, not before. Our report writing workflow covers how findings move into recommendations and draft sections without losing the evidence behind them.

Where does AI fit in interview analysis?

AI can help with first-pass summaries, code suggestions, quote extraction and comparison across cases. It does not make findings. A person checks that each quote supports its claim, that context is preserved, that confidentiality holds and that the finding does not overreach.

The order matters: set the structure first (the question, the codebook, the extraction fields), let AI work inside it, then review before anything enters the evidence base. In the UNICEF Zambia household case studies, every claim AI extracted had to carry its supporting quote and its reasoning, and each case was checked before it went into the database.

When interview evidence has to stay usable after the report, for the next phase or the next review, it is worth having a source-linked evidence system, built and handed over to the team that will keep using it.

What outputs should the synthesis produce?

A good synthesis leaves a set of working files, not only a draft. Each one has a job in writing, review or later reuse.

Use this checklist before a finding moves into the draft:

Report-ready finding checklist
[ ] Answers the report question
[ ] Traces back to named sources with locators
[ ] Has at least one quote, excerpt, case example or record behind it
[ ] Checked for contradictions and exceptions
[ ] Strength label assigned
[ ] Evidence and interpretation written separately
[ ] Implication stated; any recommendation follows from it
[ ] Clear to a reader who is not a researcher
[ ] Participant confidentiality protected
[ ] Claims no more than the evidence supports

If a finding fails a check, it stays in the analysis file until it has been reviewed.

Common mistakes

• Treating strong quotes as findings. A quote supports a finding; it is not one. Explain the pattern, then use the quote as evidence.
• Coding before the question is written down. Codes then follow whatever is most vivid in the material.
• Losing the link between notes and claims. When notes are pasted into draft language too early, the trail is hard to rebuild. Keep source IDs and locators from extraction to drafting.
• Letting analysts use private codebooks. Two people coding the same interview differently produce findings nobody can compare.
• Flattening contradictions. Exceptions are evidence too. Record them in the matrix and say how they affect the finding.
• Writing recommendations before the evidence is checked. The report sounds confident while resting on weak material.
• Accepting AI output without review. Every extracted claim needs its quote checked by a person.