User research readout presentation: plan for the skeptic

A user research readout presentation should end in a decision, and the skeptics in the room help you get there. When a stakeholder asks "How do we know?", they may have found a weak claim, a missing audience or a disagreement about the decision itself. A long run of impressive quotes will entertain them without helping anyone choose, so build the meeting around the decision and its uncertainties.

GOV.UK's sharing guidance recommends showing the research context, findings, consequences and next steps so others can use and question the work. The agenda below is our own facilitation tool for a small team.

1. Send the decision question before the meeting

The pre-read states the choice, the alternatives still in scope, who decides and the limits of the evidence. Include the research question, participants' relevant contexts, methods, dates and missing coverage.

Here is a made-up example we will use throughout: an inventory product. The decision might be: "Should we test clearer update history before committing to a full reconciliation dashboard?" That is easier to act on than "What did customer research tell us?"

Ask each attendee to bring one specific challenge, such as a competing explanation. Share restricted source links with the people who need to inspect evidence, never more widely than the study permits.

2. Spend most of the 45 minutes on challenge

Adapt the times to your team.

Time	Activity	Desired output
0 to 5 min	Restate the choice, owner and limits	Agreement on the decision being considered
5 to 13 min	Present the few findings that affect it	Shared understanding of claims and sources
13 to 23 min	Examine counterevidence and other explanations	A visible list of substantive challenges
23 to 33 min	Sort what each challenge would require	Checks, corrections or accepted uncertainty
33 to 41 min	Compare next actions and decide	A decision, or the condition preventing one
41 to 45 min	Assign owners, dates and a revisit trigger	A record of who does what next

If the evidence cannot support the proposed decision, changing the decision is a legitimate outcome. The meeting is not there to approve the researcher's favorite idea (even when the researcher is you).

3. Present each finding with its boundary

Use one claim per slide or card, with its supporting observation, context, a counterexample and the implication.

In the inventory example, a card might say: "In the studied multi-system inventory workflows, uncertainty about the latest update contributed to manual comparison." It would show the source references, a contrasting case where update time was clear, and a separate case where comparison was required for approval.

So test that explanation and a possible remedy in that workflow. The claim does not show how many organizations have the problem, or that a dashboard is the best fix.

GOV.UK's analysis guidance separates observations, findings and actions. Keep that separation and disagreements become easier to locate.

4. Turn each objection into an evidence question

Write the challenge in neutral words, then ask what observation would resolve it or materially change it.

Challenge	What it may reveal	Useful response
"You only talked to a few people."	The claim may be broader than the sample supports	Narrow it; check whether the decision needs to know how common the problem is
"Our largest customer does something different."	A context or segment may be missing	Compare their workflow; decide if separate research is needed
"The dashboard says people complete this."	Different definitions of completion or burden	Align task, date, unit and event before claiming a conflict
"This does not fit our strategy."	A priority disagreement, not a factual one	Ask the decision owner to state the tradeoff
"The proposed solution will not help."	The recommendation goes beyond the finding	Separate explanation from intervention and test it

Do not answer every challenge with more of the same evidence. A question about how common something is may need a different method. A strategy dispute needs a decision from whoever owns that tradeoff.

5. Keep the meeting from becoming a vote on anecdotes

Give attendees a quiet moment to write their challenges before discussion, and ask each person to point to the claim they are challenging. Group influence will survive, but quieter people get a turn.

Record the context and source of any contrary case, then examine it. A forceful anecdote should not erase other evidence without inspection either. (The loudest story in the room is still one story.)

Give each challenge a visible status:

Corrected now
Needs a defined check
Outside this decision
Unresolved, and accepted by the decision owner

Do not call an issue "resolved" because the meeting moved on.

6. Close with a decision someone owns

Record the action, the reasoning, important dissent, the owner, a due date and the result that would trigger reconsideration. If no decision is possible, name the missing evidence and who will get it.

In the inventory example, the output could be a scoped update-history test plus a separate check on approval-driven comparison. Nobody has committed to a broad dashboard or claimed the research proved its value.

Write down the revisit condition before everyone leaves, so the research stays useful when a later result changes the team's mind.

User research readout presentation: plan for the person asking "how do we know?"