UCDmanager

How to Use Affinity Diagrams to Synthesize Research Data

User research often produces a messy mixture of interview notes, survey responses, usability observations, support tickets and analytics. An affinity diagram turns that scattered evidence into related groups, helping a team recognise recurring needs, frustrations and behaviours without losing sight of individual participants.

This approach suits collaborative UX work because researchers, designers, product owners and developers can inspect the same evidence and discuss how themes emerged. Whether the project serves commuters in Melbourne, families in regional Queensland or government users in Canberra, a clear synthesis process makes design decisions easier to explain and test.

Why synthesis matters

Research data is valuable only when a team can use it to make decisions. Reading interview transcripts separately may reveal interesting comments, but it rarely shows the patterns shared across different people, tasks or contexts. Grouping observations exposes repeated barriers, unmet expectations and opportunities for improvement.

An affinity diagram is especially useful after exploratory research or usability testing. It helps distinguish a one-off preference from a widespread problem, while preserving the original wording behind each finding. This is important in Australia, where a product may need to serve very different circumstances, such as fast urban broadband in Sydney and intermittent connectivity in remote communities.

The method also gives stakeholders a visible basis for prioritisation. A product team can see why “confusing account recovery” matters, how often it appeared and which participants experienced it, rather than relying on the loudest opinion in a workshop.

Prepare the evidence

Start by collecting concise observations rather than broad interpretations. Write one idea per note, such as “participant looked for delivery details under account settings” or “screen reader user could not identify the form error”. Include the source, participant type and session reference so that the team can trace a finding back to its evidence.

Remove personal information and standardise the format before the workshop. In an Australian project, this may include checking that suburb, state, age, Indigenous identity or disability information is handled appropriately under the organisation’s privacy obligations. Keep direct quotes where they add meaning, but avoid placing unnecessary identifying details on a shared board.

Digital collaboration tools are practical when team members are spread between Brisbane, Perth and regional offices. If the research repository contains sensitive material, document access rules and technical safeguards. Teams working with enterprise systems may also find relevant background in this overview of single sign-on benefits, particularly when planning access for large groups of researchers and stakeholders.

Build the affinity diagram

Place each observation on its own card, then ask participants to silently group cards that appear related. Beginning in silence reduces the risk that a senior stakeholder controls the interpretation. Team members can move cards, create provisional groups and leave uncertain evidence aside until relationships become clearer.

Once the first pass is complete, discuss the clusters. Name them with specific, meaningful labels such as “uncertainty about application status” rather than vague headings like “pain points”. A useful label describes the shared idea across the evidence and avoids claiming more than the data supports.

Keep contradictory observations visible. If some people prefer phone support while others avoid it, that may indicate different needs rather than poor research quality. Segmenting by task, confidence, access need or service context can reveal a more useful pattern than forcing every note into one group.

Interpret patterns carefully

After clustering, look for relationships between themes. Several small groups may combine into a broader journey problem, such as unclear eligibility information leading to repeated calls and abandoned online forms. Conversely, a large group may contain several distinct issues that require different design responses.

Add evidence counts, participant segments and confidence levels to each theme. Counts should support judgement, not replace it: a serious accessibility barrier reported by one participant can deserve urgent attention even if it is not frequent. Teams conducting formal accessibility work can connect the synthesis to a web accessibility audit guide.

Australian service environments often make context especially important. A digital form used by a local council may be accessed on a phone while travelling between towns, while a government service may need to support users with limited digital literacy, English as an additional language or assistive technology. These conditions should appear in the theme definitions and not be treated as side notes.

Validate and document findings

Share the draft themes with people who understand the research context but were not involved in every session. Ask them to challenge the grouping, identify missing evidence and check whether the language reflects participants accurately. Where possible, return to recordings, transcripts or test notes before changing a theme.

Document each final theme with a short description, supporting observations, affected user groups and design implications. A project workspace such as UCDmanager’s FAQ can help teams understand how to organise research and usability material in a shared environment.

Use the findings to create research-backed requirements, journey-map updates, usability test scenarios or backlog items. Record unresolved questions as hypotheses for further investigation. If the project involves customer accounts or regulated information, include technical research as well as user evidence; for example, a security team may need to review SSL certificate chains alongside service usability concerns.

Practical recommendations for stronger synthesis

A productive workshop balances speed with traceability. Do not spend the session polishing labels before the underlying relationships are stable. Photograph or export intermediate boards, record major decisions and note where stakeholder assumptions influenced the final interpretation.

Use the following practices to keep the analysis useful:

A well-maintained affinity diagram remains useful after the workshop. It can explain why a feature was prioritised, guide accessibility and usability testing, and help new team members understand the evidence behind a decision. The result is a shared account of user needs that is grounded in research rather than assumption.