Affinity mapping in UX research is a way to group related observations while keeping their original context. The safest workflow is to capture one observation per note, label the source, cluster by meaning, name the pattern, and then connect the pattern to a product decision. The map is a synthesis aid; it is not a vote and it does not turn a small study into a market statistic. For the next planning step, use the dot voting for a clear shortlist guide.
When a workshop needs to compare a journey, screen, and handoff together, an online board such as Mockitt Board can keep notes and a shared flow in one review space. Keep participant identifiers out of shared views and link back to a controlled research repository for sensitive evidence.
Prepare notes before clustering
Affinity work becomes noisy when every note mixes observation, interpretation, and a proposed fix. Use a consistent note format:
- Observation: what the participant did or said, in their words where possible.
- Context: task, screen, environment, and session identifier.
- Interpretation: a separate hypothesis about why it happened.
- Open question: what still needs checking.
For example, write “P04 opened Help after the confirmation button did not change the screen” instead of “P04 was confused.” The first note can be checked against the recording and compared with other sessions; the second assumes a cause.
Normalize spelling and remove personal data, but do not erase meaningful differences in language. If a note summarizes several moments, split it before the workshop so one strong sentence cannot hide multiple patterns.
A five-step affinity mapping workflow
- Restate the research question. Put the decision and scope at the top of the board. This prevents a convenient theme from becoming the goal.
- Read silently. Let each person scan the notes before discussion. Mark duplicates only when they describe the same observation.
- Cluster by relationship. Group notes that describe a similar behavior, need, or barrier. Start without naming the clusters.
- Name and challenge. Give each group a sentence that says what is happening and why it matters. Ask which note does not fit.
- Trace to action. Link the theme to the decision, supporting notes, uncertainty, and a follow-up question or design implication.
Work in two passes. The first pass is exploratory and should tolerate several plausible groupings. The second pass tightens boundaries and records disagreements. Moving a note is useful evidence about the boundary; silently deleting it is not.
Write theme names that are defensible
A useful theme name includes a pattern and a consequence: “People look for delivery cost before choosing a date, so the total is discovered too late.” A label such as “checkout issues” is too broad to guide a decision. Avoid names that prescribe a UI before the evidence is understood, such as “Add a sticky summary.”
Under each theme, record:
| Evidence field | Example |
|---|---|
| Pattern | Participants compare cost before selecting a delivery date. |
| Sources | P02, P04, and P07; task 3. |
| Counterevidence | P01 selected the date first and said price was secondary. |
| Consequence | The current order may hide a decision input until late. |
| Confidence | Directional: three observations in a small, targeted sample. |
| Next check | Test an order summary that exposes cost before date selection. |
Avoid common affinity map errors
Do not cluster by participant. One column per person creates biographies, not patterns. Keep the participant ID on each note and group across people.
Do not treat votes as prevalence. Dot voting can help a team choose which theme to discuss first. It cannot show that a theme is common among users. Report the observed evidence and sample limits separately.
Do not merge contradictions away. A disagreement may reveal a segment, a different context, or an ambiguous task. Keep the counterexample visible and write the condition that may explain it.
Do not let the board become the repository. Store raw recordings, transcripts, and consent records in the approved research system. The map should contain the minimum evidence needed for a decision and links or IDs that a permitted researcher can trace.
Use the map with a journey or prototype
Once themes are named, place them against the journey step or prototype state where they occurred; use an empathy map for a focused view of one user group. This shows whether a barrier is caused by an entry point, a transition, or a missing recovery path. Keep the journey as a separate view so clusters do not become a decorative wall of sticky notes.
If the team proposes a change, add it as a hypothesis next to the theme, not inside the evidence note. For example: “If delivery cost appears before date selection, fewer participants will open Help during checkout.” The hypothesis can then be tested with a new prototype or task study.
Share and maintain the synthesis
End the workshop with a short decision log: what the team learned, what remains uncertain, what will change, and who owns the next check. Export a read-only snapshot with the research date and study version. When new evidence arrives, add it to the same theme structure or record why the structure changed.
A good affinity map makes the path from note to theme to action visible. That trace is more valuable than a crowded board because it helps a later teammate understand both the insight and its limits.
Facilitate a focused workshop
Set a time box for each pass and name a facilitator who can protect the research question. Invite people who know the product, but do not let the loudest role decide where every note belongs. Ask for a source or task reference when someone makes a strong claim. If two groups are equally plausible, keep both until the evidence supports a boundary.
Use a visible parking area for notes that are unclear, duplicate, or outside scope. A parking area is safer than forcing a note into a convenient group, and it creates a follow-up list for the researcher. At the end, review the parked notes and document whether they need more evidence, a different study, or no action.
Link themes to priorities without hiding uncertainty
Prioritization comes after synthesis. Record the user consequence, the business or delivery constraint, and the confidence of the evidence as separate fields. A theme can be severe but uncertain, or well supported but inexpensive to address. Keeping these dimensions separate helps a team choose a next test instead of presenting an arbitrary score as truth.
When a theme becomes a product requirement, preserve its source IDs and the conditions under which it appeared. This lets the team revisit the requirement when a new audience, device, or workflow is introduced. It also prevents a useful qualitative insight from being repeated as an unqualified rule.
Document the final map
Record the research question, date, participants represented, note-taking rule, and facilitator with the final board snapshot. Include a short note about what was excluded or parked. This context matters when a stakeholder sees the themes later without attending the workshop.
For privacy, share a view that uses study IDs and paraphrased evidence where possible. Keep the raw notes in the approved repository and limit access to the people who need them. A clean final map should make the decision easier to revisit without exposing a participant.
Finally, state what the map cannot tell you. It can reveal recurring behaviors in the studied context and suggest a next test; it cannot prove that every customer behaves the same way or replace quantitative measurement when prevalence is the decision.