Do not move every research recommendation directly into the development backlog. Connect the observation to its source, describe the interpretation and its limits, then choose an appropriate decision: fix, test a solution, collect more evidence or take no action now. Otherwise, team preferences can become “user needs” simply because they appeared after a research session.
A usable report should not end with broad themes such as trust, speed and clarity. The product owner needs to know which task was affected, what happened, to whom, in which circumstances and what changes the decision. More notes do not necessarily mean more build-ready requirements.
Keep three layers distinct
First comes evidence: an observed event or documented account within the study’s conditions. Second comes interpretation: what might explain it and where that explanation does or does not apply. Third comes the decision: what the team will do and who authorizes it. GOV.UK’s analysis guide distinguishes observations, findings and actions. Research-analysis reference.
User Research can support this synthesis when permitted evidence and its context are available. If only a short slide deck remains, state the reconstruction limits. Do not invent quotations or causes to make the conclusion appear more convincing.
The separation also makes disagreement productive. Two reviewers may agree about what happened while proposing different explanations. Recording that distinction gives the next study a useful question instead of forcing premature consensus.
Build a traceable findings register
Give each finding a stable identifier. Record its research question, participant group and task, supporting evidence, contradictory evidence and coverage limits. Not every reader needs personal recordings. Use appropriate references that authorized reviewers can verify and de-identified summaries for wider circulation.
Explain confidence rather than assigning a colour alone. “Limited confidence because this occurred in one role and the alternative route was not tested” is more actionable than an unexplained amber dot. A problem can matter even when its prevalence is uncertain; the appropriate next step may be a focused investigation rather than dismissal or an unsupported universal claim.
Preserve the version and date of the underlying experience. A finding about an older flow may still matter, but should not be treated as an observation of the current release without checking whether the relevant conditions remain.
Worked hypothetical example: an internal-request portal
The fictional team below is reviewing four findings from permitted research material. These rows are not a real study or participant testimonials. The purpose is to choose a next step for each finding rather than create a feature list with uniform certainty.
| Hypothetical finding | Known and unknown | Proposed decision |
|---|---|---|
| Old requests are difficult to locate | Difficulty was observed; label versus filter causes remain unresolved | Test alternative labels and ordering before building advanced search |
| “Complete” is understood as final delivery | Participant interpretation differs from the operational meaning of review completion | Resolve the state definition, revise wording and verify understanding |
| Some requests need a document the requester does not hold | Accounts suggest dependence on a colleague; not all roles were studied | Investigate the supporting role and later-completion need |
| One manager asks for another dashboard | The request is explicit, but the task it would support is unspecified | Conduct follow-up before adding dashboard scope |
Directly converting these rows into features would produce advanced search, a new dashboard and staged attachments even though the evidence does not require those solutions. Instead, establish the problem and choose the smallest testable response. A label or operating-rule change may resolve part of it without new functionality.
For the status finding, Product Discovery & Requirements can define the state, who changes it and what each role should see. This creates an agreed rule, not merely a preference about a word. For request retrieval, User Experience Design can prepare alternatives for comparison before a large solution is approved.
The document-dependency finding should remain open until the relevant collaboration is understood. Adding an upload reminder may not help if another person controls the document. That distinction prevents a convenient design response from substituting for a supported requirement.
Prioritize decisions, not the loudest quotation
Review task impact, affected groups, recoverability, consequences of inaction, evidence strength and the cost of resolving uncertainty. Frequency alone is insufficient: a repeated visual preference can be less consequential than a less frequently observed barrier to a critical task.
A senior stakeholder’s request should not automatically receive research-derived priority. They may have authority to make a commercial or operational decision; record it honestly as that decision, not as a finding established by users. This preserves both decision authority and the integrity of the evidence record.
When the proposed solution’s effect is unknown, route it into Product Validation with a decision criterion. Do not place it in development as a promise to improve a metric. A valid decision may reject an unsuitable solution while retaining the underlying problem for later review.
Carry the evidence into the work item
Include the finding reference, user and goal, required behaviour, acceptance criteria, dependencies and remaining assumptions. For an experiment, state the observation to collect and proceed-or-revise decision. For an approved fix, describe how the team will verify that the issue is resolved within the stated scope.
Update the record after delivery. Implementing a recommendation does not demonstrate its effect. Keep distinct states such as proposed, approved, implemented and effect verified in a specified test. Strategyzer’s Learning Card explicitly records learning and the resulting action. Learning Card reference.
Synthesis acceptance checks:
- Every finding traces to permitted evidence with known context.
- Contradictory evidence and uncovered groups remain visible.
- Problems are distinct from preferred solutions.
- Approved requirements are separate from experiments and open questions.
- Decisions have owners and reasons for priority or deferral.
- Implementation and verified effect can be distinguished.
Frequently asked questions
Do we need a specialized research repository?
Not necessarily. A structured register, appropriate permissions and stable references can be enough initially. The team must be able to trace and update decisions without losing context.
What should we do with conflicting findings?
Investigate role, task, version and contextual differences. Contradiction may reveal two different needs rather than an error to remove for a simpler story.
Does every problem require another test?
No. Some decisions have sufficient evidence and an agreed operational rule; others need verification. Explain the choice and risk rather than mandating endless research.
Who owns prioritization?
The agreed product or business decision owner, informed by research, design and implementation. Analysis makes evidence and limits explicit; it does not replace all commercial judgment.
When commissioning synthesis, request a decision register and evidence-linked work outputs, not a findings presentation detached from how the team will use it.
