By Mehdi HassanMost teams are decent at running interviews and bad at what comes after. The notes sit in a doc, someone makes a sticky-note board, a readout happens, and three weeks later nobody can say which product change came from which conversation. This guide fixes the last mile with a decision log that ties each insight to a change you can point at.
What is research synthesis?
Research synthesis is the process of turning raw research data (interview notes, recordings, usability observations) into a small set of evidence-backed insights and the product decisions they support. It sits between collecting data and designing, and it's where most of the value of research is either captured or lost.
It's different from summarizing. A summary says what people said. Synthesis says what it means for the product: which problem is real, how often it showed up, and what you'll change because of it. If you're still deciding which research to run in the first place, start with our lean user research playbook for startups, then come back here once you have notes.
The test of good synthesis is simple. A week later, can an engineer who wasn't in the interviews read one line and know what to build, and why? If the answer is no, you have themes, not synthesis.
How do you synthesize user interviews step by step?
You synthesize user interviews in five passes: clean the notes, tag observations, cluster them, write insights, then decide. Each pass shrinks the material, so by the end a 10-interview study fits on one page.
Clean notes within 24 hours
After each session, rewrite shorthand into full observations while memory is fresh. Separate what the person said, what they did and what you inferred. Mark inferences clearly, because they're the first thing that turns into false certainty.
Split notes into atomic observations
One observation per card or row: 'Exported the report to a spreadsheet to share it with the CFO.' Not 'Reporting is painful.' Atomic notes can be regrouped later; summaries can't.
Tag each observation
Use a short tag set tied to your research questions: task, pain, workaround, goal, trigger, objection. Add the participant ID so you can count later. Keep the tag list under about a dozen or tagging becomes the project.
Cluster with affinity mapping
Group observations that describe the same underlying behavior, not the same words. Name each cluster as a sentence about the user ('They rebuild reports outside the app to control what leadership sees'), never a noun ('Reporting').
Write insights and decide
Turn the strongest clusters into insight statements with evidence counts, then hold a decision session where each insight gets a decision: change, test, park or reject. That's what goes into the log.
If your interviews were weak, synthesis can't rescue them. Leading questions produce clusters that confirm what you already believed. Our guide on running customer interviews that don't lie to you covers the questioning side.
How does affinity mapping work in research synthesis?
Affinity mapping is the clustering pass: you put atomic observations on a board and move them into groups by similarity until stable patterns appear. It works on a wall, in FigJam or in a spreadsheet; the tool matters far less than the discipline of grouping by behavior.
Three rules keep it honest. First, cluster bottom-up from the notes rather than starting with your planned categories, or you'll just sort data into the boxes you expected. Second, let a cluster split when it gets large; a group of 30 cards is usually three different patterns. Third, keep singletons visible in a 'loose ends' area. A single strong observation from your best-fit customer can matter more than a big cluster from people who'll never buy.
When you have more than one participant type, color-code by segment. A pattern that only appears in one segment is still useful, but it tells you who the decision is for.
How do you write an insight that leads to a decision?
A useful insight states a user behavior, the tension behind it and the evidence, in one or two sentences. 'Users want better reports' is an opinion. A hypothetical example of an insight: 'Finance leads export reports to spreadsheets before sharing them, because they don't trust leadership to read raw numbers without context (7 of 10 participants)' is an insight.
Use this shape: [Who] [does what] because [underlying reason], which means [consequence for the product]. Evidence: [count, segment, strongest quote]. The count is from your own study, so report it as 'seven of ten participants', never as a percentage that implies a representative sample. Ten interviews tell you a pattern exists, not how common it is in your market.
Jobs-to-be-done framing helps here, because it forces the 'because'. If your team already thinks in jobs, our article on jobs to be done for product design shows how to carry a job statement into interface decisions.
For example, suppose: one cluster written three ways
Hypothetical cluster: six observations about people copying data out of the app before a weekly meeting.
Weak: 'Users need export.' This jumps to a solution and loses the reason.
Better: 'People copy data out before weekly meetings.' True, but it doesn't say why or what to do.
Strong: 'Team leads copy data into slides before weekly meetings because the in-app view can't be filtered to just their team, which means our shareable view is failing its main job. Evidence: 6 of 9 participants, all team leads.' Now the decision is obvious: test a filtered, shareable meeting view before building a generic export.
What is a research decision log and what goes in it?
A research decision log is a running table where each row links one insight to one decision and the design change it produced. It's the artifact that turns insights into decisions you can trace, and it outlives the readout deck by months.
Column | What goes in it | Example |
|---|---|---|
ID | Short reference for tickets | INS-014 |
Insight | The one-sentence insight statement | Team leads rebuild reports in slides |
Evidence | Count, segment, link to notes | 6 of 9, team leads |
Decision | Change, test, park or reject | Test |
Design change | The screen, flow or copy it affects | Filtered shareable meeting view |
Owner | One named person | PM |
Status | Open, in design, shipped, validated | In design |
Revisit | What would make you reopen it | Export usage stays flat after launch |
The 'reject' and 'park' rows matter as much as the 'change' rows. They stop the same idea from being re-argued every quarter, and they record why. Link each design change to its ticket so the trail runs both ways: from the ticket you can find the evidence, and from the insight you can find what shipped.
After something ships, close the loop. A usability test with five users or a metric from your UX metrics framework moves the row from 'shipped' to 'validated', or reopens it.
How do you avoid bias when you synthesize research?
You reduce bias by synthesizing with at least two people, separating observation from interpretation, and actively looking for evidence against your favorite insight. You can't remove bias, but you can make it visible.
- Pair up. Two people tagging the same three interviews, then comparing, catches more drift than one person tagging everything carefully.
- Count disconfirming evidence. For each insight, write how many participants contradicted it. If nobody did, check whether you asked.
- Watch the loud participant. One articulate person can dominate a board. Evidence counts by participant, not by number of sticky notes.
- Mind your sample. If you recruited from friendly early users, say so in the log. Our guide to recruiting research participants helps widen it next round.
If synthesis never changes your mind, you ran a confirmation exercise, not research.
How long should research synthesis take?
Synthesis usually takes about as long as the interviews themselves, and skipping that time is the most common reason research gets ignored. A practical rhythm is to clean and tag after each session, then block one focused working session for clustering and one for decisions.
Keep the decision session small: the PM, a designer, an engineer and whoever ran the interviews. Walk through insights in order of evidence strength and force a decision on each before moving on. If a decision needs data you don't have, the decision is 'test', and the log says what test.
If you want outside help turning a research pile into screens, our brand and design sprint is $3,000, fixed: a redesign direction plus 10 website or product explorations in Figma, built on what your research says. It's design only, so your team or ours builds afterward. Not sure yet? A free 30-minute intro call is enough to tell whether it fits.
