# Synthesize with affinity mapping

> Turn interview transcripts and raw observations into themes and insights with an affinity diagram — the bridge between collecting research and acting on it.

Source: https://uxspot.io/affinity-mapping

<section id="affinity-mapping">
<div id="what">
<h2>What is 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>After a round of interviews you're left with pages of transcripts, and somewhere inside them are the insights you ran the research for. Affinity mapping is how you get them out. <strong class="highlight">An affinity diagram groups individual observations into clusters of related ideas, so that themes emerge from the data instead of being imposed on it.</strong></p>
<p>The method is deliberately simple: every observation, quote, or data point goes on its own note; notes that feel related get moved next to each other; each cluster gets a name once — and only once — a pattern is actually visible. The power is in the constraint. <strong class="highlight">Because you sort observations before naming themes, the themes come from what participants actually said, not from what you expected to hear.</strong></p>
<p class="blockquote">One observation per note, sort first, name last. Everything else about affinity mapping is detail.</p>
</div>
<div id="run">
<h2>Run an affinity mapping session</h2>
<p><strong>Harvest your notes.</strong> Go back through your interview transcripts and pull out every distinct observation: a verbatim quote, a behavior you saw, a frustration a participant mentioned. Write each one on its own sticky note — physical or digital — and tag it with the participant code, like P3, so you can trace any note back to its source.</p>
<p><strong>Sort without talking.</strong> Spread the notes out and start grouping the ones that feel related. If you're mapping as a team, do the first pass silently — <strong class="highlight">silent sorting stops the loudest voice in the room from deciding what the themes are before the data does.</strong> It's fine to move a note that someone else has already placed; notes should keep moving until the groups feel stable.</p>
<p><strong>Name the clusters.</strong> Once the groups settle, give each one a short, descriptive label — a theme. Aim for labels that summarize the observations underneath, like "Users don't trust the payment step," rather than vague buckets like "Checkout stuff." A good test: <strong class="highlight">if you read only the label, you should still learn something true about your users.</strong></p>
<p><strong>Handle the leftovers honestly.</strong> A few notes won't fit anywhere. Resist the urge to force them into a group — park them to one side. An outlier can turn out to be the first signal of something your next study should chase.</p>
</div>
<ul>
<span>keywords</span>
<li>#Observations</li>
<li>#SilentSort</li>
<li>#Themes</li>
<li>#Outliers</li>
</ul>
<div id="insights">
<h2>From clusters to insights</h2>
<p>A named cluster is a theme, not yet an insight. The last step is to ask, for each theme, what it means for the design: what need, obstacle, or motivation does this group of observations reveal? <strong class="highlight">An insight states what you learned and why it matters — "Participants abandon the form because they can't tell which fields are optional" — in a sentence a teammate could act on.</strong></p>
<p>These insights feed everything that follows in the process: they become the raw material for <a href="/empathy-maps">empathy maps</a>, the evidence behind <a href="/identify-pain-points">pain points</a>, and the "because" clause of your <a href="/define-problem-statement">problem statement</a>. And the method returns later, too — the same clustering pass turns usability-test observations into findings when you <a href="/synthesize-test-results">synthesize test results</a>.</p>
</div>
</section>