18 Tips to Run a Design Sprint – UX Planet
We’ve talked about Design Sprints plenty of times, and have already explained why we truly believe it’s a method that’s here to stay. Yet in order for it to actually work, it has to be used wisely. So, here are some tips we believe will help you to take advantage of each and every sprint.
Written by Lateral View — Product Design Team
First thing you need to know: we love Sprints. We love seeing how everything evolves in just a couple of days, we love getting to know the client, their company and their team and how they work, articulate each area, think and make decisions. We believe Design Sprint is key both at the beginning of each project to validate product ideas and for specific features or challenges of products that already exist. Also, some of us had the chance to attend a Jake Knapp workshop last year and we’ve all have worked on several Sprints all year round, that’s why we decided it would be nice of us to transmit some of the things we’ve learned and helped you enjoy these tiny rollercoasters we call Sprints.
#1 Trust The Process
The first piece of advice we are going to give, especially if it’s the first Design Sprint you carry out is to trust the process. At times you can find yourself thinking that it will be useful, faster or easier to change this or that step but once you complete the whole Sprint you will see how everything fits together perfectly. Sprints let us simplify a complex idea or problem and test it quickly with real users. What’s interesting of the whole process is the feedback. You need to go step by step in order to get the feedback.
#2 You Need a Multidisciplinary Team
Jake Knapp addresses this in his book. You need to get as many points of view as you can in order to get proper results. You’ll probably want to include someone who has financial knowledge, someone with marketing knowledge, a technical representative and a designer. You will also need experts in the subject you are dealing with and a decision maker that’s frequently provided by the client, usually, it is the CEO, a VP or some team leader. It has to be someone who has the power of decision making.
The team should not consist of more than 7 people. If the client wishes to include more you can invite them at the beginning of the Sprint’s week and let them act as experts and participate in the interviews.
#3 Let Coworkers Know You are Going to be Busy
In Jake Knapp’s book, he establishes as an ideal Sprint a week long one. Later and together with the agency AJSmart — we recommend reading the tips this agency gives — they’ve reduced the method to a 2.0 version that is done in 4 days optimizing the time spent on some exercises. We have done sprints of both 4 and 3 days (these last ones included some extra hours on the day of prototyping). When time is tight and it’s difficult to get time away from other meetings and responsibilities for 5 days, doing it in 3 days can be hard but useful.
In any case, we recommend letting every coworker know what you’ll be up to during those days. This will prevent them from bothering you with non-urgent issues and, on the other hand, when doing a 3-day Sprint you may need some extra hands at some point especially recruiting users to test the prototype during the last day of the Sprint.
#4 Facilitators, Align Expectations
The facilitator should be clear and explain what the team is going to be working on and which are the expectations. Besides, during the Sprint he or she should be attentive and make sure that no one is left behind or thinking of something other than the Sprint. It may happen that expectations from each member differ and it’s key to make sure everyone is on the same page.
#5 Facilitators Don’t Make Decisions
This tip is short but important. Always remember: the facilitator does not make decisions. The facilitator repeats the decisions that have been made during the Sprint by the team. It’s not the facilitator’s role to make decisions.
#6 Set the Mood and Space
The Sprint team must be comfortable and you must avoid any distractions. There must be something to eat and eat available at any time. We recommend healthy snacks not to fall asleep in the middle of the sprint.
Also, having several boards available is key. You need to have all the information you gather written where everybody can see it. Once we did a Sprint in a meeting room that had to be left exactly as we had found it every day. This means cleaning everything up at the end of each day (at least an extra half hour) and copying everything back to the boards at the beginning of each day (another half hour). Be sure to avoid this if possible.
Finally, having a list of music that sets a concentration mood will be very useful for when you have to perform exercises individually.
And, of course, you need to have:
- Yellow 3-by-5 sticky notes
- Black, green and red whiteboard markers
- Black felt-tip pens
- Printer paper
- Small and large dot stickers
#7 Break the Ice
The team that participates on the Sprint needs to get along in order to kick it off. Designers and Developers usually know each other. In my case, we work at Lateral View, a digital product agency, and we always provide those roles and already have experience participating in Sprints. This usually helps to break the ice with the client and the rest of the team. But usually, you need extra help to meet with each other. So we recommend spending a few minutes during the first day’s morning doing some let’s-get-to-know-each-other exercises to wake up and get moving.
#8 Plan Ahead Your Interview Questions
The team will learn a lot from the expert interviews, but since it is the exercise with which you will start the Design Sprints, we recommend jotting down some questions beforehand in order to help keep the pace during the interviews. Questions such as: What does this product do? Who uses it? What problem do you want to solve? Where is this product used? If the product exists, who uses the product now and who do we want to use it in the future? How do you imagine this product in 2 years? Will certainly help you to cover everything you need to know.
#9 Avoid Never Ever Ending Group Discussions
In chapter 9, “Sketch”, Jake Knapp talks about why individual exercises are so important and should be followed by a voting and pooling process. He states: “We know that individuals working alone generate better solutions than groups brainstorming out loud.”.
We think it’s the reason why we don’t believe Focus Groups give any effective or real feedback. There are natural leaders that condition results and can prevent other members from communicating their ideas. During the stage of ideation, Jake Knapp suggests it’s better to work individually and then make an anonymous gallery of ideas and vote.
Long debates also exist while defining the long-term objective and the Sprint Questions or the StoryBoard. So we usually prefer to make every team member individually write theirs in post-its and then vote. This accelerates these exercises and allows you to keep the pace and avoid eternal discussions.
#10 Keep The Map Simple
Use the structure Jake Knapp shows in his book. Don’t pursue absolute perfection and don’t get entangled on a billion tiny details. You need to get to The Big Picture.
#11 Don’t You Ever Ignore the How Might We
All those problems shaped as opportunities help you define the target and see where the team feels the challenge is. When you organize the HMW and place them on the map you get many answers. They are not just notes and should not be forgotten or missed.
#12 Don’t Make It, Fake It!!!
Using Marvel or Figma, which are online platforms that allow different team members to work on the same project, helps a lot and lets you create the prototype faster since everyone can work simultaneously and nobody has to be compiling a final version. We really recommend investing some time in doing a pre-test before launching the prototype on the testing day.
#13 Find Testers Beforehand
This is not in the book but we strongly advise to arrange several test appointments previously and add extra ones because some users probably won’t make it to the meeting even though they have confirmed and reconfirmed plenty of times.
#14 Prepare Your Testing Script
It seems quite obvious, but the adrenaline of finishing the prototype and having it ready to test can make you skip this step. Like any usability test, we need to have a script that let us test what we need to test.
Jake Knapp advises assembling the key points in the flow in the rows of a grid on a blackboard and the participating users in the columns so that everyone can take notes quickly and paste them. By doing this, you’ll understand results at a glance. You’ll be able to see the patterns of what was positive and negative feedback. This grid can be completed in printed out sheets but it’s not as good or visual as the blackboard.
#15 Create a Comfortable Testing Space
Create beforehand an explanation in order to introduce the product to the user. The facilitator and the user need to be in a comfortable space. It’s not an exam and it’s important to say this. Users should not feel under pressure. They need to be relaxed. You can spend a few minutes on small talk in order to make them feel comfortable.
Whether it’s a real meeting or a virtual one through Meet or Skype you also need to be able to share your screen with the rest of the Sprint team and be sure you have the right technology (a mic, for example) to transmit what happens during the testing to another room where the rest of the team observes the test and take notes. Asking the user to think aloud is also very important to get raw feedback.
*Bonus Track: We use LookBack to optimize user testing. It’s a simple tool that lets you stream the test to the rest of the team.
#16 Don’t Panic, Take a Break
Do not be scared if the Sprint gets untidy or out of control. In the end, you are surrounded by people, not machines. Discussions can spark. If you feel nothing’s working during the Post It Moment, it’s ok to take a 15 minutes break.
#17 Retro is Recommended
When you finish a Sprint you feel like you are getting off a wild roller coaster, you are exhausted but so excited you want to take another ride right away and iterate over the idea. Most of the time iteration is necessary.
If you can do a retrospective of the Sprint the day after the tests, when everyone is well rested, you’ll certainly get interesting feedback. We usually finish Sprints with a brief doc that summarizes the whole process. We include the final Map, the Long Term Goal and the Sprint Questions, add photos of the team working and write down each and every idea that popped during the Sprint. We also put in there a link to the prototype(s) tested and the feedback from users. After reading this feedback, you can decide whether a new Design Sprint is needed or if you have enough steps to follow and build the product or add a feature.
#18 Return to The Book
Whenever we read a book, any book, we do it from our knowledge and worldview at that moment. Re-reading a book after a while may be revealing. We did that with Sprint several times and rediscovered the book, we found different ways to complete a certain exercise and got new pieces of advice we understood now that we had done some real life Sprints. Once you have lived through the context Jake Knapp describes, it’s really different. Sprint is a practical book, filled with tips on how to carry out this process, we promise rereading it after doing several Sprints is enriching.