Research synthesis
How to analyze customer interviews and decide what to do next
Turn interview notes into a clear explanation of what customers do. Follow a simple example, compare different answers and choose a useful next step.
After a round of customer interviews, start with the decision you need to make. Then look through the notes for examples that help you make it.
Suppose you are building a tool for maintenance teams. You interviewed people about ordering replacement parts because you want to know where the process breaks down. A list of quotes about “frustration” will not tell you what to build. You need to know what people did, why they did it and what happened next.
Write down what happened
Keep each useful note with its interview date and a link to the recording or fuller notes. Use quotation marks only when you have the person's exact words.
Compare these notes:
- “The customer doesn't trust the system.”
- “After submitting a parts request, they messaged their manager to ask who could approve it.”
The second tells you what the person did. The first is your explanation, which might be wrong. GOV.UK's note-taking guide recommends keeping observations separate from your interpretations.
Compare the reasons behind similar actions
Here is a fictional set of 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 do not establish that. The third already had the approver's name. The fourth was waiting for money.
You could summarize this as: “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. Keep the budget delay separate too. Grouping everything under “slow approvals” would hide differences that matter when choosing what to build.
Check your conclusion against the notes
Go back to every interview you used. Does it support the summary? Have you left out an answer that changes the explanation?
Ask a colleague to read the same notes and challenge your conclusion. GOV.UK's analysis guide recommends reviewing observations together and using them to develop findings and actions.
If you use AI to help sort the notes, check its summaries against the originals too. Ten comments from one person still represent one person's experience.
Choose something you can learn next
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. Showing an approver's name may not answer that question. Neither change would solve the separate budget delay.
Finish with a short note for your team: what you learned, which interviews support it, what remains unclear and what you will do next. Keep the links to the original notes so someone else can check your reasoning.