User Research Findings Presentation Template

User research generates data. The presentation is where data becomes decisions. A findings presentation that leaves the room with "interesting, thanks" has failed. One that ends with clear alignment on what to do next has done its job.

The structure below works for usability studies, generative interviews, diary studies, and survey research. Adjust the depth of each section based on study size and stakes.

Before the Presentation

Research findings presentations fail most often because the presenter leads with methods rather than insights. Stakeholders don't need to understand your research process — they need to understand what you found and why it matters.

Before building the deck, write down your top three findings in plain language. If you can't state each finding in one sentence, the synthesis isn't finished.

Slide Structure

Slide 1: Research Question

One slide. What question were you trying to answer? "Why are users not completing the onboarding flow?" or "What mental models do users bring to inventory management?" This orients the audience before any data appears.

Slide 2: Study Design (Brief)

Method, participant count, and recruitment criteria — three bullet points maximum. This slide exists to give findings credibility, not to explain research methodology. If someone wants more detail, they'll ask.

Slide 3: Who We Talked To

A short participant summary. Not individual names — aggregate characteristics that matter for interpreting the findings. Industry, role, experience level with the product, specific behaviors you screened for. If you conducted surveys, include the response count and confidence interval.

Slides 4–8: Key Findings

One finding per slide. Each slide should have:

• A clear headline that states the finding — not "Onboarding Findings" but "Users abandon onboarding when asked for credit card details before seeing product value"
• Supporting evidence — 2–3 direct quotes, a behavioral observation, or a data point
• Frequency or severity context — how many participants, how often, how critical

Resist the urge to show everything you found. A presentation with 14 findings of equal weight communicates nothing. Force a hierarchy. What are the 3–5 findings that most directly affect product decisions?

Slide 9: Patterns and Themes

After individual findings, step back to the synthesis. What do these findings have in common? What underlying user need or mental model do they reveal? This is the most valuable analytical contribution you can make — connecting individual data points to a coherent understanding of user behavior.

Slide 10: Implications

What does this mean for the product? This slide translates findings into design directions or product hypotheses. Not specific solutions — directions. "Users need to understand the value proposition before committing payment information" is an implication. "Add a free trial button" is a solution, and prescribing solutions in a research presentation skips the design process.

Slide 11: Recommended Next Steps

Concrete actions with owners. Research recommendations that aren't assigned to anyone will not happen. Options:

• Prioritize a specific problem area for a design sprint
• Run a follow-up study to validate a specific hypothesis
• Test a specific design intervention with users before building
• Add a specific metric to the product analytics dashboard

Slide 12: Appendix

Raw data that supports the findings but doesn't belong in the main deck. Full quotes, session recordings, survey cross-tabs. Include the link or the material here for anyone who wants to go deeper.

What to Emphasize in Your Presentation

Quotes are evidence, not decoration. A quote that directly illustrates your finding is worth including. A quote that's tangentially related adds noise. Be selective.

Show the data behind the claim. "Most users struggled with X" needs a number. "7 of 10 participants" or "64% of survey respondents" is more credible and more actionable than "most."

Separate what you observed from what you infer. "The participant clicked the back button immediately after seeing the price" is an observation. "Users are price-sensitive" is an inference. Label them differently — stakeholders trust the distinction.

Don't defend the findings. If a finding contradicts a stakeholder's assumption, present the evidence calmly. Your job is to represent what users did and said, not to argue for a particular design direction.

Common Mistakes

Organizing by session rather than by theme. "What we heard in session 1, session 2..." is not synthesis. Group findings by theme, not by when you collected them.

Burying the lead. The most important finding should be slide 4 or 5, not the last slide before the appendix.

No explicit connection to decisions. Research that doesn't connect to a product decision is interesting but not useful. End every findings presentation with a clear "so what" — what decision or direction does this research inform?