Let’s be honest: the term “design sprint” gets thrown around a lot.
Depending on who you ask, it’s either the secret to innovation or a glorified brainstorm with sticky notes.
So here’s the no-spin, engineering-grade truth:
Design sprints are not BS — but most versions of them are.
What a Design Sprint Actually Is
Originally developed by Google Ventures, a proper design sprint is a focused, five-day process to:
- Define a real product or user problem
- Explore multiple solution paths
- Prototype a core concept
- Test it with real users — fast
The value isn’t in the theatre. It’s in:
- Forcing alignment early
- Making directional decisions before heavy investment
- Reducing risk through quick feedback
At Maddison, we’ve used sprint-style approaches to:
- Validate UI direction for diagnostic platforms
- Explore product forms for wearables
- Kill speculative features before they burned budget
Case Example: Future Care
In developing their remote infant monitoring system, we ran a structured 4-day co-creation and validation sprint with parents, clinicians and engineers. It aligned the clinical need with carer UX and helped us discard an entire app workflow that was elegant on paper but broken in practice.
Where the BS Creeps In
Design sprints go off the rails when:
- No real users are involved
- Stakeholders aren’t in the room
- There’s no prototype, just post-its
- It’s run like a team-building day with Sharpies
- The outcome is pre-decided, and it’s just theatre
That’s not a sprint. That’s innovation karaoke.
We’ve seen major corporates spend £50k+ on sprints that produced nothing testable, no decisions, and no movement. Everyone left with photos of colourful walls and no clue what to do next.
When Design Sprints Are Genuinely Useful
They work when:
- The problem is real, but poorly defined
- You need cross-functional alignment fast
- There’s appetite to test assumptions early
- Decision-makers are involved
- You’re open to killing the idea if it fails
They fail when:
- It’s pure execution work
- Leadership is absent or disengaged
- The team wants validation, not truth
- The goal is a glossy artefact, not a learning loop
Our Take at Maddison
We don’t sell sprints as magic bullets. We use them as practical, time-boxed tools to:
- Cut through internal debate
- Get real feedback before committing resources
- Build momentum by forcing trade-offs
Example: Keeler Loupe Systems
A two-day sprint helped resolve conflicting feedback from surgeons on weight distribution vs. optical performance. We built and tested form rigs in-session to prioritise what mattered most for usability.
Bottom Line
Design sprints are like CrossFit:
- Done right → Strong, fast results
- Done badly → Smug noise, no progress
If you’re calling any workshop a sprint, or running them with no users and no decisions, that’s marketing smoke.
If you want to stress-test assumptions, align real stakeholders, and make a directional call fast—it might be time to sprint.
Want to run a sprint that actually works? Let’s talk.
Rob Butterfield
Managing Director
rob.butterfield@maddison.co.uk