After twelve user research interviews with analytics-dashboard customers, how do you synthesise raw notes into findings the team trusts and acts on, without confirmation bias?
answer
- one observation per note
- cluster bottom-up, name clusters last
- observation, theme, insight, implication
- hunt for disconfirming evidence
- evidence-linked, prioritised, owned
basics
~20 sBreak notes into single observations tagged by participant, cluster them bottom-up into themes, then state insights and implications backed by evidence. Counter confirmation bias by synthesising as a team, seeking contradicting evidence, and reporting breadth honestly rather than as percentages.
solid answer
~50 sStart by turning each session's notes into **atomic observations** — one fact, quote or behaviour per note, tagged with the participant and their segment — keeping observation separate from interpretation. Build an **affinity map**: group notes bottom-up by similarity and name the clusters only once they form, instead of sorting into the categories you expected. Move from clusters to **themes**, from themes to **insights** (what is happening and why) and from insights to **implications** for the product. Guard against **confirmation bias** by synthesising with engineers and product managers, deliberately looking for evidence that contradicts each theme, keeping notes that fit nowhere, and stating how many participants support a theme without turning twelve interviews into percentages. Triangulate with analytics and support data, prioritise findings by breadth, severity and business impact, and share them linked to their evidence so the team can act.
go deeper
Recall the chain from observation to theme to insight to implication, and that an affinity map clusters single observations bottom-up.
Explain how to atomise notes, separate observation from interpretation, name clusters with statements, and report breadth without percentages.
Show how you counter confirmation bias — team synthesis, written hypotheses, disconfirming evidence, triangulation — and turn themes into prioritised, evidence-linked findings with owners.
Make synthesis a team habit tied to decisions, so research findings reach the people who act on them and the organisation stops re-learning the same things.
## From notes to findings **Synthesis** is the step that turns raw research data into findings a team can act on. After twelve interviews with customers of a B2B analytics dashboard, you have hours of recordings and pages of notes. Without a method, the findings become whatever the loudest participant or the researcher's prior belief suggested. The usual chain has four steps: | Step | What it is | Example | |---|---|---| | **Observation** | One fact, quote or behaviour from one participant | P4 exported to a spreadsheet to group by fiscal quarter | | **Theme** | A pattern across observations | Analysts leave the builder when date grouping does not match their calendar | | **Insight** | What is happening and why, with its consequence | Fiscal calendars differ by customer, and the builder assumes calendar quarters, so reports are finished elsewhere | | **Implication** | What it means for the product | Supporting custom fiscal periods may recover a large share of abandoned reports | ## Building the affinity map **Affinity mapping** is the most common technique for clustering qualitative data: 1. **Atomise**: write each observation on its own note, tagged with the participant ID and segment, and use verbatim quotes where possible. 2. **Separate observation from interpretation**: "P7 said the filters are 'useless'" is an observation; "the filters are bad" is an interpretation. 3. **Cluster bottom-up**: put notes that seem related next to each other without deciding the categories first. 4. **Name clusters last**, with a sentence that says something, such as "date grouping does not match customers' calendars", not a label like "filters". 5. **Split and merge** clusters as they grow; a cluster with notes from only one participant is an anecdote until more support it. 6. **Keep the misfits**: notes that fit nowhere may be the start of a theme nobody expected. ## Guarding against confirmation bias **Confirmation bias** is the tendency to notice and weight evidence that supports what you already believe. Synthesis is where it does the most damage. - **Synthesise as a team**: engineers, designers and product managers who watched sessions bring different readings and share ownership of the result. - **Write down hypotheses before synthesis**, so you can check whether you are simply finding them again. - **Look for disconfirming evidence** for every theme: who did not behave this way, and why? - **Report breadth honestly**: "seven of twelve participants" describes the sample; "58 percent of users" claims a population estimate twelve interviews cannot support. - **Note segments**: a theme found only among new accounts is a different finding from one found everywhere. - **Triangulate** with analytics, support tickets or a follow-up survey before betting heavily on a theme. ## Making findings actionable - **Prioritise** by how widespread a theme is, how severe its consequence is, and how much it matters to the business goal behind the study. - **Link every finding to evidence**: quotes, clips and participant counts, so readers can judge its strength. - **State confidence**: strong, moderate or tentative, and what would raise it. - **Keep the report short**: a handful of prioritised findings beats a long list of observations. - **Hand over to an owner**: each finding should reach the team that will decide what to do, with a follow-up date. ## Common failures - Sorting notes into the categories of the discussion guide, which guarantees the findings mirror the questions. - Presenting a list of participants' feature requests as findings. - One researcher synthesising alone and presenting conclusions the team did not see forming. - A finding repository nobody reads, because findings were never tied to decisions. Synthesis is where research earns its cost: the same twelve interviews can produce a list of complaints or a prioritised explanation of why the product fails its users.
- How do you handle a finding that contradicts what a senior stakeholder believes?Present it with its evidence — quotes, clips, participant counts and segments — and state your confidence honestly. Invite the stakeholder to watch sessions or recordings. Propose a cheap way to test it further, such as an analytics check or a small survey. The goal is a decision on evidence, not winning the argument.
- When is a single participant's observation worth reporting?When its consequence is severe — data loss, a compliance risk, a blocker for a key customer segment — or when it is a surprise nobody anticipated and worth checking. Report it clearly as a single observation with low breadth, and propose how to find out whether it is more widespread, rather than presenting it as a theme.
saying these in an interview costs you the question
- Sorting notes into the discussion guide's topics is an unbiased way to synthesise.
- Twelve interviews can be reported as percentages of the user base.
- Cluster names should be fixed before sorting so every note has a home.
- Notes that fit no cluster are noise and can be discarded.
- A list of participants' feature requests is the synthesis output.