This is the fourth and final part of a series on design sprints. This post will cover the last two stages in the design sprint framework: Prototype and Test. It's an overview, not an exhaustive description. I'd recommend reading parts one, two, and three before reading this post.
The design sprint framework has five main stages: Understand, Sketch, Decide, Prototype, and Test. Each stage has activities from which you can pick and choose to tailor the sprint to your needs.
In the Prototype stage you'll build working prototypes of the sketches you voted on in the Decide stage.
It can be tempting to jump straight into code now that you've chosen a direction to pursue. Don't. Take some time to plan your build to ensure the remainder of your sprint goes smoothly.
Now that you've chosen a direction, it's time to map out the user flow. The storyboard activity really helps with this.
As a group you'll spend 30 minutes to an hour storyboarding how users will move through your prototype. This is also an excellent time to write the tasks you'll be using during testing. One of the goals of the storyboard is to make sure the prototype has all the screens necessary for testing participants to successfully complete tasks.
On average, you'll need to map out five to 10 screens or pages. Use whatever tools work best for your group. We usually work on a whiteboard. Discuss each screen/page and work with the testing facilitators to understand which components need to be detailed and which can be rough. The storyboard is also meant to help you understand where to put your time and effort with the build.
Once your storyboard is complete it's time to start building. Use your time efficiently by making a master list of tasks and assigning responsibilities. If you have a large group, consider breaking into smaller teams.
Give people deadlines and set clear expectations. If you're doing a multi-day sprint, you'll want to allow at least a day for prototyping. If you're only doing a day or half day sprint, you'll have to schedule time to prototype and test after the fact.
The fidelity of your build will be determined by your testing tasks and timeline. The goal here is to balance what you need to accomplish in testing with your time limitations. If your team is fast at building digital prototypes, use those. Paper prototypes are also a great way to test quickly. It's all about identifying what is best for your sprint.
During this stage the facilitator will want to keep an eye on the team and make sure no one drops out or misses a deadline. Check in early and often to keep things running smoothly.
Now that your prototype is done, it's time to test.
In a perfect world you'd have scheduled the usability tests before the sprint started. It's a great motivator and it helps ensure you actually get to testing. But if not, now's the time to get those tests scheduled.
You'll want to aim for five to 10 participants. That should be enough to start to see patterns emerge.
For more information about conducting usability tests read my previous post as a primer.
I would highly recommend incorporating as many sprint team members into the testing as you can. If possible, set up a system where the team can watch the tests in real time, but from a separate location. If that doesn't work, you can record the sessions so team members can listen to or watch them, or have team members sit in and help take notes.
The purpose of testing is to answer the questions you set out to solve at the beginning of the sprint. Do whatever you need to do to accomplish that.
Once the testing is complete, you'll want to summarize your findings into a format that is shareable with the team and stakeholders.
After the testing is done and the results are in, it's time to regroup and share your results with your team and your stakeholders.
Share the testing results with the sprint team before presenting to the stakeholders. Allow time for discussion and reflection.
If the results are positive, it's time to put together a presentation for stakeholders—explain what you did, the solution you arrived at, and the proof that the solution is viable.
If your testing results aren't positive, you'll need to spend some time as a group reviewing what might have gone wrong. You'll still need to put together a report for the stakeholders—sharing what you did, why it didn't work, and what to do next.
It's important that the stakeholder report be polished and thorough, especially if it is the first sprint you've done. The presentation is a way to demonstrate that the sprint was worth the time and effort, even if you didn't get the results you wanted.
You won't always succeed, and that's ok. Design sprints allow you to fail quicker, which is a savings in the long run.
You'll also want to do a short wrap up as a team. Thanking everyone for their help and giving them a chance to share insights. A good wrap up activity is three up, three down. In this activity everyone has the opportunity to share three positive things and three things to improve with the sprint. The facilitator should note these and use them to improve future design sprints.
Prototype and Test are the stages where the sprint can lose momentum. It is important for the facilitator to keep everyone engaged through continual check-ins and fostering discussion and collaboration as needed.
Schedule the testing sessions as part of sprint preparation. That gives the team a hard deadline to work towards.
It can also be helpful to schedule the stakeholder meeting during sprint preparation, as it can be difficult to get time on their schedules. This also provides another deadline that people can work toward.