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.
After agreeing what the evidence supports, you can use Presenti to draft slides from your research outline. Include the observations and competing explanations in that outline; the presentation tool can organize your material, but it cannot perform the analysis for you.
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.
A five-session example to carry through the deck
Consider a fictional usability study of a workspace administration product. Five people who had recently been given an administrator role tried to invite a teammate and change that teammate’s access. All five could perform the task in the test workspace; the study concerned finding the controls, not differences in account permissions. The product team must decide which part of the interface to test next.
The records below are invented to demonstrate the analysis. They are observations, not participant quotations or results from a Presenti study.
| Session | Observed behavior | Context worth keeping |
|---|---|---|
| P1 | Opened the personal profile before finding workspace settings. | First week as an administrator. |
| P2 | Searched the personal profile, then used help to find workspace settings. | Had administered another product with profile-based controls. |
| P3 | Opened the personal profile, returned, and found the workspace menu. | Invited teammates before, but had not changed access. |
| P4 | Went directly to workspace settings and completed the task. | Had used this product’s administrator help previously. |
| P5 | Found workspace settings, then hesitated between two access labels. | Uncertain which label allowed editing. |
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.
Write the finding and its counterexample together
A defensible finding is: “Three participants first looked for access controls in their personal profile.” The evidence labels are P1, P2 and P3. P4 found the correct location immediately; P5’s difficulty concerned a label after reaching the right area. These are different problems and should not become one finding called “Permissions are confusing.”
One interpretation is that people associate access management with their profile. Another is that the workspace menu is hard to notice. P2’s experience with a different product could also affect the route they chose. The current notes do not isolate which explanation matters most.
Do not turn three observations into “60% of our customers cannot manage access.” This sample was selected for a particular task and administrator profile. GOV.UK’s guidance on analysing research sessions distinguishes observations, findings and possible actions. Keeping those stages visible helps an audience see where interpretation enters the story.
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.
A slide the product team can discuss
Use the title “Test access-control discovery before redesigning the whole permissions flow.” Place the P1–P3 observation on the left, P4’s direct route and P5’s label problem in a separate context box, and the proposed test on the right. The narrow decision is whether to investigate navigation. It is not approval for a complete permissions redesign.
The P5 label issue deserves its own note and possible test. Keeping it separate prevents the more frequent navigation observation from swallowing a potentially important access misunderstanding. A count tells you how often something appeared in these sessions; it does not settle the consequence.
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.
Make the next test answer the competing explanations
Prepare two prototype variants: one makes the workspace menu more visible while retaining the current wording; the other retains its position but changes the access-management wording. Keep the task and permissions identical. The researcher should decide how participants encounter the variants so that learning from an earlier attempt does not become an apparent design improvement.
Record the first place each person looks, whether they find the control without help, and the reasoning they give after attempting the task. Do not coach them toward the menu. If stronger menu visibility changes the route but the wording change does not, that would support one explanation in this test. If neither helps, revisit the starting assumptions rather than declaring the original finding wrong.
A useful meeting request is: “Authorize a focused prototype study of control discovery, led by the researcher with design support. Keep the label-comprehension question separate. Review the observed routes before committing to a navigation change.” No conversion uplift or customer-wide success rate follows from these five fictional sessions.
If the next step is a randomized product experiment, an experiment readout can separate the result, uncertainty, and release decision. A qualitative usability study is a different research design.
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.
