Design Sprint 2.0… but make it Remote
Back in June of 2021, my Product Owner approached me with the concept of a Design Sprint. She had been looking into it and brought it up to me as something we could do at Niche to help inform next steps on our quest to raise user engagement. She floated the idea of having me facilitate it. My role on product teams at Niche is as a ScrumMaster, and while that requires facilitating, at that point I had never heard of a Design Sprint as more than just a buzzword in passing. However, it only took some light research before I knew this was something I was interested in pursuing.
The next few weeks I spent hours reading articles, watching AJ& Smart videos, reviewing templates on SessionLab, and reading Jack Knapp’s book, Sprint. I took those resources and then combined them with the tools we had available at Niche to make it work remotely. As a result, we conducted our first Design Sprint 2.0 virtually at Niche in July of 2021, and it resulted in a lot of enthusiasm and success! I had a lot of fun learning and executing, and the following is what I learned along the way.
What is a Design Sprint?
A Design Sprint is a process that allows teams to ideate, prototype, and validate concepts in less than a week.
Objectives of a Design Sprint may include:
- Overcoming analysis paralysis or a stalemate as to what to do next
- Supporting cross functional collaboration in an intentional and focused environment
- Minimizing chances of bias and attachment toward any particular solution
- Gathering data from actual users with a realistic prototype
When you think about the amount of time ideas go through a general discovery process; the back and forth with weeks and maybe even months in between, the growing attachment to ideas the longer they’re around, the unconscious bias that could be associated with who pitches the idea, you may agree that a Design Sprint is truly a low risk, high reward alternative to traditional product design decision making.
The original Design Sprint concept was first tested in 2012, and while the goal of a Design Sprint has not changed, the way it has been conducted was updated in 2018 to include a 2.0 version. The main differences being that 2.0 is 4 days instead of 5, and only requires the full team for the first 2 days. At Niche, we decided to conduct 2.0. When “Design Sprint” is referenced here, please know it is referring to the 2.0 version.
So Who All is Involved?
Design Sprints are particularly useful when the problem is meaningful and challenging enough that employees from different groups need to work together to find a solution. The ideal number of people involved in a Design Sprint is around 7, although we conducted ours with 10 due to a larger number of interested stakeholders. We found there to be 3 key roles that must be filled before starting:
- Facilitator: the person charged with guiding the sprint and making sure the team stays on track. The Facilitator will not participate in voting and should be unbiased.
- Decider: the person charged with carrying the most influence and making the final calls throughout the sprint. Oftentimes (and in our case) they are the ones who decide we should conduct a Design Sprint.
- Designer(s): Design Sprints require lots of visualizing of ideas. It’s imperative to include at least a designer, ideally the one that may be working on the project post-outcome.
The remainder of the team is composed of someone from engineering, representatives from core business departments (such as Marketing, Brand, Operations, etc.) and any other stakeholder(s). Experts in areas (such as product analytics) can be invited to share problems they encounter or to provide additional context. Together, this group will ideate, prototype, and test a solution in just a few days. Together being the key word…
This was a particularly large challenge for me. In this post 2020 world, how could we replicate a process that otherwise required everyone to be together in a conference room, huddled around whiteboards for days on end? How would we do this online?
Design Sprint 2.0 or Design Sprint 2021?
First, I made sure we had the right tools and infrastructure in place to be able to support 4 full days on camera, without creating video fatigue or compromising the collaborative nature that Design Sprints are known for. At Niche, we are fortunate to have the following tools available that helped us replicate traditionally in person brainstorming sessions for a remote landscape.
- Google Meet: We used Google Meet as our conference room.
- Mural: We used Mural as our whiteboard, our post-its, stickers, and markers. This was the main tool used for collaboration during the Design Sprint. There are many features within Mural that make it an excellent tool for Design Sprints (Vote, Timer, Private Mode, to name a few).
- Google Forms: We used Google Forms to submit physical sketches (discussed later) and to collect feedback at the end of the sprint.
- Figma: We used Figma for building and sharing prototypes.
- UserTesting: We used UserTesting.com for usability testing.
- Slack: We created a new Slack channel for the Design Sprint and used it as the hub of our async communication, and of course for celebrating wins.
- Spotify: Don’t discount what music can do! We used Spotify to play music through a browser during voting sessions, research, or breaks to help apply the concept of “Working separately, together”. Also, it removes a lot of awkward silence.
Of course, tooling only solves part of the problem. It is up to the Facilitator to make sure that the participants feel engaged. Have participants leave their camera on even during sketching or research sessions, make sure to build in breaks, play music, etc. Make sure everyone has a voice, but also keep the conversations focused.
Once the team has been assembled and the tools are in place, we can get started.
Agenda
Day 1 — Define & Sketch
The goal of the first day is to define the challenge and begin breaking down the solution. It starts with the Decider introducing the problem space and interviewing any subject matter experts they may have invited. This kicks off the rest of the morning–the team creating How Might We statements around the problem, understanding your long term goals, and making sure that the biggest obstacles have been identified. Voting happens at every level, and at the end of the morning, you are left with your North Star–your sprint goal and questions to refer back to at any point in the following week.
Imagine you own a bookstore, the following could be the outcome of these morning sessions:
- Problem Space: Less people are buying books at your bookstore.
- How Might We: How might we compete with online retailers? How might we host more events? How might we raise our social media presence?
- Long Term Goal: Create a brand where customers will think about the store as an experience and want to come back with friends and family.
- Sprint Questions: Can we raise enough loyalty within our customer base for them to forego the convenience of free 2-day shipping and a discounted price?
Break for lunch, and in the afternoon, the team will return to create a user map with the main touchpoints where customers discover and use your product or service. After the user map is created, the team identifies the area of the customer journey that should be focused on for the sprint. Once the scope of the problem has been identified, the Lightning Demo can properly take place.
At Niche, we recreated the Lightning Demo remotely using Mural. We assigned sections for each team member and turned on Private Mode to mimic working off only their screen. We played music through the browser to mimic being in the same room. For about 30 minutes, everyone researched and filled their sections with features and products that inspired them (in relation to our problem space). At the end of the 30 minutes, I turned off Private Mode and each individual demoed their sections to the team. This demo becomes very useful in the day’s final activity.
The 4-Step Sketch — pen and paper required. This activity is broken into four different parts, with everyone working separately at the same time.
- Notes: each person “goes around the room” by dragging their cursor and writes down things that stuck out to them from any of the day’s previous activities.
- Ideas: they turn these notes into ideas and begin loosely sketching them out on paper.
- Crazy 8s: taking their favorite idea, they sketch that idea 8 different ways and select a favorite variation.
- Solution Sketch: the solution sketch is the detailed version of the favorite variation. This sketch should have a catchy title, tell a story in frames, and be self-explanatory (don’t be afraid to include notes or explainers!), as it will be artist anonymous as well.
At Niche, we played music and set a timer for each stage of the sketch. Once someone finished their solution sketch, they took a photo of it and submitted it into a Google Form. Once everyone finishes, the first day of the Design Sprint concludes.
Day 2 — Decide & Storyboard
The second day is all about deciding on a solution to move forward with and outlining the specific frames that will be necessary for the user testing prototype. The morning sessions revolve around the sketches submitted the previous afternoon. As the Facilitator, you want to make sure these are “hung up in the conference room” prior to the day beginning. To recreate this remotely, I made similar sections used during the Lightning Demo, but randomized the order. Each section included just the title of the sketch, the sketch itself, and some red stickers for the heat map later on.
The morning commences with me, the Facilitator, explaining the sketch as I understand it to keep anonymity of the artist (which is why the more detail in the sketch, the better). Questions that arise on a sketch are recorded on post-its. Individuals reward parts of a sketch that stick out to them with a (or multiple!) red sticker. The morning concludes with each individual denoting their favorite sketch using a green sticker and pitching to the Decider why. At the end, the Decider chooses the sketch to move forward with (or in our case, the 2).
What I found nice about conducting this particular activity remotely was that it allowed multiple people to look at the same sketch at once, without the crowding that would otherwise happen in person. It also allowed everyone to zoom in and out, and easily compare multiple sketches at once.
After lunch, the team reconvenes to create the User Test Flow and the Storyboard. The user test flow walks through the specific set of actions that happen one after the other (clicks, taps, movements, etc.) to get to the next frame. It is often helpful to start with the first frame and the last frame, and fill in the spaces in between. The storyboard is the complementing images and sketches that will be used for prototyping. When laid on top of each other, it should be able to tell a story. Once the storyboard is complete, Day 2 is wrapped.
Day 3 — Prototyping
On the third day the team builds a realistic prototype of the storyboard. A realistic-looking prototype ensures the most accurate data from tomorrow’s test. However, it is important to focus on the parts of the prototype being tested and not get too lost in the small details. Prototyping requires its own team–members of the team volunteer to put on hats to fill a necessary role.
Prototype Team
- Makers: responsible for building the actual mockups
- Stitcher: responsible for making sure that everything is cohesive and the flow is natural
- Writer: responsible for copy on the mockups
- Asset Collector: responsible for collecting images/content
- Interviewer: responsible for creating questions and conducting the interviews
We found the third day worked well asynchronously. We met in the morning and scheduled check-ins throughout the day. Otherwise, the prototype team worked diligently and communicated largely in video calls with each other, or posting in our slack channel if something was needed. In the afternoon, we met to go over the progress on the prototypes and provide feedback on any necessary changes. At the end of the day, the whole team convened to go through a trial run. The trial run is also a great time to revisit the sprint questions. It’s one last check with the whole team to make sure the prototype will help us get our answers. After any last minute tweaks are made, Day 3 comes to a close.
Day 4 — Test!
The fourth and final day is all about testing the prototype and synthesizing the results. When I did research, I saw that many teams watched these in person interviews live from a different room. Since we were not conducting in person interviews, we altered this day as follows.
Our interviewer chose to do a mix of live interviews on Google Meets, and administered tests on UserTesting.com. The Interviewer reviewed their appointments for the day with the team, and following check-ins were set around the Interviewer’s schedule.
At the end of the day, we set two hours aside to review notes from live interviews, watch recorded UserTesting videos, and discuss. We asked ourselves how these findings rolled up to our Long Term Goal and if and how they answered our sprint questions.
We scheduled a more formal Conclusions and Wrap-Up the following week, so that our Decider (and in our case, also our Interviewer) would have enough time to properly synthesize the data. During this meeting, she would walk us through the key results, and our next steps.
In conclusion…
I found that a Design Sprint worked especially well for the problem we were trying to solve at Niche. We were ambitious and ended up creating two prototypes and conducted two variations of the same test. Our team noticed patterns in the interviews–what users latched on to, what they thought was too busy versus just eye-catching enough, the surprise delight they found in a part of the prototype that was initially just filler, etc. In the end, we decided to take aspects of one prototype and add that as a feature to the other. This one week experiment allowed us to focus our efforts on a specific problem, collaborate with each other, create realistic prototypes, and gain real user data. It also greatly influenced our team’s goals for the following quarter.
We conducted the Design Sprint at Niche to help inform us on how to solve a high level challenge, but I also see the activities and strategies benefitting our work at a smaller scale–such as for general brainstorming or feature development. In this new remote landscape, if you are looking to solve problems in an engaging and interactive way, save time, remove biases and distractions… Consider running a Design Sprint at your company.
