# Synthesize test results

> Learn how to turn raw usability test data into findings, insights, and prioritized recommendations your team will act on.

Source: https://uxspot.io/synthesize-test-results

<section id="data-to-decisions">
<h2>From raw data to decisions</h2>
<p>After a round of <a href="/usability-testing" class="redirect">usability testing</a> you are left with a pile of raw material: session notes, recordings, quotes, task timings, and half-legible scribbles. None of it is useful yet. <strong class="highlight">Synthesis is the work of turning what you saw into what the team should do, and it follows a ladder with four rungs.</strong></p>
<p class="blockquote">Observations become findings, findings become insights, and insights become recommendations. Each rung adds interpretation, so keep the rungs separate.</p>
<p>An <strong>observation</strong> is a single thing that happened in a session. A <strong>finding</strong> is a pattern of observations across participants. An <strong>insight</strong> explains why the pattern happens and what it means for users. A <strong>recommendation</strong> proposes what to change. When teams skip rungs, they leap from one participant's complaint straight to a redesign. Climbing the ladder deliberately keeps your conclusions honest and traceable back to evidence.</p>
<ul>
<span>keywords</span>
<li>#Synthesis</li>
<li>#Observations</li>
<li>#Insights</li>
<li>#Recommendations</li>
</ul>
</section>
<section id="capture-observations">
<h2>Capture clean observations</h2>
<img src="/images/rainbow-spreadsheet.webp" width="2400" height="1330" alt="Rainbow spreadsheet — observations in rows, five participants in colour-coded columns, a filled cell marking who exhibited each behaviour" title="Rainbow spreadsheet">
<p>Good synthesis starts during the sessions, not after. An observation records exactly what happened: what the participant did, what they <a href="/interview-transcripts" class="redirect">said word for word</a>, and where in the task it occurred. <strong class="highlight">Write down "tapped the back arrow three times on the payment screen," not "was frustrated" — behavior first, interpretation later.</strong></p>
<p>"Was frustrated" is already a conclusion, and conclusions written mid-session tend to reflect your expectations more than the participant's reality. Maybe they were frustrated. Maybe they were exploring, or double-checking a price. Capture the raw behavior and decide later, with the full pattern in view.</p>
<p>Verbatim quotes are your most persuasive material. "Wait, did that add it twice?" said by a real person carries more weight in a stakeholder meeting than any summary. Keep quotes in the participant's exact words, attributed with codes like P3 rather than names to protect privacy.</p>
<p>One observation per note. If a participant misread a label and then abandoned the checkout, that is two notes. Atomic observations are what make the next step possible.</p>
<ul>
<span>keywords</span>
<li>#NoteTaking</li>
<li>#VerbatimQuotes</li>
<li>#BehaviorNotOpinion</li>
</ul>
</section>
<section id="affinity-mapping">
<h2>Affinity mapping</h2>
<img src="/images/affinity-diagram.webp" width="2400" height="1330" alt="Affinity diagram template — observation notes grouped into three dashed clusters, each labelled as a theme" title="Affinity diagram">
<p class="blockquote">Affinity mapping is grouping individual observations by similarity so that patterns across participants become visible.</p>
<p>Put every observation on its own sticky note — physical or digital. Then start grouping: pick a note, find others that feel related, and place them together. When a cluster forms, give it a short descriptive label written as a sentence, such as "People don't notice the saved-address option," rather than a vague bucket like "Checkout."</p>
<p><strong class="highlight">Let the themes emerge from the notes instead of sorting notes into categories you decided in advance.</strong> If you start with buckets like "Navigation" and "Content," every note will find a home and you will learn nothing new. The surprising clusters — five participants doing the same odd workaround you never anticipated — are exactly what pre-made categories hide.</p>
<p>Map with a colleague when you can — disagreements about where a note belongs surface assumptions worth questioning. A cluster becomes a finding when it contains observations from multiple participants; one person struggling is a data point, three people struggling the same way is a pattern.</p>
<ul>
<span>keywords</span>
<li>#AffinityMapping</li>
<li>#Themes</li>
<li>#Patterns</li>
</ul>
</section>
<section id="theme-to-insight">
<h2>From theme to insight</h2>
<p>A theme tells you what kept happening. An insight goes further: it explains why it happened and points toward what to do about it. <strong class="highlight">A useful formula: observation, plus probable cause, plus consequence for the user.</strong></p>
<p>Compare the two. Theme: "Four of six participants missed the promo code field." Insight: "Participants missed the promo code field because it sits below the order summary where nobody looks at that stage, so people who came specifically for a discount believed the site did not honor it and abandoned the cart." The second version names a cause the team can act on and a consequence the business will care about.</p>
<div id="problems-vs-preferences">
<h3>Problems, requests, and preferences</h3>
<p>Not everything participants say belongs on the same list. A <strong>usability problem</strong> is evidence that the design blocked or misled someone. A <strong>feature request</strong> is a participant designing on the spot — "you should add a wishlist." A <strong>preference</strong> is taste — "I'd make this blue." Log requests and preferences separately as input for product discussions, but do not let them dilute your findings. <strong class="highlight">Your findings report what the design did to people, not what people would do to the design.</strong></p>
</div>
<ul>
<span>keywords</span>
<li>#Insights</li>
<li>#RootCause</li>
<li>#FeatureRequests</li>
</ul>
</section>
<section id="severity-ratings">
<h2>Severity ratings</h2>
<p>Not every finding deserves a sprint. Severity ratings let the team fix the worst problems first. A practical way to judge severity is frequency times impact: how many participants hit the problem, and how badly it hurt them when they did.</p>
<div id="severity-blocker">
<h3>Blocker</h3>
<p>The participant could not complete the task at all. In an e-commerce test, a payment form that rejects valid card numbers is a blocker. These get fixed before anything else ships.</p>
</div>
<div id="severity-major">
<h3>Major</h3>
<p>The task was completed, but with serious difficulty, wrong turns, or outside help. Most participants eventually found the filter menu, but only after scrolling past it twice and expressing doubt they were in the right place.</p>
</div>
<div id="severity-minor">
<h3>Minor</h3>
<p>A hesitation or small irritation that slowed people down without derailing them. A confusing icon that users figured out within a few seconds usually lands here.</p>
</div>
<div id="severity-cosmetic">
<h3>Cosmetic</h3>
<p>Noticed but harmless: a misaligned label, an awkward phrase. Worth a ticket, not a meeting.</p>
</div>
<p><strong class="highlight">A minor issue that every participant hit can outrank a major issue that only one participant hit — rate the finding, not the moment.</strong></p>
<ul>
<span>keywords</span>
<li>#Severity</li>
<li>#Prioritization</li>
<li>#FrequencyTimesImpact</li>
</ul>
</section>
<section id="share-findings">
<h2>Share findings people read</h2>
<p>The best synthesis fails if it lives in a document nobody opens. Write each finding as a short, self-contained card: one insight, its severity, the evidence behind it — participant count, one or two quotes, a link to the moment in the recording — and a suggested direction. One insight per card; if the headline needs the word "and," split it.</p>
<p><strong class="highlight">A three-minute highlight reel of real users struggling will change more minds than a forty-page report.</strong> Clip the moments where participants hit your top findings and play them in the share-out. Watching someone tap the same dead button three times creates a kind of conviction that a bullet point never will.</p>
<p>Invite the team to the share-out rather than emailing a file, walk through the top findings by severity, and end with the decisions you need. Turning those decisions into <a href="/iterate-designs" class="redirect">design changes</a> is the subject of the next article.</p>
<ul>
<span>keywords</span>
<li>#FindingsReport</li>
<li>#HighlightReel</li>
<li>#Storytelling</li>
</ul>
</section>
<section id="takeaways">
<h2>Takeaways</h2>
<p class="blockquote">Synthesis climbs a ladder: capture behavior without interpretation, group it until patterns emerge, explain the patterns, then prioritize by frequency times impact.</p>
<p>Keep observations atomic and verbatim, let affinity mapping surprise you, write insights that name cause and consequence, and share the result as short evidence-linked cards and a highlight reel — not a report that dies in a shared drive.</p>
</section>