Cross-case analysis: how to compare interviews without losing context

To do cross-case analysis, define what counts as a case, examine each case in its own context, then compare the same questions across cases. Keep the supporting evidence beside every comparison. Look for differences and exceptions as deliberately as similarities.

The aim is to explain a pattern without flattening the people, teams or situations behind it. If three interviewees describe a delay, the useful question is not simply whether “delay” appears three times. It is whether the delays happened at the same stage, under comparable conditions, and for similar reasons.

This guide offers a practical workflow for comparing recorded product and customer interviews. Its example is fictional. For a formal academic study, use the research design and analytical method agreed for that study; a working matrix does not, by itself, establish methodological rigour.

What cross-case analysis means

Cross-case analysis examines relationships between cases. Khan and VanWynsberghe describe it as a way to develop knowledge by accumulating, comparing and contrasting individual case studies. The cases remain meaningful units, rather than disappearing into an undifferentiated collection of quotations. Cross-case analysis research abstract

A case could be a person, a customer organisation, a project or an implementation. It is not automatically one recording. Three conversations with one customer might describe one case over time; one workshop might contain accounts from several cases.

Within-case analysis asks what happened inside one case and how its circumstances fit together. Cross-case analysis asks how that account relates to others. You will often return to individual cases when a comparison exposes an ambiguity.

This differs from simply grouping comments under themes. A theme such as “handover difficulty” may appear across the dataset. A cross-case comparison asks which cases experienced it, which did not, and what differs between those situations. For the wider process of moving from observations to findings, see the research synthesis guide.

Before you start

Have the relevant recordings, transcripts and any contextual notes available. Decide where the working comparison will live: a spreadsheet, a research repository or a document you can revise. Keep a source reference for every entry.

Choose a question that can be answered by the material. “How do small agencies handle client approval?” gives you a comparison to build. “What do customers think?” does not define a useful boundary.

Check whether each case was actually asked about the topic. A missing answer can mean the interviewer never asked, the recording is incomplete or the participant did not know. None of those means the experience did not occur.

Before sharing evidence, check the permissions and agreements governing the recordings. Use case codes in the working comparison where names are unnecessary. A code reduces casual disclosure; it does not make a recognisable account anonymous.

1. Define the case and the comparison boundary

Write one sentence defining your unit of analysis. For example: “A case is one agency’s process for approving a completed client deliverable.” Then decide the time period and which kinds of deliverable qualify.

Keep a small case register with a code, the relevant recordings, the participant’s role, the process being discussed and known gaps. If two people describe the same agency process, link their accounts to the same case while preserving who said what.

Do not quietly count one organisation twice because it contributed more interviews. Conversely, do not merge different branches or teams if their circumstances matter to your question. Explain the choice before counting anything.

A conference paper on cross-case strategies describes a common research question as the starting point for comparison, while allowing attention to context-specific differences. That is a useful discipline even for a small applied project. EERA research contribution

2. Write a short account of each case first

For each case, record the sequence of events, the participant’s explanation and relevant context. Keep direct evidence separate from your interpretation.

In the fictional approval study, Case A might involve a two-person agency, an established client and an email approval process. Case B might involve a larger agency, a new client and several approvers. Those details could explain a difference in delays better than the wording of an individual complaint.

A useful case account answers:

• What process or event did this person describe?

• What was the starting situation and intended outcome?

• Who was involved, and which parts did the participant observe directly?

• What happened next?

• Which parts remain uncertain or contradictory?

Keep the account short enough to compare, but retain a route to the fuller material. Do not resolve disagreement between two participants by choosing the more confident speaker.

3. Build a matrix around comparable questions

Use one row per case and one column per analytical question. Choose columns because they help answer the research question, rather than because they are easy to count.

For the approval study, the columns might be: approval route, who can approve, reported delay, workaround, outcome and source reference. Add a context column if team size or client history seems relevant.

Use explicit missing-data labels. “Not asked”, “unclear answer”, “not applicable” and “not observed in reviewed material” mean different things. Avoid an empty cell that later becomes an accidental “no”.

A cell should contain a concise account, not an unsupported conclusion. “Participant reported waiting two days for a second approver; Interview B, 12:10” is more useful than “bad communication”. Include any qualification that changes the meaning.

If a column keeps producing incomparable answers, revise the question or divide it. “How long did approval take?” can refer to elapsed time, active work or the wait after submission. Those measures should not share a single number column without explanation.

4. Compare rows as well as columns

Read down a column to examine a possible pattern. Then read across each row to check whether that pattern makes sense within the case.

Consider this fictional comparison:

• Case A: one named approver; same-day approval; no chasing reported for the example discussed.

• Case B: two approvers, but the order was unclear; a two-day wait; the agency sent a reminder to both.

• Case C: two approvers with a stated sequence; same-day approval; the second approver had already reserved time.

• Case D: participant described preparing the deliverable, but the interview did not cover approval timing.

“Two approvers cause delays” does not survive Case C. A more useful provisional interpretation is that an unclear approval sequence may contribute to waiting. Case D cannot be counted as either support or contradiction.

The next step is to check that interpretation against more evidence: was the client available, was the deliverable complete, and did the participants describe comparable deadlines? This is a hypothesis to examine, not a causal finding established by three short accounts.

5. Keep contradictions and alternative explanations

Create a separate note for evidence that challenges your emerging explanation. Do not hide it in an appendix that nobody reads.

Ask whether an apparent difference could be explained by the interview question, the participant’s role, the stage of the project or incomplete recall. If the interviews happened months apart, a changed process may matter more than a difference between people.

Return to the source when the matrix entry seems unusually neat. A participant may have said that approval was usually quick, then described an exception later. Keep both parts if they affect the claim.

If a contradiction cannot be resolved, state it. “Accounts differ about whether the approver was named before submission” is a useful result. Inventing a single tidy narrative would remove the uncertainty that the next conversation needs to address.

6. Write a finding that names its limits

A finding should describe the pattern, its scope, the supporting cases, the exception and the next useful action. Avoid turning a small qualitative comparison into an unsupported population estimate.

For the fictional study:

In the three cases with approval timing discussed, the delayed example also had an unclear approval sequence. The case with two approvers and a stated sequence did not report the same delay. Investigate whether making the sequence explicit helps; the interviews do not establish that the number of approvers causes waiting.

This is deliberately narrower than “customers need an approval automation feature”. The latter adds a solution that the evidence has not yet justified.

If you report counts, count distinct cases under a stated inclusion rule. Keep cases, participants, recordings and mentions separate. Repeated comments from one account are not independent cases. A claim such as “three of five cases discussed this problem” also needs a note about whether all five had an equal opportunity to discuss it.

Using Weeve to inspect recorded evidence

Weeve can help you explore saved interviews and review the sources behind a proposed comparison. Keep the relevant recordings together in a project, then ask a bounded question. The interview analysis workflow describes the product’s role and limitations.

For example:

Review the recordings in the Client Approval study. For each customer organisation, identify the approval route described, any reported wait and the workaround. Cite the source passages. Keep conflicting accounts separate and state where the topic was not covered. Do not treat each recording as a different customer.

Demonstration content: a sourced answer about a workshop. This illustrates source navigation, not a completed cross-case analysis.

Check the returned scope before using the answer. An assistant may have reviewed only part of the relevant material. Open the citations, inspect the surrounding passage and listen to retained audio where available. Verify speaker attribution and whether the passage describes an actual event or a hypothetical example.

Use the checked material to populate your own case matrix. Weeve is not a validated qualitative coding system, and a generated answer does not prove complete coverage, reliability or saturation. Local chat runs on your Mac; choosing optional ChatGPT sends relevant text to that provider. Match that choice to the permissions for your material.

How to know the comparison is ready to share

Someone who did not conduct the interviews should be able to trace a finding back to its cases and understand its limits. Before sharing, check that every case has a clear identity, every substantive cell has a source, missing information is labelled, and the most important exception appears beside the pattern.

Finally, ask what would change your conclusion. If no possible contrary evidence has been considered, return to the cases. A useful cross-case analysis leaves a reader with a defensible explanation and a specific next investigation, rather than a confident story detached from its sources.