Affinity diagramming: turning research notes into themes

An affinity diagram turns a pile of research observations and quotes into a few themes the team can act on. Each finding goes on its own note, the team clusters similar notes, names each cluster and picks where to start. It works when there is a clear focus question, labels that describe a problem, and a final check: every theme has to fit the data you actually collected.

What the diagram does

The Nielsen Norman Group article on affinity diagramming describes the method as organizing related observations, ideas and findings into distinct clusters. The notes can be physical or digital. The same method goes by other names: affinity mapping, collaborative sorting, the KJ method.

The article keeps it apart from card sorting. Card sorting is a research method for information architecture, where participants group the product’s labels. An affinity diagram groups what the team saw and heard. If your question is about menus and categories, start with the post on open and closed card sorting.

After research, the most common use is synthesis. Interviews, usability tests and diary studies produce dozens of notes, and someone has to say what they mean together.

Three steps: write, cluster, prioritize

The NN/g guide breaks the method into three steps.

Write the notes. Each person writes observations, user quotes or data points, one per note, in no order. This step is individual, so nobody pulls the group toward their own reading. A separate color for direct quotes and for observations helps later.
Cluster into themes. The team puts together notes about the same thing. Group by content first and decide the cluster name after. Small clusters still count and shouldn’t be dropped for having few notes.
Prioritize. With named clusters, the team picks a focus, through discussion or dot voting. Each chosen cluster gets a next action and an owner.

Two rules from the guide keep the diagram useful: don’t force clusters, and don’t overcategorize. When a note fits two clusters, duplicate it.

Start with a focus question

The article on the method’s pitfalls opens with the most common failure. The facilitator asks the team to sort by theme, and everyone stares at the wall. There are many valid ways to group the same notes, and each leads to a different conclusion.

The fix is to write a focus question before the session and keep it visible the whole time. In discovery, it can be broad, such as “what user needs are not met”. In a project with a set goal, it gets narrow, such as “why aren’t more users logging in”. With many notes, run two rounds: first where the problem happened, then what the problem was.

Labels that say something

The second failure in the same article is grouping by a shared word. Notes about the menu button, the login button and the cart button end up under “button issues”. The label tells you nothing, because the word is all the notes have in common.

Two defenses:

Warn people up front. Explain the risk at the start and agree that anyone can call out keyword matching.
Set a rule for labels. Ask for short sentences with a verb, such as “users failed to log in”, or for made-up user quotes, such as “I don’t know what this site is for”. Both keep the focus on the user and slow down the jump to solutions.

Silence against groupthink

The third failure is the group following whoever speaks first. The article names three profiles: the senior person who intimidates without meaning to, the enthusiast who takes over the conversation, and the expert who brings too much context. When one of them proposes a sorting rule early, the rest fall in line, and other readings never surface.

The proposed rule is to cluster in silence at the start. The start feels messy, but that is where the best ways to sort come from. Once firm clusters exist and only stray notes remain, talking can come back.

The diagram inside thematic analysis

The article on thematic analysis treats the diagram as one of three ways to find themes, next to analysis software and the researcher’s own journaling. In that article’s vocabulary, a code is a short label for a segment of data. A theme is a belief, practice or need that shows up several times, across people or sources.

The article separates two kinds of code:

Descriptive. Says what the segment is about.
Interpretive. Adds the analyst’s reading.

The diagram matches the quick method: cut out the segments, cluster them, and only then give the cluster a code. The upside is speed, teamwork and low cost. The article also names the downside: it is less thorough, since a segment rarely gets more than one code, and it struggles with very varied or very large data.

The six steps of thematic analysis apply to any tool. Gather the data, read all of it, code it, create codes that propose themes, take a day off, then check whether each theme holds. Reading everything before clustering is what keeps synthesis from relying only on the quotes everyone remembers.

Break apart, recombine, then check

The article on analyzing usability data names the two halves of the work. Analysis breaks data into smaller units. Synthesis recombines those units into an explanation. In a diagram, writing the notes is analysis, and naming the clusters is already synthesis.

The article proposes four steps: collect the data relevant to the question, weigh each point, propose explanations and check whether they fit the whole set. Weighing matters on the wall. Praise given in reply to a leading question counts for less than an observed behavior, even when both notes sit side by side.

The final check is the step teams skip the most. The first explanation tends to come from the most memorable notes. When you go back to the full set, some notes contradict the theme, and the explanation has to change. Ending with “we don’t know why yet” is an outcome the article accepts.

The pain points on the C6 Bank redesign

On the C6 Bank project, a redesign of the desktop app, the raw material for analysis came from two sources: journey mapping and interviews with stakeholders inside the bank.

The case doesn’t describe an affinity diagramming session. The path, though, is the one in this post. What comes out of interviews and observation is loose notes. They only become pain points once someone clusters them, names them and decides what weighs most. Identifying those pain points is what the journey mapping and interviews were for.

The checking step was there too, in the form of testing. Nothing was implemented before going through a prototype and a session with a real user, and each round could knock down a theme. That testing plays the role of the last analysis step: seeing whether the reading of the data holds up when people use the product. For the interview side, see the post on stakeholder interviews.

Where the sources disagree

Talk or stay quiet. The diagramming guide describes clustering as a collaborative discussion, sometimes led by a facilitator. The pitfalls article asks for silence at the start, so one voice doesn’t set the sorting rule.
Small clusters. The guide says not to drop clusters with few notes, since they show different perspectives. Thematic analysis defines a theme as something that appears several times and asks whether it is saturated with instances.
One note, two clusters. The guide settles doubt by duplicating the note. Thematic analysis points out that the method usually gives each segment a single code, which makes it less thorough.
Time. The guide treats the diagram as fast, with five to ten minutes to write notes. Thematic analysis suggests budgeting at least as much time for analysis as for data collection.

The common mistake

The mistake is thinking the diagram is just a way to tidy up notes. The team groups by keyword, accepts the most senior person’s rule, names clusters with generic nouns and leaves with a nice wall that answers no question. Before the session, write the focus question. During it, ask for silence and labels with verbs. After it, go back to the full data and see whether each theme survives the notes that contradict it.