How to synthesise customer interviews into a useful decision.

1. Write the question and the boundaries of this round.

Start the synthesis document with the decision you were trying to inform. For example: should the next prototype help first-time volunteers choose an available role, or help them contact a coordinator? Those are different jobs. Without a question, the most memorable comment can become the priority simply because it is memorable.

Record whom you spoke with, how you found them, the experience you asked about, and what you did not investigate. Use participant codes in the working summary rather than names. If all participants came through your own network, say so. If nobody used an earlier version, do not describe their accounts as feedback on that version. A clear boundary makes the eventual recommendation easier to challenge constructively.

2. Separate an observation, an interpretation, and an idea.

GOV.UK's analysis guidance distinguishes observations, findings, and actions. Keep that separation in your own notes. An observation records something you heard or saw; a finding explains a pattern; an action proposes what to do. These should be connected, but they should not silently become interchangeable.

Consider three deliberately invented notes. Observation: P02 said they sent a message because the page did not say which roles were still available. Interpretation: uncertainty about availability may delay choosing. Idea: add an availability label. The first statement is a participant's account, not an observed delay. The second is a tentative explanation. The third is one possible response, not a requirement handed down by the interview.

Give each observation an ID and a pointer to the source note or permitted recording timestamp. Distinguish exact quotations from paraphrases. If you cannot check the wording, remove quotation marks. If an interviewer supplied an answer or showed a solution, retain that context beside the response rather than polishing it away.

3. Group related observations, then look for the awkward cases.

Place observations about the same difficulty together. You might use a document, spreadsheet, or physical cards; the tool matters less than keeping each source attached. Start with practical labels such as choosing a role, finding the meeting place, or asking for help. Rename a group if its contents no longer fit. A theme is a working container, not proof that everyone has the same need.

Then deliberately search for contradictions. Who completed the task without that difficulty? Did a person have prior experience, a helpful friend, a different device, or information the others lacked? Keep an isolated but consequential barrier visible too. A concern affecting access or safety should not disappear because it was mentioned only once. Do not use the largest pile of notes as an automatic voting system for the roadmap.

4. Write a finding with enough context to be challenged.

Use a simple structure: in this situation, these participants described or demonstrated this difficulty; the consequence appears to be this; here is the evidence and here is what remains uncertain. Avoid broad labels such as people hate forms. A narrower finding about a specific question, task, or handoff gives you something you can change and examine.

Count participants rather than quotations when describing how many people raised a topic. One talkative participant might generate ten notes. Do not turn those into ten independent votes. Counts from a small, selected interview group describe that group; they are not population percentages, and silence is not evidence that a problem was absent. If the topic was not asked consistently, state that before making any comparison.

5. Work through one finding without inflating the conclusion.

Here is a hypothetical synthesis, not reported SIX33 research. Four first-time volunteers describe their latest attempt to choose a role. P01 and P02 say they contacted a coordinator because availability was unclear. P03 says an experienced friend explained the options. P04 chose directly from a recently updated list. These are accounts of past events, not observations of the four people using a prototype today.

A supportable finding is that two interviewees described needing extra contact to resolve availability, while the other accounts suggest that timely information or personal help may matter. An unsupported headline is that half of all volunteers abandon signup. Nobody established that population rate, and contacting a coordinator is not the same thing as abandoning a task.

The next decision could be to prototype a clearly dated list of available roles before building a larger matching system. The next test would observe whether new participants can choose an appropriate role and identify how to confirm it, recording assistance and misunderstandings separately. That test still needs its own scope and decision rule. The interviews suggested the uncertainty; they did not settle the solution.

6. Close with a decision, an owner, and a checkable next step.

For each important finding, write whether you will investigate, change something, leave it unchanged for a stated reason, or stop a proposed direction. Name who owns the next step and when the decision will be revisited. Keep a link to the prototype or brief version so a later team member can understand what the recommendation actually changed.

Share the smallest useful summary with the people who need it. Keep raw notes and identifying details within the access and retention arrangements agreed with participants. Permission to discuss an experience privately is not permission to publish a quotation, identifiable story, or recording. A public update can describe the decision and its limits without exposing the people whose experiences helped you make it.