UX Research Findings Presentation

UX research findings that don't change decisions are research that wasn't worth doing. The presentation of research findings is not the end of the research process — it's the beginning of the translation process, where observations from users become decisions about the product. A findings deck that produces vigorous discussion and concrete roadmap changes did its job. A deck that produces "interesting, thanks" did not.

The failure mode is almost always the same: too much data, too little synthesis. Researchers who present every observation, every quote, and every theme in exhaustive detail bury the signal in the volume. The audience leaves knowing that you did a thorough study — and uncertain what to do about it.

The Insight Hierarchy

Before writing a slide, organize your findings into an insight hierarchy. Not all findings are equal. Some observations are interesting curiosities. Some are significant patterns across multiple participants. Some are critical issues that are currently causing users to fail at their primary goal. The presentation should reflect this hierarchy explicitly.

Level 1 — Critical issues: User failures. Tasks that a significant percentage of users couldn't complete. Mental models that are systematically wrong and produce errors. These require immediate product action.

Level 2 — Significant patterns: Behaviors or attitudes that appeared consistently across multiple participants and have clear product implications. Not failures, but friction that consistently produces frustration or workarounds.

Level 3 — Interesting observations: Single observations, edge cases, or context that's worth flagging but doesn't rise to the level of a pattern. Goes in the appendix or is noted briefly in context.

The body of your findings presentation should cover Level 1 and Level 2. Level 3 is for the appendix or for researchers who want the full dataset.

Research Context Slide

Open with a slide that answers: what question were we trying to answer, who did we talk to, and how? This grounds the audience in the study before they're asked to absorb findings.

What this slide includes:

• Research objective in one sentence: "We wanted to understand why enterprise users aren't completing the integration setup within the first week."
• Participant profile: number of participants, their characteristics (role, company size, tenure), and how they were recruited.
• Methods used: usability sessions, interviews, diary study, survey, analytics — with brief note on what each method was designed to surface.
• Study period: when the research was conducted.

Why this slide matters:

Audiences who don't know who was studied will ask — and the answer affects how much weight to give the findings. "We talked to 8 users" means something different if those are 8 random signups vs. 8 users from the 50 accounts that churned in the last 90 days. The context slide preempts the credibility questions and lets the audience focus on the findings.

The Insight-Evidence Structure

Each significant finding should be presented with the same structure: the insight, the evidence, and the implication.

The insight: A declarative statement of what you learned. Not "some users had trouble with X" (weak, vague) but "users who complete setup without completing step 3 fail to connect their data source and abandon the workflow." Present the insight as a specific, falsifiable claim.

The evidence: The data that supports the insight. This can be direct observation counts ("7 of 8 participants skipped step 3 without noticing it"), user quotes ("'I thought I was done after the configuration page — I didn't realize there was another step'"), behavioral data from analytics, or a video clip if available. Evidence makes the insight credible and provides material for stakeholders who want to see the raw data.

The implication: What this finding means for the product. Not your recommendation yet — just the clear statement of what the finding implies. "Step 3 is not recognized as mandatory by users completing setup independently without guidance." This is distinct from the recommendation (add a progress indicator, make step 3 unavoidable, add inline help text) which comes later.

One slide per major insight. Don't combine two insights on one slide — each insight deserves full attention and the combination makes it harder for the audience to discuss one without the other.

Showing Evidence Effectively

Evidence in a UX research presentation can take many forms. Choosing the right format for the evidence type matters.

User quotes: Presented as pull quotes with context. Include the participant profile (a few words, not a full description: "enterprise user, 8 months on platform") so the audience can evaluate the quote's relevance. Don't cherry-pick outlier quotes — use quotes that represent the pattern, not the most dramatic individual case.

Video clips: A 30-60 second video clip of a user encountering a problem is often more persuasive than any amount of descriptive text. Stakeholders who watch a user fail at a task they designed feel the friction in a way that reading about it doesn't produce. Keep clips short and focused — a five-minute video of a usability session loses the room.

Completion rates and task metrics: For usability studies, show task completion rates, error rates, and time-on-task as data tables or bar charts. Contextualizing these against benchmarks or prior study results ("task completion improved from 42% in our March study to 67% in this study") adds meaning to absolute numbers.

Journey maps and flow diagrams: For research that surfaced a systemic flow problem, a simplified journey map or decision tree showing where users deviate from the intended path is more useful than describing the deviation in prose.

Affinity diagrams (simplified for stakeholders): If your analysis produced an affinity diagram, don't show the full complexity. Show the top-level themes and the count of observations in each theme, with two or three representative quotes per theme. The full diagram belongs in the appendix for researchers.

Recommendation Slides

Recommendations are separate from findings — and this separation should be explicit in the deck. Findings are what you observed. Recommendations are what you think the product should do in response.

The recommendation structure:

State the recommendation specifically. "Add a progress indicator that shows all setup steps, with the current step highlighted, on every page of the setup flow" is a recommendation. "Improve the onboarding experience" is not.

Tie the recommendation back to the finding. "Based on Finding 2 (step 3 isn't recognized as mandatory), we recommend..."

Include a priority tier. Not all recommendations are equally urgent. Tier them:

• High priority: Directly addresses a critical issue causing user failures. Should be in the next sprint.
• Medium priority: Addresses a significant pattern causing friction. Should be in the next quarter's planning.
• Exploratory: Worth investigating further before committing to an implementation. Should be on the research backlog.

Include estimated impact where possible. A recommendation that removes a step completion blocker for a task that 60% of users attempt is more impactful than one that improves the experience of a task that 10% of users attempt. Quantified impact helps product and engineering teams prioritize.

Connecting Findings to the Roadmap

The findings presentation should end with an explicit connection to roadmap decisions — which is where the research actually creates value.

Roadmap alignment slide:

For each high-priority recommendation, note whether it connects to an existing roadmap item (and suggests the item's priority), suggests a new item that isn't currently on the roadmap, or contradicts the direction of a current roadmap item.

The last category requires care. Research that suggests the team is building the wrong thing is high-value but difficult to present. "This finding suggests that Feature X, which is scheduled for Q3, may not solve the problem users are actually experiencing" is the honest statement. Delivering it with evidence (not opinion) and with a recommended alternative (not just a problem) produces productive responses rather than defensive ones.

The decision request:

End the presentation with specific decisions you're asking the team to make. "Based on this research, we're requesting: (1) prioritization of the progress indicator fix in the next sprint, (2) a follow-up research session with the three users who couldn't complete setup to validate the proposed solution, (3) a revisit of the Q3 Feature X scope in light of Finding 4." Specific asks produce specific responses. "Let us know what you think" produces a meeting that ends without decisions.

Presenting to Different Audiences

For engineering teams: Lead with specific, technical findings. Engineers want to understand exactly what's broken and how users are experiencing it. Include the behavioral data, the task flow where failures occurred, and specific error messages users encountered. Video clips are particularly effective.

For product leadership: Lead with strategic implications. How do these findings affect the roadmap? Which bets are validated, which are challenged? What would change if these recommendations were implemented?

For executive stakeholders: Lead with business impact. How do these findings connect to retention, conversion, or growth? Frame findings in terms of users who churned, deals that weren't won, or customers who didn't activate — concrete business outcomes that give research findings financial weight.