UX/UI Design, A to Z ┃ 2.1 Affinity Diagrams: Finding the Pattern in the Pile

Welcome back! Good to have you :)

An affinity diagram groups scattered qualitative data by shared meaning, so a team can see the themes and needs hiding inside it.

You come back from five interviews with two hundred fragments. Quotes, half-observations, moments where someone hesitated.

The temptation is to skim them, spot something that confirms what you already suspected, and announce what to build. That isn't analysis. That's your existing opinion wearing evidence as a costume.

An affinity diagram is the slow way. It's also the only way that survives contact with a stakeholder asking "what makes you say that?"

Welcome to Define

Everything so far has been gathering. In Discover, you widened — interviews, observation, usability tests, all of it piling up.

Define is where you narrow. Not by throwing data away, but by finding what repeats, what matters, and what problem is actually worth solving.

The affinity diagram is the workhorse of this phase. But keep one thing in mind: design processes are never as linear as the diagram suggests. You'll regroup notes, go back for more research, and revise your definition. That's the process working, not failing.

What Is an Affinity Diagram?

An affinity diagram breaks scattered information — user quotes, observations, problems, ideas — into small units, then clusters those units by shared meaning to reveal common themes.

Where it comes from

The technique traces back to the KJ Method, developed in the 1960s by Jiro Kawakita, a Japanese anthropologist who needed a way to make sense of scattered notes from ethnographic fieldwork.

That origin is the point. It was built for messy qualitative field data that refuses to fit tidy categories — which is exactly what a pile of interview notes is.

One important caution

An affinity diagram is not a statistics tool. It doesn't prove that something matters because five people said it. Frequency is one signal among several — severity, context, and impact matter too.

Five people saying a button looks dated is not more important than one person who couldn't complete checkout with a screen reader.

When to Use It

• After interviews or observation, when you have a lot of notes to analyze together
• When team members are carrying different interpretations and you need shared understanding
• When you're defining a problem and need to surface repeating needs and pain points
• When a brainstorm produced more ideas than anyone can hold in their head

How to Build One

Paper sticky notes on a wall work fine. So does FigJam or Miro. The method is the same.

1. Gather your raw data

Pull together transcripts, interview notes, observation records, test sessions. Tag each note so you can trace it back to its source.

P01, session 2, checkout flow

Strip out names, contact details, and anything personal that analysis doesn't need.

2. Break it into single units

One note, one thing. One quote, one behavior, one problem, or one need. Keep the user's own words where you can, and don't mix in your interpretation or your solution.

❌ "Needs a timer and voice guidance." — that's a solution you've already picked

✅ "When I'm cooking I can't keep scrolling the screen." — P03

3. Spread everything out and read it

Lay all the notes out before you decide on a single category. Let the team read the whole set first, absorbing meaning and context.

• Don't force data into categories you brought with you
• Keep the ambiguous and contradictory notes — don't quietly discard them

4. Group by meaning

Move similar notes next to each other. Reshuffle as often as you need. Group by what it means, never by who said it.

Try this:

Have everyone group in silence first, then compare and discuss. It takes five extra minutes and it stops the loudest person in the room from anchoring everyone else's interpretation.

Split groups that grow too large into sub-groups. For groups of one or two, ask whether it's noise — or a signal nobody else happened to mention.

5. Name each group with a sentence

Write what the notes in that group are collectively saying. A short, specific sentence about the user's situation — not a noun, not a feature name.

❌ "UI improvements"

✅ "New cooks lose their place in long recipes."

This step does more work than any other. A group titled "Navigation" tells you nothing. A group titled with a sentence has already half-written your problem statement.

6. Turn patterns into insights

For each group, write one or two sentences answering: which users, in what situation, struggle with or need what — and why does it matter?

Every insight must trace back to raw data.

Observation: Users repeatedly scrolled the screen while cooking.

Interpretation: With their hands busy, checking information carries a real cost.

Insight: New cooks lose their place in long recipes because of dense text and frequent scrolling — they need information delivered short and sequential.

 

7. Review, then connect forward

Check with the team that the groups and insights honestly reflect the raw data. Look for counter-examples and exceptions, not just the comfortable patterns. Then connect out to problem statements, personas, journey maps, or new research questions.

If you need to know how often or how many, that's a different question — go verify with surveys or log data.

Insight Is Not Solution

This is the failure mode that ruins otherwise good analysis, so it gets its own heading.

"Users lose their place while cooking" is an insight. "Build voice guidance" is one of many possible solutions.

Fix the solution too early and you've quietly narrowed the design space before anyone explored it. Voice guidance might be right. So might step-by-step screens, a persistent progress indicator, or larger text. You can't compare options you never generated.

Define the problem in this phase. Compare solutions in the next one.

A Worked Example: A Cooking App

Notice that the design direction names areas to explore, not features to build. That's deliberate.

Six Mistakes Beginners Make

1. Grouping by participant

• The goal is shared meaning across users, not a tidy file per person.

2. Deciding categories first

• You'll only see what fits the assumptions you brought.

3. Writing several things on one note

• Now it belongs in three groups and lands in none.

4. Treating frequency as importance

• How often something comes up and how badly it hurts are different measurements.

5. Jumping straight to features

• You've locked in an answer before understanding the question.

6. Discarding outliers

• A single user's experience can expose an accessibility failure or a serious edge case. Rare isn't the same as unimportant.

Checklist Before You Finish

  Does each note contain exactly one unit of meaning?
  Can every note be traced to a participant and session?
  Did the grouping follow the data, rather than categories you brought in?
  Does each group title describe a user situation instead of naming a feature?
  Is every insight backed by an actual quote or observation?
  Have you reviewed the outliers and the notes that wouldn't group?
  Are facts, interpretations, hypotheses, and solutions clearly separated?

What to Show in Your Portfolio

A screenshot of the finished board is the least interesting thing you have.

Show how the raw data was broken down, how the groups changed as you worked, and what evidence produced each insight. Intermediate versions of the board, the discussion that reshaped them, the reasoning behind your grouping — that's what demonstrates analytical thinking and collaboration.

A neat final board proves you can arrange sticky notes. The messy middle proves you can think.

Key Takeaways

• An affinity diagram groups qualitative data by shared meaning to reveal themes and needs.
• It's an interpretive tool, not a statistical one. Frequency, severity, and impact are separate questions.
• One note, one unit of meaning — the user's words, not your interpretation.
• Read everything before you categorize anything. Pre-set categories only confirm what you already believed.
• Group titles should be sentences about users, not feature names. This single habit changes the quality of everything downstream.
• Every insight traces back to raw data. If you can't point to the note, it isn't an insight.
• Insight ≠ solution. Define the problem now; compare answers later.
• Keep the outliers. One person's blocked path can matter more than five people's minor annoyance.

Before You Go

A 10-minute exercise

Here are six raw notes from a fictional study of a transit app.

• "I checked the app three times before leaving because I wasn't sure the time was current." — P01

• "I always end up asking someone on the platform if it's the right train." — P02

• "The delay showed up on the screen but not in the app." — P03

• "I take a photo of the map because the signal drops underground." — P04

• "I got off one stop early once and just walked the rest." — P02

• "I don't trust it enough to cut my departure fine." — P01

1. Group them by meaning. Two groups will probably emerge; some notes may resist.

2. Give each group a sentence title about the user's situation.

3. Now check your titles. Did either one name a feature or a screen? If so, rewrite it as a sentence about what the user experiences.

(Watch note 5 in particular. It's the odd one out — and the outlier is often where the interesting question lives.)

What's Next

Empathy Maps: Say, Do, Think, Feel

Your affinity diagram tells you what patterns exist across users. Next we go the other direction — deep into a single user's experience.

We'll cover the four quadrants of an empathy map, how to build one from research data rather than imagination, and what it catches that an affinity diagram misses: the gap between what people say and what they actually feel.

If this helped, stick around — follow the blog for the next one, and send it to a friend who's just starting out.

Thank you! 🙌