The technique that transforms a wall of research notes into decisions you can act on

Affinity mapping — also called an affinity diagram — was developed by Japanese anthropologist Jiro Kawakita in the 1960s as part of his KJ Method, a framework for organising complex qualitative data. It entered design practice through usability research and was later formalised in interaction design methodology.

The underlying idea is simple: when you have too many individual observations to reason about, grouping them by similarity reveals patterns you couldn't see at the data-point level. What looked like 47 separate user comments becomes five or six distinct themes. Those themes are what you design for.

Nielsen Norman Group's documentation on affinity diagrams is where most UX teams encounter the method formally, even if the underlying logic is decades older.

The mechanics are deliberately low-tech:

1. Capture data points individually. After user interviews or observation sessions, write each distinct observation, quote, or behaviour on a separate sticky note — one idea per note. This is usually done digitally in FigJam or Miro, or on physical stickies for in-person sessions.

1. Put everything up at once. Every note from every session goes on a shared surface. At this point it looks like noise — that's normal.

1. Group silently first. Team members move notes into clusters based on similarity, without talking. Discussion too early anchors people to frameworks before the patterns have a chance to emerge naturally.

1. Name the clusters. Once groupings stabilise, give each one a descriptive name. Not 'navigation issues' — that's a category. Something like 'users don't know what has been saved vs what's still draft' — that's an insight. Specificity is what makes the output useful.

1. Identify hierarchies. Some clusters will contain sub-patterns. Nest them. What looks like one theme often contains two or three distinct problems that need separate solutions.

1. Prioritise. Which clusters appeared across the most participants? Which ones connect to workflows that are critical to the product's core value?

Affinity mapping earns its time investment when you have a substantial amount of qualitative data from multiple participants and you're not yet sure what the dominant themes are.

It's most valuable after:

• A round of user interviews (five or more sessions)
• Observation or contextual inquiry studies
• Open-ended survey responses that need categorisation
• Multi-team research programmes where different people collected data independently

It's less valuable when:

• You have fewer than three or four sessions and the themes are already obvious
• The research questions were very narrow and the findings are already structured
• You're under time pressure and need directional findings fast

The technique doesn't generate insights automatically. It creates conditions where insights are easier to see. If the underlying research data is thin, affinity mapping won't make it richer — it'll just organise the thinness more neatly.

Two patterns consistently undermine affinity mapping sessions:

Grouping by topic instead of insight. 'Navigation', 'Onboarding', 'Pricing' are topics — not insights. An affinity map organised by topic tells you what users talked about, not what they experienced. The clusters need to capture the observation itself: 'Users return to the homepage when they're lost, not the back button' is an insight. 'Navigation issues' is a filing system.

Including interpretations instead of observations. Stickies should contain what users said or did, not what the researcher thinks it means. 'User seemed frustrated' is better captured as 'User sighed, reread the instruction twice, then selected the wrong option and had to undo it.' The interpretation comes later, from the pattern — not from individual notes.

The other common pitfall is running it as a solo activity. Affinity mapping done alone produces one person's view of the data. Done with the full product team — designers, researchers, product managers, engineers — it produces shared understanding, which is often more valuable than any specific insight. When the people who'll make the product decisions have seen the raw data and participated in organising it, they don't need to be convinced by the findings.

Affinity mapping is infrastructure for {{LINK:jobs-to-be-done}} analysis, persona work, and design prioritisation — not a deliverable in itself. The map is a means to an end.

Done well, it achieves something research reports rarely do: it gets the whole team looking at the same evidence and drawing the same conclusions. That alignment is often worth more than the synthesis itself.

For teams running their first structured research programme, it pairs naturally with {{LINK:usability-testing}} output and interview data. The specific method matters less than the discipline of doing synthesis at all — most product decisions made without it are just strongly held opinions dressed up as insight.

Related: {{LINK:jobs-to-be-done}}, {{LINK:usability-testing}}, {{LINK:ux-benchmarking}}