A user research findings presentation should help a product team decide what to do with evidence. It should connect observations to themes, show the boundaries of the sample and end with a decision or a focused next question. A transcript dump is not a synthesis, and a confident headline does not make a small sample representative.
When the research includes sources, quotes and measures, the data storytelling guide can help structure the evidence. This guide focuses on the reasoning between a research observation and a product decision.
1. Frame the decision before the findings
Open with the decision the audience can make: “Which onboarding problem should we test next?” State the product area, participant group, research method and dates. Include what the study was designed to learn and what it was not designed to answer.
Use a short methods box rather than a long preamble. For example, describe interviews with a defined participant profile and a stated recruitment source. If the sample is directional, say that it is directional. Research boundaries are not an apology; they prevent the audience from applying a conclusion beyond the evidence.
Keep research questions separate from hypotheses. “How do new administrators complete the first workspace setup?” is a question. “They will need a guided checklist” is a hypothesis that the evidence may support, refine or reject.
2. Move from observations to themes
Start synthesis with specific observations: what a participant did, said or failed to complete. Then group related observations into themes that explain a pattern. A theme should be more useful than a topic label. “Navigation” is a topic; “people look for permissions in the workspace menu but expect them under their profile” is a testable interpretation.
Show one or two supporting examples for each important theme and keep the participant context visible. Do not present a vivid quote as if it were a frequency estimate. If you have a count, state the denominator and whether the sample was selected for that behavior.
Look for disconfirming evidence. A theme that fits four observations but conflicts with two may need a narrower statement. Including a counterexample makes the conclusion more robust and tells the product team where a solution might fail.
3. Make the evidence traceable
Give each evidence point a source label that maps to your notes, transcript or event report. Remove personal details that are not needed for the product decision. Preserve enough context to avoid changing a quote’s meaning.
Separate direct evidence from interpretation. Use labels such as observed, reported, inferred and open question. A participant saying “I could not find the setting” is reported experience; concluding that the label is unclear is an interpretation that can be tested.
For behavioral data, state the event definition, time range and relevant segment. “Completion improved” needs the before and after periods, the measure and the comparison. If you cannot establish causation, use language such as “coincided with” or “is consistent with” rather than “caused.”
4. Prioritize opportunities without overclaiming
Translate themes into opportunity statements: “Help a new administrator confirm the workspace is ready before inviting teammates.” Then evaluate opportunities using criteria the team agrees to, such as customer impact, frequency signal, strategic fit, confidence and effort.
Keep frequency and severity separate. A rare problem can matter if its consequence is serious, while a frequent complaint may have a low-cost workaround. A small interview study can reveal an important mechanism without estimating the size of the entire market.
Show the decision rule. A two-by-two can be useful if the axes are named and the placement is explainable. Avoid a mysterious composite score that turns qualitative judgment into a precise-looking number.
5. Connect findings to a testable action
For each prioritized opportunity, propose an action and the learning signal. The action might be a prototype review, a usability test, a content change or a product experiment. Describe what would support the idea and what would change the direction.
Assign an owner and a review date. A research finding without a next step becomes a reference slide that nobody revisits. At the same time, avoid claiming that the proposed action will produce a particular business result. The research supports a decision to learn or act; it does not guarantee the outcome.
Keep a “not answered” list. If participants did not include an important segment, or the method could not test a pricing question, say so. Turn the gap into a follow-up question instead of quietly filling it with stakeholder assumptions.
6. Present the story in a reviewable sequence
A clear deck often follows this order: decision and method; three or four themes; evidence and counterexamples; opportunity priorities; proposed actions and learning signals; limits and open questions. Put the full participant or coding detail in an appendix so the main story remains readable.
Use plain theme names and repeat them consistently. Do not mix a persona label, an internal team name and a problem statement as if they were the same kind of object. A small legend can explain your evidence labels once.
End by asking for a specific decision: choose one opportunity to test, approve a follow-up study or request a missing piece of evidence. After the meeting, store the source notes and decision log with the deck. A good user research findings presentation makes the next product choice clearer while staying honest about what the research cannot prove.
