How to analyze customer interviews: group by the reason

The best way to analyze customer interviews is to start with the decision you need to make, then sort what people did by why they did it. A pile of quotes about "frustration" won't tell you what to build. What people did, and why, will.

Here is a made-up example. You are building a tool for maintenance teams and interviewed people about ordering replacement parts, to find where the process breaks down.

1. Write down what happened, not what you think it means

Keep each note with its interview date and a link to the recording or fuller notes. Use quotation marks only for the person's exact words. Compare:

"The customer doesn't trust the system."
"After submitting a parts request, they messaged their manager to ask who could approve it."

The first is your explanation, which might be wrong. The second is what they did. GOV.UK's note-taking guide recommends keeping observations separate from your interpretations.

2. Compare the reasons behind similar actions

Here are fictional notes from four interviews:

Interview	What the person described
1	They submitted a parts request, then asked their manager who could approve it.
2	They also had to ask their manager who should receive the request.
3	Their request showed the approver's name, so they contacted that person directly.
4	They knew the approver but had to wait until the team had money available.

The first person needed to find the approver. The second needed to know who should receive the request. Those might be the same person, but the notes don't say so. The third had the approver's name. The fourth was waiting for money.

A fair summary: "One person needed help finding the approver; another needed help finding the right recipient for the request."

Check how requests are submitted and approved before proposing one fix for both. Filing all four under "slow approvals" would hide the differences that decide what you build. (It would make a very tidy sticky note, which is the problem.)

3. Try to break your conclusion

Reread every interview you used. Does each support the summary, and did you leave out an answer that changes it? Then ask a colleague to read the same notes and challenge you. GOV.UK's analysis guide recommends reviewing observations together and using them to develop findings and actions.

If AI sorts the notes, check its summaries against the originals too. Ten comments from one person still represent one person's experience.

4. Pick a next step that tests one explanation

For the first person's problem, show a sample request with the approver's name and ask: "Who would you contact to check on this order?" Watch whether they can answer without help.

For the second, ask where a new request needs to go and what makes that unclear; an approver's name may not answer it. Neither change solves the budget delay.

Then write your team a short note: what you learned, which interviews support it, what is unclear and what you will do next, with links to the original notes.