A design sprint is an exercise that takes you from challenge to a user-tested prototype in just five days. The sprint is a rapid process for answering critical business questions through design, prototyping, and testing ideas with customers. Developed by a team at Google Ventures as a “greatest hits” of business strategy, innovation, behavior science, and design thinking, the Design Sprint refines many of the great tools and methodologies of User Experience and User-Centered Design and promises to compress months of work into a single week.
The Challenge
For the uninitiated, pulling a Design Sprint together a challenge in itself. You have to put together a functional team of designers, subject-matter experts, key stakeholders, and decision makers, and coordinate their schedules to fit into a single week. Add to that the logistics of securing a single location where you can set up shop for the week, and enough pre-planning to make the actual process run smoothly, and you’ve got a significant challenge ahead of you. The payoff is months of work condensed into a single, focused week. Once you work out the logistics, the process itself and what you come up with at the end are extremely valuable.
We managed to secure all the needed team members, stakeholders to commit to key decision-making parts of the exercise, and dedicated a couple different spaces we could use as workshops. We decided to make our tools and equipment move-able to account for location change mid-week. With a few days planning, we were able to get 8 designers and decision-makers dedicated to coming up with a solution to a long-standing institutional problem.
Institutional Challenge
In a large, multi-specialty organization consisting of thousands of individuals and hundreds of offices working independently, individuals routinely created solutions in silos and developed tools where features and function would often overlap.
Because of the sheer size of the organization, many researchers weren’t even aware of all the tools and resources that had been created to solve problems, much less how to access and use them.
Even though these tools were technically available to everyone, they often went under-used and, even worse, were replicated, creating a redundancy that reduced productivity and innovation.
We distilled the challenge into a single question:
“ How might we get staff the information and tools they need to be successful”
Process & Tools We Used
Because this was an institutional problem that had been festering for years we wanted to eliminate the past cycles of meeting, debating, proposing solutions, deliberating and ultimately back-burnering the process. We decided a Design Sprint was well suited to overcome a cycle that had proven to be ineffective.
The Sprint Process is broken down into 5 stages of analysis, ideation, and validation on each of the five days of the Sprint:
Day 1: Define your goals. On Monday, you map out your problem and pick an important place to focus.
Day 2: Think alone, together. On Tuesday, you sketch multiple solution possibilities to compete with one another.
Day 3: Choose your solution. On Wednesday, you make some decisions about which ideas are your most viable solutions.
Day 4: Rapid prototype. On Thursday, the team comes together to create a high-fidelity prototype you’ll be able to test with actual users.
Day 5: Test with users.
Friday, you test your prototype and observe how users interact with it.
The timeline is intense, and it’s almost hard to believe everything you need to do can be done in such a short amount of time. But, a well-planned Design Sprint actually runs quite smoothly. It also forces you to make decisions and move forward with a viable solution.
The Solution
The solution for our particular product came about after multiple solutions were put on the table on days one through three. We had a team of designers listening to input and feedback from stakeholders and users on Day 1. We proposed ideas based on ideation exercises like comparative analysis, sketching, journey mapping, and lighting demos on Day 2. We presented ideas to key stakeholders and had them vote and comment on best ideas. As a team, we settled on a solution by the end of Day 3, creating a storyboard of the 15 stages of the user journey as they were introduced to the challenge and interacted with our solution.
On Day 4, we began to build our prototype: an interactive web application that:
Introduced users to a tool repository
Helped them filter through thool options and select the option that best suited their needs
Introduced features like the an ability to talk with other users.
Value Added
The Design Sprint itself lends itself to solving problems with specific circumstances; namely:
You’re dealing with a complex problem where stakeholders have a difficult time pinpointing where to begin.
Time is a factor. You can’t linger for months on user testing, ideation, and deliberation of a solution. Or, you’ve already spent months doing just that, but are no closer to a solution.
You can’t afford to invest development resources. Your implementation resources, namely time and money, can’t be spent on something that may or may not resonate with users and solve your problem.
You need stakeholder buy-in. Key decision makers need to believe your solution will work before it gets the green light.
Additional benefits we found in this project is that we were able to understand what worked and what didn’t work with users. A lot of great ideas were put forward and not all resonated with users at testing. The Design Sprint reveals what doesn’t work as much as what does.
The final solution for this challenge wasn’t the only solution developed during the Design Sprint. Insights from users during this process sparked ideas for future projects and allowed stakeholders - who were participating throughout - to recognize that there was more than one challenge and more than a single solution needed.
We brought in actual stakeholders to observe user testing and even key decision makers to test the prototype. That hands on experience really allowed them to buy into specific aspects of the solution and feel more comfortable moving forward.
Ultimately, we were able to get closer to a solution in five days than the institute had come in several years of frustrating deliberations. What we learned from the user testing, and from the process itself, gave us insights into not just one solution, but the beginnings of ideas for future innovation.