How The Zebra Runs Remote Design Sprints
Overcoming the challenge of distance during the design process
Introduction
As the nation’s most comprehensive comparison website for car insurance quotes, The Zebra faces a lot of competition. So it’s critical that our product design and user experience set us apart from the crowd, even when we can’t be in the same office.
That’s why design sprints are a top priority for all the product stakeholders. We use sprints to design new features, fix existing problems, and improve weak spots in our experience. Unfortunately, with our team working remotely, the process can be tricky. We’ve made a series of tweaks in order to address these issues and improve our results.
Our design sprint team
We have slightly modified the standard roles in our design sprints. We will typically have some combination of the following:
- UX Lead (Facilitator & design expert)
- UX Researcher (Customer expert)
- Dev Lead (Tech expert)
- Product Manager (Logistics expert)
- VP of Product (Decider)
- CEO (optional)
- COO (optional)
Our modified process
Because our team is remote, we face certain challenges throughout the sprint regarding scheduling, communication, and decision-making. Therefore, we have made some adjustments to the traditional sprint model:
Individual meetings, not full days
There’s just no feasible way to get all the right people in the same place for 5 full days. We have broken up the days into 5 meetings, each 1.5 hours long. I’ve found that this is typically enough time to get the majority of the work done, then we use Slack and Miro to communicate, vote, and decide on things.
Virtual whiteboards
Without a physical room, we had to find a way to broadcast our whiteboard activity in real time and keep track of everything between meetings. Miro solved all of our problems. With a basic template, I can fire up a new design sprint in seconds. There’s even a feature that allows for quick voting (You can also use emojis or red circles to sticker vote). We split up our boards into “Design Sprint Board”, “Effort/Priority Matrix”, “Lightning Demos”, “Solution Sketches, “User Test Flows”, and “Storyboard”.
Slack channels
Instant communication is critical between sprint meetings, so we create a specific channel for each sprint. We use it to post any updates to the Miro board, share links for lightning demos, and discuss the problem in greater detail.
Adding research throughout the process
Research is the cornerstone of every design sprint. We start the first meeting with videos of users struggling with the problem and each subsequent meeting starts with research findings that we have discovered along the way. We’ve found this to be invaluable at every step of the way, including understanding the problem, designing solutions, and validating our ideas.
“How Might We…” notes from the start
We believe HMW notes are an important component of a successful design sprint and encourage all team members to write as many as they can. We introduce them immediately after the introductions so that nothing is missed as we discuss the problem.
Assumption mapping
During the first meeting, we insert an exercise after sprint questions to document all the assumptions we’re making. We basically split a whiteboard into 3 columns that read “We assume that…”, “Tested with…”, and “Validated if…”. We then fill the columns with sticky notes as we go, writing down all the assumptions and their corresponding tests and validation criteria.
Effort vs. Priority matrix
We found organizing HMW notes into groups was important, but thought we could take it a step further. We use a effort/priority matrix to help prioritize the ideas we come up with. The “big wins” fall into the top left quadrant (low effort and high priority). We use votes and a supervote to decide on the most important ideas.
Adding “User Test Flows” before we start Storyboarding
We consistently struggle with our fourth meeting, because it’s hard to remember where you left off and what you were thinking in the previous session. After stumbling across this video on “Storyboard Hacking”, we thought it made sense to give it a try. Basically, we have each member create a user flow with sticky notes, then we move things around and vote. We’ve found that it makes the actual storyboarding process much quicker and easier.
Voting on the predicted winner of A/B tests
Anytime we have multiple solutions that we want to test, we do a round of voting on the predicted winner. It’s an interesting insight into how we think as a group and a fun way to keep track of who’s the best at predicting winning designs. Make sure to keep the A/B spec close to the poll so that people can learn about the problem.
Our Design Sprint Kit
We’ve paired down the supplies for our design sprints to include ONLY what we need. To make it easy, I’ve created an Amazon wishlist so you can buy them all at once. The individual items are listed here:
- Sprint book
- Carrying case
- Notepads
- Dry erase markers
- Sharpies
- Masking tape
- Sticky notes
- ¾” stickers (red)
- ¼” stickers (blue)
- Timer
Conclusion
We’ve completed roughly 15 design sprints so far and have grown to rely on them for all of our big decisions. Our CEO, Keith Melnick, summed up our experience so far:
“Design sprints are crucial to The Zebra’s success, but having teams in different locations can be challenging. We’re still perfecting the process, but have been happy with the changes we’ve made so far.”
Solving design problems is one of the toughest challenges our company faces, but through constant learning and increased user understanding, we feel confident that sprints offer us the best chance for success. We will continue running design sprints for the foreseeable future and keep evolving the process to create amazing experiences for our users.
