Design Sprints: What Actually Works
A time-boxed process, typically five days, in which a small team moves from a problem to a tested prototype.
At a glance
- Typical length five days
- Phases understand, sketch, decide, prototype and test
- Team a small cross-functional group including a decision maker
- Output a prototype tested with users
Why it matters
Why it matters: Sprints compress weeks of debate into days and produce evidence from real users before expensive development.
Best practice
- Choose a focused, important problem
- Include someone with authority to decide
- Protect participants' time for the whole sprint
- Test with real target users
- Plan what happens after the sprint
Common pitfalls
Watch out for:
- Running sprints for small, well-understood problems
- Decision makers who drop in and out
- Testing with colleagues instead of users
- Treating the prototype as ready to build
When to call in a specialist
Bottom line Bring in help when a team is stuck on a high-stakes product decision.
Where this comes from
- Interaction Design Foundation — Design sprints
- Nielsen Norman Group — Design sprints
The figures and practices above come from the sources listed.
Working on something like this?
We take on UI & UX Design work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.