April 18 was a special day here at Ruby® Receptionists HQ as we hosted our second annual Design Week Portland event! I’m Terri Haswell, Director of UX at Ruby. My team and I hosted an interactive session where we traded in stuffy presentations for a bit of hands-on learning. The audience got to experience how we use design sprints to keep the collaboration radical and customers at the center of all we do.
Our goal was to have audience members leave with enough insight and inspiration to feel like they could give design sprints a spin with their own products and customers.
What’s a Design Sprint you ask? Great question!
- It’s a framework
- By design, it promotes collaboration across teams & customers
- It helps answer critical business and user questions
- It’s fast
- It results in an actual prototype to test
The Design Sprint was invented by the folks at Google Ventures (GV). It’s a three to five-day collaborative design process for exploring and testing ideas with a human-centered approach. Each day of the sprint is intended to help you bring together a diverse group of people to examine the problem, brainstorm solutions, prototype, and test your ideas to see if they resonate with your customers.
Clearly Ruby didn’t invent design sprints. The value of Ruby holding this community event was to share how a real organization used and modified the design sprint process to help us focus on continuous collaboration, making things instead of just talking about them, and moving fast.
The five phases of a design sprint are:
Each phase gets a single day, which means by the end of five, fast days, a sprint team will have agreed on a problem, and built, tested, and gained invaluable insights from a working prototype. That’s a lot to communicate in just a one-hour session! We set out to take our guests through the “cooking show” version of a design sprint, with some pre-prepped artifacts, and lots of audience participation, we got the sprint week done in 1 hour… ish.
The event was a hit, and the audience even stayed late for a robust Q&A. Curious if a design sprint could help you better understand a business/customer problem you may have? Wonder if you could run a design sprint of your own? Let’s take a look at what a GV sprint entails (and what Ruby does a little differently):
Day 1: Understand and agree on the problem
The first day of the design sprint is when everyone slows down, digs deep, and picks a problem to solve. The sprint team starts by aligning on their long-term and short-term goals. After that, they move on to mapping the flow or journey for the person using the product. Experts and stakeholders come in to discuss known pain points, and the team takes notes using the “How Might We” method, looking for ways to reframe issues as potential opportunities.
Ruby Tip: Though a design sprint is intended to garner your team’s full attention for five consecutive days, we weren’t able to stick to that 100%. We found that days one and two truly required our undivided attention. For these days, we went outside of our usual office to keep us focused, and when our co-workers outside of the sprint needed our help, we had designated one person to negotiate if/when to pull individuals away.
Day 2: Come up with ideas
Day two is all about getting inspired and brainstorming broadly to solve problems. The day starts by looking for inspirational designs on the web or in the world. After that, they move onto the most fun part of the day: sketching! The two key sketching techniques are:
- Crazy 8s – This is when you fold a piece of paper into eight sections, and you make eight sketches as fast you can (spending no more than one minute per sketch!).
- Solution sketching – After everyone has shared their crazy 8s, the team votes to start to narrow the field of ideas. The most popular ideas then become the basis for a solution sketch, which is meant to be more in-depth and show more steps of a flow or journey.
Ruby Tip: When it comes time to solution sketching, we found that some folks work better when they have a little more time and can sketch in their own private space. We recommend going back to your desks to really noodle on ideas quietly and independently.
Day 3: Decide on an idea, and make a storyboard
This is when it starts to get real. After exploring lots of different solutions, the team decides which idea is the best to test. To do that, the team does a round of speed critique and takes a vote! Once there’s a clear winner, the team gets to work creating the storyboard, and writing the testing scenarios. This ensures that everyone is fully prepped and ready to start building the prototype.
Ruby Tip: We found that it was difficult to vote on concepts or sketches as a whole. Instead, we voted for individual parts and pieces. If we ended up voting for competing ideas, we might use our designated “decider” to choose which one to pursue, or we might choose to do a “rumble,” which means we show both in the same testing session to see which one resonates better.
Day 4: Make a realistic prototype to test the idea
The fourth day is action-packed! This is when your team starts building and pilot testing your prototype. To get it all done, you’ll need to break up with the work and swarm.
GV recommends dividing into at least four roles:
- Asset Collector – the person who gathers images and icons for the prototype
- Maker – the person who makes the visual screens or parts
- Stitcher – the person who makes the prototype clickable and makes sure there are no “dead end” flows
- Writer – the person who writes the content for the prototype and the testing questions that you’ll be asking
Once the prototype is done, the rest of the day is spent pilot testing and revising to ensure that testing day will be as smooth as silk.
Ruby Tip: The way you break up prototyping tasks can change depending on the tools you use. We recommend deciding on and working with your tools before the sprint starts. That way you have a good understanding of how it makes sense to break up the work.
Day 5: Test the idea and analyze the data
This is where the rubber meets the road, and the sprint team gets to find out what customers really think about their idea. On this day, the team tests the prototype with real users. Five testing sessions are conducted with one participant and one facilitator at a time. The rest of the sprint team observes the sessions from a separate room, where they watch reactions, capture insights and note down critical user feedback. After testing with just five people, patterns will start to emerge, and the team will see what parts went well, and what parts were confusing or uninteresting.
Ruby Tip: For most organizations, it can be tricky to conduct research with users face-to-face. For testing (remote or in-person!) we use a tool called Lookback.io. This tool allows participants to interact with your prototype remotely while you talk to each other. It shows their face, their screen, and their mouse movements. There’s even a mode for live observation, and all sessions are recorded for future reference.
And that’s it!
Once the sprint is done, you’ll know what was successful and what needs more thought, or as GV frames it, efficient failures and flawed successes! Your testing sessions with customers may even convince you to pivot and go in a completely different direction. But either way, you will have learned a lot about your product idea, and about the people using it in just a few days, instead of waiting to build it, only to find it’s not the right solution and may not even be the right problem.
I’ll leave you with this quote from Tim Brown, a legend in design thinking.
“The faster we make our ideas tangible, the sooner we will be able to evaluate them, refine them, and zero in on the best solution.” —Tim Brown, CEO of IDEO
Ready to make design sprints part of your process? Try not to feel like you have to do everything and do everything just right the first time. Do what you can and have some fun with the chaotic challenge of making your idea come to life in one week. Check out these Google Ventures resources. They’re loaded with tons of great information!