User Research Synthesis: Keep Conflicting Evidence Visible

An employee asks for a shorter equipment-request form. A reviewer asks for more context. A team manager asks for a way to see requests that are waiting for a decision. A synthesis that combines these observations into “users want a simpler approval process” leaves the product team with an attractive sentence and an unresolved design problem.

This is a fictional example of an internal business tool. There are no actual interview results behind it. It illustrates a problem in synthesis: a shared word can conceal different tasks, constraints and consequences.

The team needs to decide which information a requester should provide, what a reviewer needs before deciding, and how a manager can locate a delay. A useful synthesis keeps those questions separate long enough to make a defensible choice.

Trace the evidence into a decision

Keep the source and role

Record the task, situation and observed behavior. Repeated copies of one observation remain one source.

Separate what happened from your explanation

Write a scoped interpretation

State which role and situation the proposed finding describes. Keep alternative explanations visible.

Look for evidence that challenges it

Does a counterexample change the claim?

Check who is missing and which observation would alter the recommendation.

If yes, or coverage is insufficientNarrow the claim or collect missing evidence

Record what changed. Return to the counterexample check with the new evidence.

If the scoped claim supports a bounded decision

Compare a change with alternatives

Define the hypothesis, affected roles and observable result. Test the decision before treating it as an improvement.

This is a proposed synthesis process for the fictional equipment-request example. A passed check does not prove prevalence or remove remaining uncertainty.

Preserve the observation before interpreting it

Start with a record that another team member can trace. Keep a participant reference, role, task, source location and what happened. Separate that observation from the explanation you think fits it. GOV.UK's research guidance makes this distinction between observations, findings and subsequent actions. Analyse a research session.

For the fictional tool, “the requester left the cost-center field blank and asked where to find it” is an observation. “The field is unnecessary” is an interpretation. It might be wrong. Perhaps the requester needs help finding a value that the reviewer genuinely requires.

Use separate columns for the two. A quote copied from an interview into a workshop board and then into a slide deck still describes one source observation. Do not count those copies as independent support. Preserve the underlying reference when combining notes so the apparent weight of a theme does not grow merely because it has been repeated.

Keep those references in the controlled research record. The published readout does not need identifiable participant details. GOV.UK's note-taking guidance covers consent, secure handling and participant/session labels. Taking notes and recording research. In a real study, follow the permissions agreed with participants when deciding what can be shared.

Put role and situation back into the theme

Consider this proposed synthesis table. Every row is part of the same invented example.

The table does not establish that these issues occur in every team. It shows why removing fields, adding fields and improving a status view are different proposals. They require different evidence and may coexist.

Recruitment also affects what can enter the table. A study of experienced employees will not directly answer what a first-time requester understands. GOV.UK advises defining relevant participant groups and recruitment criteria around the questions being investigated. Finding participants for user research. Record missing groups in the readout rather than quietly extending a finding to them.

Give the counterexample a consequence

Suppose a reviewer can approve routine requests without a free-text justification, but needs it for specialist equipment. That observation challenges “every request requires justification.” It does not prove that justification should disappear everywhere.

The theme can become narrower: routine requests may need fewer manual inputs, while unusual requests require additional context. The resulting design question is whether the form can ask for that context only when it is relevant, and whether the reviewer can still explain the decision.

Use a counterexample register with three fields: the working conclusion, the observation that challenges it, and the change it makes to scope or confidence. A counterexample that changes nothing deserves an explicit explanation.

This is a proposed safeguard. The GOV.UK analysis guide allows irrelevant or isolated notes to be discarded when organizing themes. An isolated observation can nevertheless matter to the decision. Before removing it, ask whether it reveals an excluded role, a rare but consequential task, or a condition under which the recommendation fails. Preserve that limitation even if it will not determine the first release.

Separate confidence from popularity

A team can be confident that it observed a particular problem and uncertain about its frequency. Keep those statements distinct. “We saw this in these sessions” is narrower than “customers generally experience this.” Repeated notes from the same participant do not resolve that gap.

Avoid a single unexplained confidence score. Record what is well supported, what the evidence does not cover and what would change the recommendation. For example: the observed reviewer needed extra context for this unusual request; the study has not established which other request types require it.

If the decision depends on how common the issue is, define a separate measurement task and its population. If it depends on whether people can complete the revised workflow, test that workflow. An interview theme alone does not answer both questions.

Turn disagreement into a testable decision

For the equipment tool, a possible next experiment is a prototype with prefilled routine details and a conditional justification step. Test the employee and reviewer journeys together. A faster request form is not sufficient if reviewers must repeatedly return incomplete requests.

Before testing, write what evidence would make the team reject the proposal. Examples include incorrect prefilled data that people cannot correct, reviewers unable to explain an approval, or a manager unable to identify who owns a delayed request. These are proposed checks, not completed tests or measured findings.

Keep alternatives visible. Better field guidance, a saved template and a different review workflow could address different parts of the problem. The synthesis should explain why a particular experiment is informative without treating it as an already-proven solution.

Make the readout useful to someone who missed the sessions

Include the decision, study scope, findings with source references, counterexamples, alternatives and next investigation. Ask a colleague to trace a recommendation back to its observations and identify where inference begins. GOV.UK recommends sharing findings so teams can use them in decisions and other readers can identify gaps. Sharing user research findings.

For the fictional approval tool, the immediate decision might be to test conditional information collection. Questions about missing roles or the frequency of unusual requests remain open. Record who will resolve each question and which decision depends on the answer.

If the disagreement occurs between stages of a service, a journey map of waiting and handoffs can help locate the boundary. Keep the original observations attached to it. A shared diagram should make the disagreement easier to inspect, rather than smooth it out.

The next readout should allow someone to answer a practical question: if we remove this field, whose work changes, and what evidence tells us the change is acceptable?