Affinity Diagram in UX Research: From Notes to Findings

Affinity mapping groups research observations to expose relationships that individual sessions can obscure. Moving sticky notes is only the visible activity. The analytical work is deciding what the notes mean, preserving contradictions, and developing findings that can be traced back to evidence.

Define the decision and scope

Start with a concrete scenario: analyze interviews about approving supplier invoices. State what the team needs to decide and what evidence could change its current direction. Keep the scope narrow enough that participants can provide relevant evidence and the team can act on the result.

Use the word counter during preparation. Paste the participant-facing instructions into the tool and shorten long or ambiguous passages. Read the edited version aloud and pilot it with someone outside the project. Word count is an editing aid, not evidence that the language is understandable.

Write a short study contract covering the audience, task boundary, main uncertainty, and intended decision. Identify what this round will not establish. For a research synthesis, that boundary prevents a useful finding from being stretched into an unsupported claim about the entire customer base.

Prepare the evidence and study materials

Write one observation per note, retaining its participant identifier and context. Keep direct quotations clearly distinguished from paraphrases. Read the notes before grouping them so a memorable early interview does not define the categories for everything that follows.

Create explicit definitions for the concepts your team will use. In this study, pay particular attention to traceable observations. If two observers would classify the same event differently, resolve the ambiguity before collecting more data. Definitions should describe observable conditions rather than impressions such as engagement or ease.

Include realistic variation without making the study unmanageably broad. Consider task frequency, prior knowledge, permissions, device constraints, and the consequences of an error. Recruit or sample around differences that could change the decision, not simply around the people who are easiest to reach.

Use Nielsen Norman Group's research guidance to check the method's purpose and limits. Keep the materials within your team's design workflow, but do not treat stakeholder approval of a script as proof that participants will interpret it correctly.

Pilot the process and protect participants

Allow notes to move as understanding develops. Name clusters with statements that describe a pattern, not vague topic labels. A cluster called trust is less informative than a statement explaining what evidence customers require before approving an unfamiliar supplier.

Run a complete pilot, including recruitment, consent, setup, task instructions, recording, and data storage. Time the full experience rather than only the main activity. Check whether participants can withdraw, report a technical problem, and understand what information will be retained.

Collect the minimum personal information necessary. Keep identifying details separate from shared findings and use participant codes where possible. Confirm compensation and accessibility arrangements before scheduling. Do not promise anonymity if the planned recording or account context makes a person identifiable.

Use the GOV.UK user research guidance as a practical planning reference. Record changes after the pilot. If you substantially revise instructions or eligibility, decide whether pilot evidence remains comparable instead of silently pooling different study conditions.

Analyze patterns with their context intact

Begin with observable evidence, then develop interpretations. Record what happened, under which conditions, and with what consequence. Keep direct observations distinct from participant explanations, system measurements, and team hypotheses. Each source can contribute without being interchangeable with the others.

Look for recurring patterns and meaningful exceptions. A problem affecting one person may still deserve urgent attention if it causes an irreversible loss. A frequently mentioned preference may matter less if it has no demonstrated effect on completing the task. Frequency alone is not a complete prioritization rule.

Compare alternative explanations before recommending a change. A confusing instruction, unsuitable participant, missing permission, or faulty event can mimic a product problem. Mark uncertainty explicitly when the available evidence cannot distinguish these causes. Do not exclude inconvenient cases merely because they complicate the story.

Use the UX research collection to choose complementary methods. A finding about traceable observations may need another kind of evidence before the team commits to a costly intervention. Preserve source references so someone who missed the sessions can review the reasoning rather than trusting a persuasive summary.

Turn findings into a testable improvement

Write each finding as a relationship between context, behavior, and consequence. State who was affected and what prevented progress. Avoid a recommendation consisting only of a solution, because colleagues need to understand the underlying problem before evaluating alternatives.

Apply this rule: keep participant evidence separate from the team’s proposed solutions. Identify the smallest change that addresses the supported problem and list any assumptions that remain. Assign an owner, a review date, and a verification method appropriate to the risk. A minor wording repair and a major workflow change should not require identical evidence plans.

Choose outcome measures that reflect customer success rather than convenient activity counts. A measure can improve while the experience deteriorates if the team optimizes the wrong behavior. Include guardrails for errors, unwanted commitments, support demand, or lost work where those consequences are plausible.

The W3C guidance on involving users is useful when checking whose experiences your evidence includes. Document coverage gaps and avoid treating a small study as a compliance assessment. Finish with a brief decision record: what changed, why it changed, what remains uncertain, and when the team will revisit the result.

Check whether a cluster survives contradictory notes

Imagine a cluster labeled Approval is confusing. One note says an approver could not identify the invoice owner; another says a finance administrator knew the owner but could not see whether approval had already occurred. Those observations may share a broad theme while requiring different explanations and remedies.

Split the cluster provisionally into ownership and status visibility. Add participant identifiers and task context to each note, then inspect the original excerpts. Include a contrary case: someone who completed approval easily because they used an external spreadsheet. That success may depend on a workaround rather than a clear interface.

Write a finding only after this comparison: approvers lack particular information under particular conditions, with a documented consequence. Count distinct participants separately from notes so a talkative interview does not dominate the apparent pattern. Preserve unresolved notes outside the main clusters and list what additional evidence would help classify them. A smaller, well-supported finding is more actionable than an impressive umbrella theme.

Key takeaways

• Frame the work around a specific decision and realistic scenario.
• Define traceable observations before collecting evidence.
• Pilot the full process, not only the main task.
• Separate observations, interpretations, and proposed solutions.
• Preserve exceptions and verify the consequences of changes.