How to analyse customer interviews: a worked example

You have six interview recordings, forty pages of notes and a meeting on Thursday. Someone asks, "So what did we learn?" and the honest answer is a handful of vivid quotes and a feeling. Feelings lose arguments.

Analysis is the work that turns those quotes into something you can defend. You do not need special software or a bigger sample to start. You need a fixed sequence and the discipline to follow it:

1. Put every transcript in one place, in one format.
2. Read all of it once without coding.
3. Code twice: first openly, then against your decision.
4. Group the codes into a theme.
5. Try to break the theme with a counterexample.
6. Count people, not mentions.
7. Write a finding that states its own limits, and hand over the table behind it.

This guide walks through all seven on a small worked example, then gives you the table to copy. It applies to customers, users, your own staff and partners alike. That guide covers judging a finding: what makes a customer insight evidence-backed. This one covers producing it. You already have the transcripts, and the question is what to do with them.

Put it in one place and read it cold

Start with one document or spreadsheet. One row per excerpt, with a participant code (P1, P2, P3) instead of a name, and the exact words the person used. Do not tidy their grammar. Do not paraphrase yet.

Keep what was said apart from what you think it means. The GOV.UK Service Manual tells teams to use¹, recording what was seen or heard rather than its meaning. The same government research community explains why: capture², so you do not unwittingly bias your findings. Your interpretation goes in a separate column, later.

Then do something that feels wasteful: read everything once with no highlighter and no coding. The framework approach described by Pope and colleagues starts with³, before any labels are applied. Your only output from this read is a short list titled "What surprised me." Write it down now, because surprises are where your assumptions show.

If two people ran the interviews, each reads independently before you compare lists. Disagreement at this stage is cheap. Disagreement after you have printed the slides is not.

Code twice: open first, then against the decision

A code is a short label for what an excerpt is about. "Rewrote the message three times" is a code. "Needs automation" is a conclusion, and conclusions do not belong in the code column.

Make two passes.

Pass one, open. Ignore your decision. Label what is in the text, in plain words close to the participant's own. Do this for every excerpt, including the ones that seem irrelevant. This is how you find what you did not go looking for.

Pass two, against the decision. Write the decision at the top of the sheet as a question: "Should we build X?" Go back through the excerpts and mark each one as for it, against it, or neither. This is how you avoid drowning in interesting but useless labels.

Do both. If you only start from the decision, you find what you went looking for. If you only code openly, you finish with sixty labels and no recommendation.

The worked example: six freelancers, one decision

Here is an invented example to show the method. A three-person team makes invoicing software for freelancers. They must decide whether to build automatic late-payment reminders. They interviewed six freelancers from their own customer list and asked each one to describe the last time an invoice went unpaid. Everything below, including the people, is made up.

The decision question: Should we build automatic late-payment reminders?

Look at what the codes did. E1 got two, because one sentence held two ideas. E5 also got two, and neither is "against automation". That would be a conclusion, and the open pass is not allowed to reach one yet. E6 got TONE-WORRY only because P5 says why they avoid it. "I dread it" alone would have been AVOIDANCE and nothing more. A reason that is not in the words cannot go in the code.

The Decision column is pass two. Here "for" means the excerpt points towards some kind of reminder help, and the rulings below sort out which kind. E5 is against. E4 is for as well: chasing is not P3's problem, but noticing who is overdue is, and that is reminder help of a different kind. E8 is neither, because there is nothing to chase.

Group the codes, then try to break the theme

A theme is a sentence about what several codes have in common. It is a claim about your data, so write it as a claim, not as a topic. "Reminders" is a topic. "Freelancers put off chasing because of how the message will land" is a theme.

Sort the codes into piles of similar meaning, and name each pile. The GOV.UK method has teams¹, then record the finding on a different note from the observations, so the evidence and your reading of it never blur together. Do the same in your sheet: themes in their own table, apart from the excerpts, and the finding written separately again.

In the example, three codes land in one pile.

DELAY is in neither row on purpose. It is the outcome the theme tries to explain, not a code to group. Do not throw away the unplaced pile. The excerpt that fits nowhere is where your counterexample hides.

Now attack your own theme. Pope and colleagues describe how analysis lets you³: excerpts that contradict what you think you have found. Do it deliberately, with three questions:

• Who had the outcome without the cause?
• Who had the cause without the outcome?
• Who would say the opposite?

Run them on the example. The outcome is delay (the DELAY code). P3 had it without the cause: thirty seconds to send, no worry, and the delay comes from forgetting to look. That is a different problem with a different fix. P1 has the cause without the outcome: the excerpts show forty minutes of rewriting, not a late reminder. P4 answers the third question, because they chase on day one and would reject an automated message outright. P6 sits outside the pattern altogether, with nothing to delay.

Now rule on the theme. For each counterexample, keep it, reword the theme, split it or drop it, and write down which and why. "P3 is just disorganised" is not an analysis. It is explaining the problem away. In the example:

• P1: reword. The cause shows up as rework, not delay. The theme becomes "Freelancers delay or rework a reminder because of how it will land." DRAFTING-TIME now counts as an outcome, like DELAY.
• P3: split. There are two causes of delay, worry and forgetting. The theme covers only worry. Forgetting becomes its own, smaller theme.
• P4: keep. They do not delay, so they do not break the theme. They stay on the sheet as a counterexample to automatic sending, and the finding reports them.
• P6: drop. They had nothing to chase. They stay out of the people the theme applies to.

Count people, not mentions

Counting is allowed and useful, but count the right thing. Count people, not quotes. P1 said "pushy" twice. That is two mentions and one person.

The theme row counts excerpts (E1, E2, E3, E6), so E6 counts once even though it holds two of the theme's codes. That is why the three theme-code rows add up to 5 mentions and the theme row shows 4.

Choose the total before you count: everyone you interviewed, or only the people the question applied to. Say which, and show it. Here, "3 of 6 people interviewed" and "3 of the 5 who had an unpaid invoice" both describe the same data honestly, because P6 had nothing to chase. "4 of 8 quotes" counts mentions, and "50%" hides the total. Pope and colleagues, writing about qualitative analysis, accept that³. Keep them as plain counts of people with the total beside them.

Do not convert small counts into percentages. Nielsen Norman Group makes the point about small usability studies:⁴. A second Nielsen Norman Group article adds that such studies⁵. Treat interviews the same way. Your six people show you what kinds of things happen, not how often.

Also resist ranking themes by count alone. A theme held by one person can still be the most important thing in the data. Say how many, then argue why it matters.

Write the finding with its edges

A finding has five parts: what you saw, in whom, what it supports, what it does not support, and the counterexample that tested it. Copy this skeleton.

Of [number] people we interviewed, [number] [did the thing].
They were [who they are and how we found them].
This supports [the specific decision or next step].
It does not show [the claim a reader might wrongly draw].
The strongest counterexample is [participant and what they
said], which [kept, reworded or split] the finding.

For the example, the full finding reads:

Of six freelancers we interviewed, five had a recent unpaid invoice (P1 to P5). Three of those five (P1, P2, P5) delayed or reworked a reminder because they worried about how it would land. One (P3) delayed because they forgot to check, not because of worry. One (P4) chases on day one and said an automated message would feel impersonal to their clients. The sixth (P6) has predictable payers and nothing to chase. All six came from the team's own customer list, so we have not heard from freelancers who use no invoicing product.

This supports exploring help with the awkward first message, such as a drafted reminder the freelancer reviews and sends. It does not show that sending reminders automatically is the right form of that help, and P4 points the other way. A separate, smaller problem is noticing who is overdue. P3's forgetting is evidence for automatic help there, such as flagging overdue invoices or sending the reminder, and it has to be weighed against P4. We do not know how common either problem is among freelancers in general. The strongest counterexample, P3, split the finding: forgetting to check is a separate cause of delay.

Notice what that finding refuses to do. It does not say "most freelancers". It does not claim automation will work. It names the person who disagrees. A reader who disagrees with your conclusion can still check your work, because the scope is on the page.

The analysis table to copy

Build the table in three parts, in the same shape as the example, and fill it from the first read onward. The excerpt part holds evidence. The theme and count parts hold your interpretation. Keep them apart.

Excerpts, one row per excerpt:

Themes, one row per theme, plus an "Unplaced for now" row:

Counts, one row per theme and per code inside it, plus any code you split into its own theme:

Under the three parts, list each counterexample with your ruling (keep, reword, split or drop) and one line of why, as in the example.

Then hand your team three things, in this order:

1. The finding, written with its scope, as above. One paragraph.
2. The counterexamples and what you ruled on each. This is what turns "trust me" into "check me".
3. The table. Not every row, but enough that a sceptical colleague can pick any claim and trace it to an excerpt in under a minute.

Do not hand over a slide of the best quotes. The table lets people check the finding; a quote cannot. More on why in the evidence-backed guide.

If your next round of interviews needs better questions, start with how to ask questions that get past the surface answer. Better excerpts make every step above easier.

What this will not tell you

This method organises what your participants said. It cannot tell you how many people in your market behave the same way. Six interviewees are a group you picked, not a measured slice of a market, so treat any theme as a lead to test, not a measurement.

It also cannot remove your own bias. You chose the codes and the themes. Ask a second person to code independently, so you can compare what each of you saw. The counterexample step helps too, but neither makes you neutral. What the method does is make your reasoning visible, so someone else can disagree with it.

Finally, analysis works only with what was said. If the interviews led the witness or recruited only fans, no sorting will repair that.

Tonight, take one transcript, split it into excerpts, and fill in three columns: ID, excerpt, open codes. Related page: customer interviews.