When to run a design sprint
Design Sprints are powerful, but not a one-size-fits-all solution. They’re ideal for tackling ambiguity — new products, features, and ideas — but less useful for polishing what already works. Knowing when not to run a sprint is just as important as knowing when you should.
Not everything should be run as a design sprint.
Design Sprints are powerful, but they’re not magic.
They can help teams move quickly from idea to insight, but they’re not right for every problem. As Justin Zalewski, Design Lead at Studio Science, puts it:
“Design Sprints aren’t a one-size-fits-all solution.”
And that’s a good thing. Knowing when not to run a sprint is as valuable as knowing when you should.
What Design Sprints are great for
Sprints shine when the challenge is ambiguous, the stakes are high, and decisions need to be made fast.
They’re particularly useful for:
- Creating new products – when you’re starting from zero and need to define direction fast
- Entering new markets – to test assumptions before major investment
- Developing new features – especially when the “how” isn’t obvious
- Defining marketing strategies – to align creative teams and validate messaging early
In short: if you’re dealing with unknowns, a Design Sprint helps you get clarity and evidence quickly.
The snake-oil statement
I'm not in the business of forcing every project through the same process. A Design Sprint isn’t a ritual - it’s a tool, and tools are only useful when they fit the problem.
Here’s when a sprint tends to work best:
- Kickstarting a large or complex project
- When stakeholders want to see something before committing significant time or money
- To start testing early ideas with real users
- For new features where there are multiple unknowns
- To improve a specific part of an existing product (like delivery within a checkout flow)
- To begin solving a messy or unclear problem
- To explore radical ideas and build alignment fast
- When a team needs fast, consensual progress
What Design Sprints aren’t good for
Sprints don’t add value when the challenge is already well-defined or the solution is incremental. For example:
- Full website redesigns – these need ongoing UX work and systems thinking, not a five-day sprint
- New designs for page templates – better suited to standard design cycles
- Low-impact iterations – use A/B testing or a strong design team instead
In summary
Design Sprints are best for framing and testing ideas early, not refining finished products.
They thrive on uncertainty — when the path isn’t clear, when the team needs momentum, or when leadership needs confidence to move forward.
If you’re certain about the problem and just need to execute, skip the sprint and build.
If you’re unsure what the right problem is, start sprinting.
