Turn raw interview notes into themes with an affinity map, then capture what you learned in an evidence-based persona.
Why it matters
After five interviews you might have a hundred notes. Raw notes do not tell a team what to build. Synthesis is the work of turning those notes into a few clear insights that everyone agrees on. Two of the most common synthesis tools are the affinity map, which groups observations into themes, and the persona, which describes a typical user in a way the whole team can remember.
The core idea: bottom-up grouping
An affinity map is built from the bottom up. You do not start with categories and sort notes into them. You start with individual observations and let the groups emerge from what is actually there.
- One observation per note. Write each fact, quote or behaviour on its own sticky note (paper, or a free whiteboard such as FigJam's free plan). Add the participant code (P1, P2...) so you can trace it back.
- Cluster. Put notes that feel related next to each other. Do not name the groups yet. Move notes freely.
- Name the clusters. Once clusters settle, give each one a short label written as a statement from the user's point of view, for example "I only remember due dates when it is too late" rather than "Reminders".
- Group the groups. Related clusters form larger themes.
- Write insights. For each theme, write an insight: what is true, why it matters and how strong the evidence is ("4 of 5 participants").
Doing this with two or three people is better than alone: others will see connections you miss, and the team ends up owning the findings.
Worked example: bill splitting
Notes from five interviews about splitting shared bills included:
- P1: "I screenshot the bill and send it to the group chat."
- P2: Keeps a spreadsheet; housemates never look at it.
- P3: "I don't want to be the one who nags."
- P4: Paid the full internet bill for three months and gave up asking.
- P5: "We use an app but only one of us actually logs things."
- P1: "Chasing money feels awkward with friends."
Clusters that emerged:
| Cluster label | Notes | Count |
|---|---|---|
| "Asking for money feels awkward" | P1, P3, P4 | 3 of 5 |
| "One person does all the tracking" | P2, P4, P5 | 3 of 5 |
| "We already use chat for everything" | P1, P5 | 2 of 5 |
Insight: The social cost of asking is a bigger problem than the maths. One housemate ends up as the unpaid bookkeeper and often absorbs costs to avoid conflict. That is a far more useful starting point than "people need a calculator".
Personas
A persona is a short, realistic profile of a type of user, based on research. It helps a team make decisions by asking "would this work for Sam?" instead of "would I like this?". A useful persona fits on one page and includes:
- A name and a short descriptive line ("Sam, the reluctant house bookkeeper").
- Context: situation, devices, how often they face the problem.
- Goals: what they are trying to achieve.
- Pain points: what gets in the way, linked to your themes.
- Behaviours and workarounds you observed.
- A real (anonymised) quote from an interview.
Sam, the reluctant house bookkeeper
Shares a flat with three others; pays the rent and internet, then collects shares.
Goals: get paid back without awkward conversations; spend < 5 min a month on it.
Pain points: housemates ignore the spreadsheet; feels like a nag; absorbs costs.
Behaviours: screenshots bills into the group chat; keeps a private spreadsheet.
Quote: "I don't want to be the one who nags."
Evidence: themes from 4 of 5 interviews.
Leave out details that do not affect design decisions. A favourite colour or star sign adds nothing and makes the persona feel fictional.
Some teams prefer lighter archetypes or proto-personas (written from assumptions before research). Proto-personas are fine as a starting point if they are clearly labelled as assumptions and replaced once you have data.
Common mistakes
- Sorting into pre-made categories. You only find what you expected. Let groups emerge.
- Multiple ideas per note. Split them, or the note cannot move to the right cluster.
- Topic labels. "Payments" says nothing. "I don't trust the app to remember who paid" is an insight.
- Invented personas. A persona with no research behind it is fiction that sounds like evidence.
- Too many personas. Start with one primary persona; add another only if their needs truly conflict.
- Stereotypes. Base details on what you observed, not on assumptions about age, gender or background.
Quick recap
- Synthesis turns raw notes into a few insights the team agrees on.
- Affinity maps are built bottom-up: one note per observation, cluster, then label.
- Write cluster labels and insights from the user's point of view, with evidence counts.
- A persona is a one-page, research-based profile with goals, pain points, behaviours and a quote.
Try it
On the Do tab you will turn your interview notes into an affinity map and a persona.