UX Research Synthesis: Turn Notes into Traceable Design Decisions
Work through a research synthesis example that links observations to themes, preserves contradictory evidence, and produces a specific design decision.
UX research synthesis connects what people said and did to a decision a product team can make. Grouping notes is part of the work, but the useful output is a defensible explanation: what the evidence suggests, where it conflicts, what remains uncertain, and what should happen next.
This guide follows a software-license renewal handover. Six synthetic notes show how to move from observations to a qualified finding and a proposed interface change. The notes are teaching examples, not customer quotations or results from a real study.
Start with a question and an evidence ledger
The example research question is: “How do staff identify who owns an upcoming software renewal and what decision is needed before its deadline?” That question limits the synthesis. Comments about unrelated reporting features can be preserved for later without dominating the current decision.
If the team has not yet collected relevant evidence, start with an appropriate UX research method. A synthesis session cannot compensate for interviewing the wrong audience or failing to observe the task. It also should not turn internal stakeholder preferences into user findings.
Give each observation a stable ID and enough context to retrieve its source. A working ledger might contain the study, participant identifier, role, task, observation, source location, and any consent or access restriction. Use participant codes in a shared board and keep identifying information in the approved research repository.
| ID | Context | Illustrative observation |
|---|---|---|
| R01 | P01, operations coordinator | Opens a renewal record, then searches a chat thread to find the decision owner |
| R02 | P01, same task | Finds a due date but cannot tell whether it is a cancellation deadline or a payment date |
| R03 | P02, department lead | Asks whether “pending” means waiting for their approval or waiting for procurement |
| R04 | P03, procurement colleague | Uses a handover note to explain why another team owns the next decision |
| R05 | P04, finance colleague | Requests an export for an existing review process rather than another dashboard |
| R06 | P02, follow-up task | Identifies the owner once a named role and next action appear together |
Six notes do not mean six independent participants. Here, P01 and P02 each contribute more than one observation. Preserve that distinction if you later summarize how many people encountered an issue. This tiny illustrative set cannot establish prevalence in the customer population.
Separate observation from interpretation
R01 records a behavior: the coordinator searched a chat thread after opening the record. “The renewal dashboard is confusing” is an interpretation, and “Add an owner widget” is a solution. Store these separately so the team can revisit the reasoning.
The GOV.UK guidance on analyzing research sessions separates observations, findings, and actions. That distinction helps a team discuss what happened before deciding what it means. Confirm disputed notes against the permitted recording or source material rather than resolving factual disagreements by a show of hands.
For R02, the uncertainty may concern date semantics rather than owner visibility. Do not merge it into the owner problem simply because both notes came from the same screen. One screen can contain several causes, and one cause can appear across several screens.
Keep a short interpretation memo when an inference needs explanation. For example: “R01 and R03 suggest uncertainty about the next decision owner, but the observations come from different roles and may reflect different responsibility rules.” That is more useful than a confident cluster label that hides the ambiguity.
Cluster evidence without losing the source IDs
Arrange the notes on Mockitt Whiteboard with an ID, a brief observation, and a context label on each card. Keep raw recordings and sensitive details in their approved location. The board is a workspace for organizing evidence, not permission to make every research artifact public.
Try tentative groups such as identifying responsibility, understanding the deadline, and fitting the handover into an existing process. Move notes as the interpretation improves. Keep R04 near responsibility while acknowledging that its handover explanation may also inform the process group.
A heading such as “Dashboard” identifies a location, not a finding. Ask what connects the observations: is information missing, is a label ambiguous, or is responsibility genuinely undecided? If the underlying causes differ, split the group or record the competing explanations.
The Nielsen Norman Group introduction to thematic analysis explains the role of coding and theme development in qualitative analysis. A board of sticky notes can support that work, but proximity alone is not evidence that two notes mean the same thing.
Write a finding that carries its limits
A qualified finding for this example is: “The handover view does not consistently make the next decision owner clear in the observed tasks. R01 and R03 show participants looking outside the status label for responsibility; R04 and R06 suggest that a role plus a next action may help explain it.”
This wording preserves the task context, names the supporting records, and distinguishes the observation from a possible response. It does not claim that every user needs a new dashboard or that adding a role field will solve the problem.
Retain R05 as a constraint. The finance colleague's existing export process may be important even if it does not fit the preferred interface direction. Record a follow-up question: which information must remain available in that export, and who uses it next?
Do not discard a contradictory observation because it is isolated. Consider whether it signals a different role, an accessibility need, a rare but consequential failure, or an error in the note. The relevance of an issue depends on its context and consequence, not only the size of its sticky-note cluster.
Connect the finding to a specific design decision
Propose a renewal handover panel with four elements: decision owner, deadline with its meaning, current decision status, and a short source-linked handover note. Label it as a proposed response to inspect. It is not a proven solution, and it does not replace the unresolved finance-export requirement.
The proposed handover panel keeps the evidence IDs beside the decision it is meant to support.
Use Mockitt Design to lay out the proposed panel and its alternative wording. Keep the original version available for comparison. For the example, compare the generic status “Pending” with the more specific “Awaiting department approval,” shown beside the named role. The labels should express actual business rules that the team can confirm.
Then write a decision record:
- Evidence: R01, R03, R04, and R06 relate to identifying the next decision owner.
- Decision: prototype a responsibility-and-next-action panel before changing the whole renewal dashboard.
- Open question: determine which handover information finance needs in the export.
- Next evidence: observe whether intended users identify the correct owner and next action without facilitation.
- Reconsider if: responsibility remains unclear because the business process itself has no agreed owner.
The final point prevents a common mistake: trying to repair an organizational ambiguity with a clearer label. The design can expose an unresolved ownership rule, but it cannot decide that rule on behalf of the organization.
Share the chain of reasoning, not only the polished screen
Present the research question, qualified finding, supporting notes, contradiction, proposed change, and next test together. A stakeholder should be able to follow the path from R01 to the panel without assuming that the drawing itself is evidence.
Keep the synthesis concise enough to use in a product discussion. Link to the permitted evidence rather than pasting an entire transcript into every artifact. If a colleague disagrees, distinguish disagreement about the observation from disagreement about its interpretation or the proposed priority, using severity calibration when a finding identifies a usability problem.
A follow-up task session should assess owner and next-action clarity; it should not ask only whether the panel looks better. Use the outcome to revise the finding or proposed design. If participants still depend on chat messages because ownership changes informally, further process research may be more useful than another visual iteration.
Check the synthesis before treating it as direction
Check that every material finding has retrievable evidence, repeated notes are not counted as independent people, quotations remain distinct from paraphrases, and contradictory information is visible. Make sure the next action addresses the finding rather than a feature the team already wanted.
If AI helps organize notes, verify each resulting statement against the original source, follow the study's data-handling restrictions, and keep interpretation under human review. A fluent summary can combine separate participants, erase qualifications, or invent a causal connection. Do not let that summary become the only surviving evidence record.
The useful outcome is a decision someone can question and improve. For this example, it is a narrowly scoped handover-panel experiment with a preserved export constraint. The team can now test a specific change while remaining clear about what the research has and has not established.
