Design sprints for cross-functional collaboration
As the sophistication of digital products increases, the partitions between product development roles have begun to crumble. To create products that meet user needs more effectively, user experience designers, product managers, and engineers need to find common ground in a shared vocabulary and an inclusive process.
Cracking the code took a few years of trial and error, but eventually here at Google we developed a process that enabled designers and developers to conceive, build, and test prototypes efficiently. The design sprint process became a go-to method for product teams across Google and Alphabet, and is a core tool for enabling Google’s innovations.
The design sprint emphasizes elasticity and malleability to meet the needs of various audiences such as internal product teams, third-party partners, startups, international aid organizations, and creative hackathons. The ability to adjust the process to answer a multiplicity of questions is what sets Google’s design sprint methodology apart.
The Google design sprint was developed to improve the way teams work, generate more innovative and viable ideas, and test those ideas with users quickly.
What is a design sprint?
A design sprint is a five-phase framework to solve a critical organizational challenge, rooted in design thinking and interaction design processes, that uses rapid prototyping and testing with users. How is a design sprint different from an agile sprint? First is the duration of the activity, a design sprint is never more than five days long. Second is its structure, whereas an agile sprint is unstructured, once tailored to the its goals and deliverables a design sprint is scheduled down to the minute, ensuring the most effective use of time.
When is a good time to sprint?
The design sprint framework can be applied to many of the challenges an organization may be facing. It’s a great tool for kicking off a new product, bringing the team together to create a shared vision, and testing initial concepts with users. Another great use of the design sprint is when you have a mature product that is encountering some hiccups. A sprint can help leverage data to improve your product, or it can help your team to move faster, particularly if you’re stalled or having cyclical conversations.
When is NOT a good time to sprint?
Successful sprints have prerequisites. You don’t need a sprint if you already have a clear product direction and simply want to build it quickly. Sprints also work best with a good quantity of user research data. So, if you’re light on user data, you may want to hold off a sprint until you’ve collected more. Finally, if you don’t have leadership support for the outcomes, it’s probably not the best time to sprint.
Crafting a sprint challenge
Every sprint should have a clear goal and well-articulated challenge. This helps to focus the team and make the best use of its time. A good challenge should be succinct and inspirational. It should include the key user, relevant platforms, and a clear time frame. Here are a few examples:
Improve the mobile onboarding experience for new users, to help increase the number of sign-ups to be implemented in the next two quarters.
Define a vision for how your product will better meet users’ needs two years from now.
Generate a broad range of ideas to increase engagement for high volume users on mobile and desktop next quarter.
The five phases that make up a design sprint are: understand, sketch, decide, prototype, and validate.
- During the understand phase the team builds shared knowledge, a shared vocabulary, and explores the problem from all angles. Together the team will map out user journeys for the experience, and then establish clear goals and success metrics.
- The sketch phase is the individual ideation portion of the sprint, when each team member sketches out eight ideas for how to address the challenge and then narrows these down to one well-articulated idea.
- In the decide phase the team comes together and reviews the solution sketches, comparing them against the goals. The team might also discuss in detail the sprint questions that they would like answered.
- Prototyping happens in a day or less and is where the ideas take shape and are threaded together to create a coherent experiment.
- Finally, the validation phase is when the real learning happens, with the entire team observing while users test out their ideas.
Design sprints in action
We’ve worked with many companies and organizations to run design sprints; these three examples — each from very different industries, facing their own unique challenges — offer some practical insight into the power of the process.
Memrise: voice user interface
Memrise is an app to help people learn languages and have fun while doing so. The team at Memrise wanted to explore what a voice user interface (VUI) experience could be for their learning flow. Google partnered with Memrise to design a sprint focused on creating a user experience for a heads up, hands free learning mode that enables people to learn a language without requiring their direct visual attention and interaction through touch and the screen. All with the goal of launching in six months.
The team consisted of fourteen people from different disciplines, including product managers, user experience designers, user experience researchers, language specialists, and engineers. The number of participants allowed them to break into two groups and do more prototyping. The team came together for three days. The first day was dedicated to learning more about the principles of VUI from Marc Paulina, a conversational user interface designer on the Google Search team. Through lightning talks, they explored the problem from several angles, including the business case, the user perspective, the competitive landscape, and even the technological opportunities. Each group mapped out the journey for how a “hands free/eyes free” experience might fit into their users’ daily lives, highlighted pain points with the language learning process and described the opportunities for increasing the time users could dedicate to learning.
By the end of day one, the groups had fourteen clearly outlined ideas. From these, they selected two approaches and prototyped them into two different experiences. They tested the prototypes with six users on day three and learned that users were quite comfortable talking to their phones and adding a voice learning experience felt natural to them. Memrise also found that a simple overlay of a conversational experience on top of their existing chat format would work well as an minimum viable product for the new experience.
Afriscout: new product sprint
Climate change has affected rainfall patterns in East Africa, forcing pastoral tribes to alter their herding routes. Traditional methods of finding good grazing land such as word of mouth, scouting, and ancestral knowledge are no longer sufficient to maintain healthy herds. Project Concern International (PCI), a nonprofit based in San Diego, in conjunction with USAID, tackled this issue head-on.
They set up a program in Afar, Ethiopia that relayed satellite photos to pastoralists showing current vegetation conditions, giving them critical intelligence on where good grazing land might be. The program was a tremendous success, with a 50% reduction in livestock mortality rates and 80% adoption by locals. However, the delivery system was cumbersome and inefficient. The question was, is it possible to cut out the middlemen and simply deliver maps from satellite to smartphones and, if so, could the new process be as effective as the old?
In collaboration with Google.org and a Google design sprint master, PCI held a design sprint to develop an app that downloaded the satellite photography to smartphones, transforming an outmoded print and paper delivery system. Representatives of the local tribes participated in the sprint, lending their expertise about language and herding needs. This ability of the sprint to accommodate multiple types of expertise and find functional solutions through group effort is one of the many reasons it is such a powerful tool.
Dimensions: moonshot sprint
The Design Relations team at Google invited 35 top app designers and developers to San Francisco to participate in a three day sprint exploring the potential of the Android platform. Participants self-selected into broad market categories including Self-Activating, Environmentally Sustaining, Entertaining, Connected Living, and Productive. In just three days, the teams developed cutting edge prototypes with real world applications. These included an artificial intelligence bot that helps users calculate the environmental impact of everyday decisions such as which pasta brand to buy, a recommendation engine for nightlife geared towards the user’s tastes, and an anonymous social media app where survivors of sexual trauma can help one another navigate the healing process.
Resources for design sprints
To get teams started on running design sprints, we created a design sprint kit which outlines the basic methods used at Google. It includes templates to help with the planning process. The SPRINT book by Google Ventures is another great way to get step-by-step instructions on how to run sprints in startups and smaller companies, and has some fantastic examples you can learn from. We hope that you’ll try the process in your team and let us know how it goes!
What do you think?
Do you have questions or thoughts on how to run successful design sprints? Continue the discussion in the comments below or tweet using the hashtag #AskPlayDev and we’ll reply from @GooglePlayDev, where we regularly share news and tips on how to be successful on Google Play.