How to Run a Design Sprint Kickoff Presentation

The design sprint kickoff presentation sets the frame for the entire week. A strong kickoff aligns the team on the problem, establishes working norms, creates psychological safety for divergent thinking, and builds enough shared context that the sprint can move quickly. A weak kickoff produces a team that spends Monday afternoon still debating scope.

What a Kickoff Is For

The kickoff is not the sprint — it's the preparation for the sprint. By the end of the kickoff, every participant should be able to answer:

• What specific problem are we trying to solve?
• Who is the user we're designing for, and what do we know about them?
• What does success look like for the sprint?
• How will the week work?
• What are the constraints we're working within?

If those five questions are answered clearly, the sprint can start. If any are fuzzy, the sprint will produce fuzzy outcomes.

Kickoff Presentation Structure

Opening: Why This Sprint, Why Now (5 minutes)

The sponsor or product lead opens by explaining the strategic context. What business problem is driving this sprint? Why is this the right problem to work on right now? What happens if we solve it, and what happens if we don't?

This is motivational context — it connects the week's work to something that matters. Don't skip it. Teams that understand the stakes make better decisions.

The Problem Statement (10 minutes)

Present the problem statement that the sprint will address. It should be specific enough to be actionable but open enough to leave room for solutions.

Good problem statement format: "[User] needs a way to [accomplish goal] so that [outcome]."

Spend time here. If the team doesn't agree on the problem statement, facilitate a brief alignment conversation before continuing. A sprint built on a disagreed problem is a sprint built on sand.

User Research Summary (15-20 minutes)

Present what's known about the users. This might include:

• Personas or customer archetypes
• Key insights from recent user research
• Jobs-to-be-done framing
• Customer journey maps
• Video clips of user interviews (2-3 minutes of actual user footage is more persuasive than a page of quotes)

Teams that have direct contact with the users they're designing for make better sprint decisions. If you have time, bring a real user in for a lightning interview at the start of the week.

Current State and Constraints (10 minutes)

Show what exists today — the product, the workflow, the interface, the customer experience. Make visible what the sprint is trying to improve.

Cover constraints explicitly:

• Technical constraints (what can't be built)
• Business constraints (what can't be changed)
• Regulatory or compliance constraints
• Timeline and resource constraints for implementation

Constraints are not creative enemies — they're the frame that makes the sprint tractable. A sprint with no constraints is a strategy discussion.

Sprint Process Overview (10 minutes)

Walk through the week structure. Most participants won't have run a design sprint before, and even experienced sprinters benefit from a clear agenda.

Day 1: Map and define — setting the long-term goal, mapping the user journey, choosing a target Day 2: Sketch — individual ideation, concept development Day 3: Decide — critiquing concepts, choosing a direction, creating a storyboard Day 4: Prototype — building a realistic test artifact Day 5: Test — five user interviews, synthesizing findings

Cover facilitation norms:

• One conversation at a time
• No devices unless contributing to sprint work
• Defer judgment during ideation
• Time-boxing is real — when the timer goes, we move on

Expert Interviews Preview (5 minutes)

If you've scheduled expert interviews for Monday (recommended), preview who's coming and what you'll be asking them. This primes participants to listen for specific information.

Common expert types: customer success, sales, legal/compliance, engineering lead, a real customer.

Sprint Questions and Success Criteria (10 minutes)

Close the kickoff by surfacing sprint questions — the things the team most wants to learn or test during the week — and the success criteria for the sprint.

Success criteria example: "By end of Friday, we'll know whether users can find and complete a payment dispute without contacting support, based on 5 user tests with our prototype."

If you can't write a success criterion for the sprint, you can't evaluate whether it succeeded.

Kickoff Slides Format

Kickoff slides should be functional, not polished. They're working tools, not a presentation. Use them to:

• Display the problem statement prominently throughout the week (print it and put it on the wall)
• Show research photos and quotes in full size
• Display the week's agenda and timing

One technique: give each team member a printed copy of the agenda and key slides. Some facilitators skip slides entirely for the kickoff and work on whiteboards or sticky notes from the start.

What Derails Kickoffs

Starting without alignment on scope. If the sprint is about "the checkout experience" and half the team thinks that includes the cart and half thinks it starts at payment, you'll lose Monday afternoon to a scope debate.

Too much information, too fast. Research summary of 40 slides for a kickoff is not a summary — it's a dump. Edit ruthlessly.

No participation from the decider. The design sprint requires a designated decision-maker who can say "yes, we're going this direction" when the team is stuck. If that person isn't in the kickoff, align on who they are before the sprint starts.

Skipping norms. Teams that haven't worked together before need explicit norms. Don't assume them.