Below is an article originally published by Samanta Shi at PowerToFly Partner Intent. Go to Intent's page on PowerToFly to see their open positions and learn more.
You have probably heard about the Design Sprint methodology by now. Perhaps you have even read the book (twice), but just in case you haven't: The Design Sprint, developed by Jake Knapp, is a five-day process that helps companies (startups and enterprises alike) tackle big problems and answer critical business questions through various design, prototyping, and testing activities. You may want to run a design sprint because you're tackling a new, challenging problem, craving product innovation, or perhaps you're just plain stuck.
A few months ago, I facilitated a Design Sprint at Intent Media. Since we have a handful of remote folks, we ended up with 2 remote participants. We followed the book closely, with a few adjustments here and there. I've read several blog posts about how others lead sprints, what tools they used, tips they have. Today, I've decided to share some learnings that I took away as facilitator.
Here are 12 lessons learned:
1. Send out your calendar invites early, and by early, I mean at least 6–8 weeks in advance.
People are busy and have crazy schedules, especially folks on the commercial side who have a lot of meetings with partners and senior management. You will also want to make sure that you are not disrupting the engineering team, and it helps to check in with the team lead or director before you recruit 1–2 engineers. This way, you can figure out attendance early and move the sprint around by a week or two without being too disruptive.
2. Get participants to fully commit to the sprint and make sure that they understand what a sprint is and why you're doing it.
This might seem like an obvious one, but new concepts and methodologies are unfamiliar, and therefore, have a boundary to entry (some may be hesitant to new things, some may have a habit to defaulting to prior processes). Also keep in mind that when people are thrown into a room with coworkers who they may have never worked with before, they might be intimidated or feel out of place. So, make sure that people feel prepared beforehand. Send out pre-reads, such as snippets from the book or easy-to-read blog posts with examples of sprints at other companies. Other useful pre-reads include summaries of user research, if applicable, or relevant product learnings from usability tests.
People will feel more inclined to clear their calendars and take participation seriously, if they understand the sprint, the rationale and impetus, as well as the importance of their participation.
3. Prepare research and send pre-reads ahead of time
You will have a much more productive sprint if your team has access to user and/or customer feedback regarding the problem at hand. The pre-reads don't have to be super long. In fact, it's probably better if you send out shorter, more digestible summaries. (Hopefully, as a UX researcher, you're already sharing user insights with the rest of the company on a regular basis.) However, this is a great opportunity to get your coworkers to really empathize with your users, and therefore feel better prepared to tackle the sprint problem. More knowledge = more ideas and creativity!
4. Find someone to help facilitate, especially if you have remote participants
There are several great blog posts out there that will help you prepare for a remote design sprint. (Check out Running a Design Sprint Remotely Across the Planet) I ended up recruiting a co-facilitator, Lana, who helped maintain our RealtimeBoard, which our remote participants used to view and add information on our boards, such as sticky notes and drawings. Lana also made sure to transcribe their input from the RealtimeBoard into physical copies so that everyone in the room saw the remote contribution (since laptops were not allowed for the in-person participants). Lana also helped with moving the webcams around, taking photos, and documentation. Safe to say that this sprint wouldn't have been possible without Lana's help!
5. Be strict about the rules
Be upfront about the rules in the beginning of the sprint and make sure people follow them. If someone needs to take a phone call, they should go outside. Make sure no one uses their laptop, unless during the research phase. Be strict about the rules so that participants are present and paying attention and so that the group stays focused for the duration of the sprint.
Introduce additional rules that you think might be helpful for your group. For example, we used the "parking lot", which is a literal box on the board where we'd write down ideas that were interesting but not relevant to the sprint or current sprint activity. If the group went off topic and we didn't have any time to spare, I would interrupt the discussion and take note of the topic in the parking lot. This made people feel OK with being interrupted, as they had some assurance we would get around to the topic at a later date.
6. Make sure the topic of the sprint supports the goals of the product team
Again, this might seem obvious, but if the sprint topic doesn't relate to an immediate goal (even though it might still be interesting, or something your team wants to tackle in the future), then it's safe to say that whatever action items you have following the sprint will be de-prioritized for the quarter (or two). One of the worst things that can happen is that you facilitate a 5-day sprint with really important people in the room and then none of the learnings or outcomes materialize. And, you definitely don't want people at the company to think that sprints are a waste of time.
7. Make sure someone follows through on the action items
After 5 days of ideation, creating, and testing, you will surely have some action items to follow up on in the next few weeks. Make sure someone explicitly owns these and that you assign these before the sprint is over! Otherwise, these tasks will likely remain unassigned, in the icebox, untouched, and incomplete. Even just 1 hour per week can make a difference here.
8. Make sure the topic of the sprint is focused but not too narrow
If you are not sure what to sprint on, then you are probably not ready to facilitate a sprint. However, if you find yourself prescribing the outcome with specific solutions, then you probably don't need a sprint — or you need to change your mindset. There will be little to no value in having a sprint if you don't know what to focus on.
I like to remind myself of the examples in the Sprint book itself. Let's look at Flatiron Health. They needed to figure out how to get more patients enrolled in clinical trials. Some of their sprint questions included: "Can we find matches fast enough?" and "Will clinics change their workflow?" (page 63). Slack, another example, was dealing with rapid growth. They needed to better explain their product to different kinds of businesses (page 129). Slack's story can be told in so many different ways, and surely the members of their sprint team each had an ideal way of telling that story, but the sprint helped them gather input from various people while coming to a decision quickly.
The sprint works for various kinds of challenges, but you now have to make sure you understand your challenge and provide enough of a focus so that your sprint has a sense of direction. "Solving healthcare" or "reinventing travel" are not appropriate topics, "How to get more patients enrolled in trials" and "How to streamline the search of leisure travel activities" are.
9. Be aware of the energy in the room
This is really, really important. If the energy is low, take a break! Even if you are so, so close to coming to a conclusion. Sometimes a short 5–10 minute break helps more than trying to tackle the problem to the ground with low-energy forces. You don't want to exhaust people. Keep your participants engaged and find ways to ease the sprint journey: take breaks, provide healthy snacks, crack a window if the room gets stuffy, always ask how the participants are doing.
10. Streaming the user sessions is fun!
Getting your set up sorted for streaming the user sessions might seem like a daunting task, but we found a relatively easy way to do it.
- Download OBS
- Create a YouTube account
Create your scene in OBS:
- Add screen capture
- Add web camera capture
- Add audio capture
- Add optional eye tracker capture
For more information on how to get an affordable eye tracker set up, check out my colleague's post Hacking Together Eye Tracking for your Usability Lab for less than 150.
- Connect OBS to your YouTube account. Make sure your YouTube channel content is private!
To livestream from OBS to YouTube, follow these steps:
- Go to your YouTube Creator Studio, navigate to Live Streaming, and then Stream Now
- Under Basic Info scroll down to Privacy and select private
- Scroll down to Encoder Setup and copy/paste your Stream name/key into OBS
- In OBS, open settings and go to the Stream tab
- Paste the Stream name/key into the Stream key field
- Change the Service to YouTube / YouTube Gaming; hit OK
Now, when you Start Streaming inside OBS, you should be able to see that your Youtube live stream is online with your scene from OBS (there is a little bit of a delay)
- Open the private livestream link in the room where your sprint team will observe
- Start testing and streaming! (Given that you have user permission!)
Make sure your sprint team is in the observation room for all (or most) of the user sessions so that they can observe how your users are interacting with your product and write down learnings and any ideas. They will surely find it both entertaining and rewarding.
11. Schedule a sprint retrospective
Find sometime on everyone's calendar to schedule a meeting where you talk about how the sprint went: what went well, what didn't go so well? Talk about thoughts and feelings and use this time to figure out what you might do differently next time. Also use this time to iron out any action items and assign ownership of the respective tasks.
12. Now that you've established a sprint muscle: flex it
Start planning your next sprint, even if it might be one or two quarters away. Keep your eye out for opportunities to practice the methodology where you see fit. Remember, don't just sprint for the sake of sprinting. Pinpoint moments, topics, where you think a sprint will help, start planning early, and find supporters.
You might want to consider a set cadence for scheduling sprints, so that they become part of your company's routine. For example, schedule a sprint during the 4th week of each quarter and use that time towards company level OKRs (Objectives and Key Results; learn more about OKRs here). You might not need a sprint every quarter, but at least you know you have the opportunity to sprint and that you will only use it if it makes sense from a business perspective.
That's it for my 12 lessons! I hope you can learn from my past experience and apply it to your future as a sprint facilitator or participant. Thank you for reading!
