Design Sprint Results Presentation Template

A design sprint produces a prototype and user test results in five days. The results presentation determines whether that work leads to product decisions or gets filed away.

The sprint produces answers to a specific question. The presentation communicates those answers clearly enough that stakeholders can act on them.

Who Attends and What They Need

Leadership and decision-makers: Need to understand whether the sprint validated or invalidated the core hypothesis, and what the recommended next step is. They don't need the blow-by-blow of each day's activities.

Product and design team: Need to understand what specific user behaviors and reactions the prototype revealed, and which design directions are worth pursuing.

Engineering: Need enough detail to assess feasibility of the validated direction and surface any technical concerns before committing to development.

Keep the main deck focused on findings and recommendations. Put process detail in the appendix for people who want it.

Slide Structure

Slide 1: The Challenge

One slide restating the problem the sprint addressed. "How might we help new users reach the first value moment before the end of their first session?" The challenge statement keeps the audience focused on what success looks like before they see the prototype.

Slide 2: Sprint Question

The specific question the team set out to answer. "Will users understand how to create their first workflow without onboarding assistance?" A sharp sprint question makes the results easy to evaluate — you either got an answer or you didn't.

Slide 3: The Prototype

Show the prototype. Screenshots of the key screens, a recorded walkthrough, or a live demo if the stakeholders' environment allows it. Keep this brief — the prototype is context for the findings, not the main event.

For remote presentations, a 2-minute screen recording of the prototype flow is usually more effective than a live demo that can encounter technical issues.

Slide 4: How We Tested

Test format (moderated remote, in-person), number of participants, and recruitment criteria. This establishes the credibility of the findings. Five users completing realistic tasks with a think-aloud protocol is a different level of evidence than three internal team members reviewing the designs.

Slide 5: What We Hypothesized

The assumptions the prototype was designed to test. Stating hypotheses before results keeps the evaluation honest — it's too easy to retroactively interpret ambiguous findings as validation.

Slides 6–9: Key Findings

One finding per slide. For each:

Headline: A specific, observable result. "4 of 5 users created a workflow in under 3 minutes without assistance" or "Users did not notice the secondary action CTA in the bottom right corner."

Supporting evidence: What users said or did. Quotes and behavioral observations are more compelling than summaries.

What it means: The implication for the design direction.

Separate confirmed hypotheses from invalidated ones from inconclusive findings. Mixing them produces confusion about what was actually learned.

Slide 10: What We Validated

The specific hypotheses the testing confirmed. This is not the same as "what worked" — it means the prototype produced evidence that the team's assumptions were correct. Be precise about what was actually tested vs. assumed.

Slide 11: What Was Invalidated

The hypotheses that the user testing disproved. This is often the most valuable output of the sprint. A design direction that fails quickly and cheaply in a prototype stage fails much less expensively than one that fails in production.

Be direct about what this means. "The proposed navigation pattern consistently confused users who expected to find X in the main menu. This direction needs to be reconsidered."

Slide 12: Decision Point

This is why the sprint happened. Present three options and a recommendation:

Option 1: Proceed to development — if the prototype validated the approach strongly enough to build from it. Specify what level of additional design work is needed before engineering begins.

Option 2: Run another sprint iteration — if the testing revealed a fundamental design direction problem that warrants another round. Specify what the next sprint question would be.

Option 3: Pivot or pause — if the testing invalidated the core assumption. What does the team now know about the problem that should change the strategy?

Make an explicit recommendation. Presenting all three options without a recommendation puts the decision burden on stakeholders who have less context than the sprint team.

Slide 13: Next Steps

If you're recommending option 1 or 2, what specifically happens next? Design tasks, engineering scoping sessions, additional research, decisions that need to be made. Assign owners and timelines before the meeting ends.

Common Mistakes

Presenting the sprint activities instead of the results. Nobody needs to know what happened on Monday of the sprint. They need to know what the testing revealed.

Treating weakly supported findings as confirmed. One participant struggling with a flow is an observation. Four of five participants struggling is a finding. Be clear about the difference.

No explicit recommendation. The sprint team has more context than anyone else in the room. Own the recommendation rather than leaving it open.