Pre-sprint
Notify all members of the sprint to set up the expectation of anything that they need to complete before the sprint and what to expect during the sprint.
Review roles for the sprint
Facilitator Leads the design sprint. Guides the sprint from start to completion.
Recorder Takes notes, photographs and is in charge of the documentation for the sprint.
Product Owner Typically the client and/or the person with the initial product vision. This person has final say in the product.
Set expectations for the outcome for the sprint
Sometimes, design sprints converge on solutions that are partially or completely invalidated. Some things will have worked, and others won't. Make sure everyone understands that the outcome falls in one of three buckets:
Most stuff worked
This often doesn't happen during the first sprint on a project, but if it happens to you, everyone on the team is probably on the same page about the fixes and tweaks you need to make.
What to do next: Take a week to tune your existing prototype. Create a backlog for developers to start implementation of the most important features or API integrations.
Some big questions
A common outcome after a user study is a mixed bag: a few hits, a few tweaks, and a couple of real head-scratchers. Fortunately Keynote or Invision prototypes are easy to change, and as long as some parts of your design are solid, you can probably build on what you have.
What to do next: You can move fast on the tweaks, but you’ll want to come up with multiple solutions for the bigger problems. Start your next sprint at step 2 (Diverge).
Everything exploded
We've seen a lot of designs go up in flames, and that's OK. You learned that something didn’t work, and it only took you a few hours to build it. This is great progress, and very cheap relative to building and launching a full product. Think what would have happened if you’d spent weeks or months implementing this solution!
What to do next: Start your next sprint back at the drawing board with step 1 (Understand). (Hint: the results of this study are perfect fodder for reviewing and building understanding as a group.)
Review design sprint documentation and schedule
The moderator of the sprint should be reviewing design sprint documentation and coming up with a plan specific to the project of feature set. Typically done by the Facilitator.
Gather existing research and information
Learning from previous product design sprints, existing product or other test and research done. Typically done by the Product Owner.
Capture existing competition
Any potential competition that solves the same or similar problem that the sprint is trying to solve. This should include lowest common denominator competitors such as email and offline tools. Typically done by the Product Owner.
Set up room
Make sure you have a room big enough to fit all of the people in the sprint. The room would have a whiteboard and a place to pin or tape up sketches. Typically done by Facilitator.
Buy supplies needed for sprint
Sharpies
Post-its
Blank sheets of Printer paper
Whiteboard markers
Circle vote stickers
Easel Pad
Typically done by Facilitator.
Schedule 4–6 people for interviews / usability tests
Only if users are already identified. Otherwise this should be held off till after Understand. During Test, we'll be running a user study, showing the prototype to 4–6 real people. Learn how to recruit great participants for your study here. Typically done by Product Owner.
Last updated