User Research Findings Presentation Template

User research findings often don't drive product decisions — not because the research is poor, but because it is presented poorly. A research report buried in a Confluence page or a raw Dovetail export that only the researcher reads is not useful. A well-structured presentation that translates observations into design implications and connects insights to specific product decisions is what moves teams.

The user research findings presentation is the bridge between the field and the roadmap. This template covers how to structure it so that product managers, designers, and engineers can act on what was learned.

Slide 1: Research Overview and Objectives

Open with context. The audience needs to understand what question the research was designed to answer before they can evaluate the findings.

Include:

• Research question: the specific product or design question that motivated the study (e.g., "Why are users abandoning the onboarding flow after step 2?" or "What do enterprise users need from the reporting dashboard that they are not getting?")
• Research type: what method was used and why (moderated usability study, contextual inquiry, diary study, concept testing, card sort)
• Timeline: when the research was conducted
• What decisions this research will inform

Frame the research objective as a question, not a topic. "Understanding user behavior in the checkout flow" is a topic. "Why are users with more than five items in their cart abandoning checkout at the payment step?" is a question that leads to actionable findings.

Slide 2: Methodology

Describe how the research was conducted. This slide establishes the credibility of the findings by explaining how they were generated.

Cover:

• Method description: what participants did, how sessions were run (moderated or unmoderated, remote or in-person)
• Session structure: duration, activities, stimuli used (prototypes, production interface, paper concepts)
• Number of sessions and total participants
• How participants were recruited and screened
• Any methodological limitations that affect how findings should be interpreted (e.g., unmoderated studies may not capture why users behaved a certain way)

Be honest about limitations. A usability study with five participants is not statistically representative — it is designed to surface qualitative patterns. Overstating the representativeness of qualitative research undermines trust when stakeholders push back.

Slide 3: Participant Profiles

Make the participants real to the audience. Product teams make better decisions when they understand who was studied.

For each participant segment (or for the full group if homogeneous):

• Demographic profile (age range, relevant experience level, device or platform used)
• Relevant behavioral characteristics (how often they use this type of product, their comfort with technology, their primary use case)
• Key differentiators between segments if multiple segments were included

For moderated studies with five to eight participants, consider including a brief profile card for each participant — a pseudonym, their role, their relationship to the product, and one notable observation. This gives stakeholders anchors when findings are discussed.

Slide 4: Key Findings Overview

Before diving into individual findings, give the audience a map of what you found.

Present:

• A one-sentence summary of the overall picture (e.g., "Users understand the core concept of the product but struggle with the configuration step, which is where all observed task failures occurred")
• A numbered list of the three to six most important findings, ordered by severity or impact
• For usability studies: a severity rating for each finding (critical, major, minor) using a consistent scale you define

This overview slide should stand alone — someone who only reads this slide should understand the most important things you learned.

Slide 5–8: Individual Findings (one slide per major finding)

Each major finding gets its own slide. The structure of each finding slide is the same:

Finding title: A specific, actionable statement — not a vague topic label. "Users do not realize the save button applies to all items, not just the current row" is a finding. "Save button confusion" is not.

Evidence: What you observed. Direct quotes, behavioral descriptions, screen recordings, or annotated screenshots. Show the evidence — don't just assert the finding. If six out of eight participants made the same error, say so. If three participants expressed the same frustration in their own words, quote them.

Frequency and severity: How many participants exhibited this behavior or expressed this sentiment? Was it consistent or variable? For usability issues, was task completion affected or was it a friction point that did not prevent task completion?

Why it matters: Connect the finding to the user's goal and the business objective. A finding that prevents users from completing a core task is critical regardless of its frequency. A finding that affects only a rare edge case is low priority regardless of how surprising it is.

Design implication: What does this finding suggest should be changed, and in what direction? The implication should be directional (e.g., "The primary action needs to be more visually prominent and positioned closer to where the user's attention is focused at that point in the flow") not a prescriptive design solution. Design implications drive design exploration — they are not specs.

Slide 9: Patterns Across Findings

After presenting individual findings, step back and identify the patterns that connect them.

Common cross-finding patterns:

• Mental model mismatches: does the product's conceptual model differ from how users think about the task?
• Information architecture problems: do users look for things in places the current structure doesn't support?
• Progressive disclosure failures: is critical information hidden behind steps users don't take?
• Trust and confidence gaps: do users hesitate or second-guess themselves in ways that reveal uncertainty about the product's behavior?

A well-observed pattern is often more useful than individual findings because it points to a root cause that, if addressed, resolves multiple surface-level issues.

Slide 10: What We Didn't Learn

This slide is often omitted — and it shouldn't be. Being explicit about the limits of the research helps stakeholders calibrate how much confidence to place in the findings and what additional research is needed.

Include:

• Questions the research was not designed to answer
• Segments that were not included and why
• Behaviors or motivations that the method could not capture
• Follow-up research that would fill the most important gaps

Research that acknowledges its own limitations is more credible than research that claims to have answered everything.

Slide 11: Prioritized Recommendations

Translate findings into a prioritized action list. The audience for this slide is product and design leadership — they need to understand what to do, roughly in what order, and why.

Format: | Priority | Recommendation | Finding It Addresses | Estimated Effort | Expected Impact | |---|---|---|---|---| | 1 | Redesign the payment confirmation step to show the full order summary before asking for payment authorization | Finding 3 (payment abandonment) | Medium | High — addresses the most common task failure | | 2 | Add inline guidance to the configuration step | Finding 1 (configuration errors) | Low | High — low effort, high frequency issue | | 3 | Move the save confirmation message above the fold | Finding 2 (save confusion) | Low | Medium |

The priority column is a judgment about impact relative to effort — which improvements will have the greatest effect on the outcomes that matter, achievable in the shortest time.

Slide 12: Recommended Next Steps

Close with the specific next steps, owners, and timelines.

Include:

• What design explorations or prototypes should be developed in response to the findings
• What the validation plan is for the proposed solutions (what research would test whether the solutions work)
• Who owns each next step and the target completion date
• Any decisions that leadership needs to make before design exploration can begin

A research presentation without a next steps slide ends in discussion without action. The next steps slide converts findings into a work plan.

---

Facilitating the Discussion

After presenting findings, the most valuable thing a researcher can do is facilitate a structured discussion that connects findings to product decisions.

Discussion prompts that work:

• "Which of these findings changes anything we are currently building?"
• "Are there any findings that confirm assumptions we were acting on already?"
• "Which finding, if we addressed it, would have the greatest impact on the metric we care most about?"
• "What would we need to see to be confident a proposed solution works?"

The goal is not debate about the findings — it is productive disagreement about priorities and solutions.

---

Common User Research Presentation Mistakes

Leading with methodology before context. Tell people what you found and why it matters before explaining how you found it.

Presenting raw observations without synthesis. Quotes and behaviors need to be interpreted, not just displayed.

Fifty slides of findings. If everything is a finding, nothing is. Ruthlessly prioritize. Three great insights drive more change than fifteen adequate ones.

No design implications. Findings without implications leave designers to make the connection themselves — inconsistently.

---

Build Your Research Findings Presentation

slide-deck.io generates user research findings presentations with structured finding slides, severity matrices, prioritized recommendation tables, and participant profile templates — built for UX teams that need to turn research into product decisions.

Create your research findings presentation