Article 4 of this series gave a strategic overview of how we are scaling the Design Sprint framework across our organization to drive design transformation, empower teams and foster a culture of innovation. To further supplement this strategy, we created a public version of our training manual. Hope you enjoy!
What is a Design Sprint?
A design sprint is a flexible 5-phase framework that has been refined by Google Ventures. Their methodology is a mix of Agile and Design Thinking. Specifically, Design Sprints answer critical business questions up-front to reduce risk. The process includes problem framing, solutioning, prototyping, and testing.
When to run a design sprint?
Design Sprints are used to solve big problems where a solution is not apparent. Additionally, they are imperative for creating alignment among interdisciplinary teams and testing assumptions early in the process. This allows teams to fail-fast and pivot early when needed. The process is used for testing experiments and NOT for creating a production-ready design.
When NOT to run a design sprint?
Design Sprints are not ideal for well-defined products where ideation is not needed. Conversely, products with a broad scope are not good candidates as constraints must be enforced. Lastly, if more research is required to validate the market fit, a Design Sprint is not the right tool.
Design Sprints start with a defined problem-statement ahead of the sprint. This process is crucial for setting the Design Sprint up for success. The priority is to determine a fit between why this is important to both the business and the end user. There is no one-size fits all recipe for problem-framing. Currently, we are testing the Value Proposition Canvas as a tool for problem statement generation. More on this to come.
The Design Sprint team consists of 5–7 interdisciplinary team members. These are people who will touch the project after the sprint. It is best to have one representative from each main function of the team. This gives a well-rounded view of the problem-space. Also, we include a user researcher in each sprint.
Additional stakeholders are brought in to provide a strategic view of company initiatives. This helps to align the project with overall company vision. Stakeholders can be anyone the team deems to be relevant to the problem space, but not needed for the duration of the sprint.
We will test our prototype(s) with real customers at the end of the sprint. This provides immediate feedback and allows to validate/invalidate assumptions and prioritize next steps quickly.
We start every sprint with research and problem-framing. This is used to validate the problem-space and determine if a Design Sprint is the right tool for the project.
The team reviews existing knowledge to define the sprint focus and create assumptions for testing.
We focus on brainstorming activities that leverage the “group brain” while simultaneously allowing individuals to work through solutions on their own.
The team decides on which solution(s) will be tested with customers.
The team creates a realistic facade for testing. The key is to have enough fidelity to communicate the solution without getting hung up on the details.
The design is testing with five customers. The goal is to validate/invalidate the assumptions identified in the Investigate phase. This allows the team to define the project’s next steps.
Remote Design Sprint Best Practices
Due to the remote nature of our work, several of our teams have conducted remote Design Sprints. The key to the success of these projects is to streamline workflow and condense agendas. We don’t recommend using anything over a 3-day agenda for remote sprints.
Online remote Design Sprint tools we use are:
1. Instant communication via Slack
2. Airtable for project planning
3. Video conferencing tools such as Hangouts or Appear.in
4. Cloud storage/collaboration platform
5. Mural is used to capture the creative process during the sprint
Approval Process for Squad-level Design Sprints
Squad-level Design Sprints operate within one E2E autonomous, single-mission squad or across multiple squads. These projects have an immediate impact with the quickest customer-facing solutions, and we are currently running 1–2 per month.
First steps are to identify who is responsible for this project, and who has decision making power. Once key stakeholders have been identified. The team has an Intake Meeting to determine the following:
1. Goals and deliverables — Why is the project essential and what is the goal the team is looking to accomplish within the sprint? The team discusses what the current state and history of the project. A User Research team member must be involved in this meeting to validate the research and help scope the correct design sprint tier.
2. Logistics — We determine the target sprint date.
3. Team makeup — We use this time to determine our team.
Facilitator — The facilitator is responsible for taking the team through the exercises while maintaining both neutrality and an unbiased position.
Shadow — The shadow is responsible for documenting sprint activities and shadowing the facilitator through the duration of the sprint.
Core team — The Design Sprint team consists of 5–7 interdisciplinary team members. These are people who will touch the project after the sprint. It is best to have one representative from each main function in the Design Sprint. This gives a well-rounded view of the problem-space. We also include a user researcher in each sprint.
Decider — This is the CEO of the sprint and should have the most knowledge of the project. This is usually the product owner but doesn’t have to be. This person has final say in the two voting sessions.
Stakeholders — Four 30-minute stakeholder interviews that provide a strategic view of company initiatives. Stakeholders can also be anyone the team deems to be relevant to the problem space, but not needed for the duration of the sprint.
These workshops are ideal for projects with little to no user research inputs. Specifically, the team is looking to test an idea or hypothesis. This agenda goes through the first three Design Sprint phases, Investigate, Ideate and Focus. Post-sprint, the team, makes a value assessment + LOE decision on next steps (3-Day Design Sprint or done). Additional sprint outputs are roadmap prioritization, user research prioritization (to help further scope the problem-space) and a strategy deck.
3-Day Design Sprint
This agenda goes through each of the five phases in a condensed timeline and is the sweet spot for our culture. The user research inputs for this sprint are three or more of the following: User Testing Protocol, Survey Data, Customer Insights, and Data Analytics. At the end of the sprint, the team delivers low-fidelity prototype(s)/wires, value assessment + LOE, roadmap prioritization and debrief deck.
Value Proposition Canvas
We should not start a sprint without defining the desired outcome. That desired outcome is ideally coming from the user’s jobs to be done (JTBD), which fills in the customer segment section of the value proposition canvas. Lacking that, the desired outcome may also start as a problem statement agreed upon by the whole team.
5-Day Design Sprint
This agenda is the main one derived from Google Ventures and is used for larger-scale projects. The user research inputs for this sprint are jobs to be done JTBD and/or Value Proposition Canvas. At the end of the sprint, the team delivers high-fidelity prototype(s)/wires, value assessment + LOE, roadmap prioritization and debrief deck.
We start every sprint with research and problem-framing. This is used to validate the problem-space and determine if a Design Sprint is the right tool for the project. Allow two weeks for logistics and pre-sprint activities. It’s important to stay in the same sprint room as much as possible.
1. Self-stick Easel Paper Pad
2. Black 12-count Dry-erase Markers
3. Green 12-count Dry-erase Markers
4. Post-it notes, yellow 100 count, Pack of 12
5. 12 Sharpies
6. Plain printer paper, letter size pack of 100
7. Masking Tape
8. 1/2 round dot stickers — color s
9. 3/4 round dot stickers — color 2
10. Healthy Snacks — this is VERY important, and the bar is continually rising
During the Sprint
Phase 1 Investigate — The team reviews existing knowledge, defines the sprint focus and creates assumptions for testing. The goal is to gain alignment on the problem-space and sprint challenge.
Phase 2 Ideate — Explore solutions using the work-alone but together approach. We focus on brainstorming activities that leverage the “group brain” while simultaneously allowing individuals to work through solutions on their own.
Phase 3 Focus — We define the sprint focus. The team decides on which solution(s) will be tested with customers.
Phase 4 Prototype — The team creates a realistic facade for testing. The key is to have enough fidelity to communicate the solution without getting hung up on the details.
Phase 5 Validate — The design is tested with five customers. The goal is to validate/invalidate the assumptions identified in the Investigate phase. This allows the team to define the project’s next steps.
Determine next steps based on testing outcomes. Possible scenarios are to conduct a follow-up mini-sprint to refine the design. The team also builds a backlog of priorities that are used for sprint planning and roadmap prioritization. If there is not a squad attached to the project, meet with Design Sprint leadership to discuss activating a squad.
Design Sprint Facilitators
We lean on a core team of facilitators to help pilot our program. These individuals are identified based on facilitation & leadership skills.
Our Design Sprint Facilitators work within a modern matrix (Squad, Community, Chapters, and Guilds) structure to activate Design Thinking & Design Sprints within one E2E autonomous, single-mission Squad or across multiple Squads. Specifically, our team uses Design Sprints as an innovation catalyst to strategically balance the constraints of desirability, viability, and feasibility. Our facilitators investigate complex problems and explore solutions. Additionally, they drive iterations of our Design Sprint framework and facilitate additional problem-solving sessions.
We have a tiered onboarding plan based on classroom teaching, sprint participation, and soft skills assessment. Additionally, we understand facilitating is not for everyone, and that’s ok. Our goal is to help team members learn and provide the right framework and tools for success as we continue to build our team of design sprint facilitators.
• You oversee and facilitate the entire Design Sprint process — from pre-work, sprint, and debrief/aftercare
• You perform intake meetings with new teams to uncover the first problem statements as they align to project goals and meet the criteria of a design sprint project
• You find new ways to improve our current framework
• You improve, craft, and facilitate problem-solving sessions
• You ensure artifacts, and templates align to industry standards
• You can effectively negotiate conflict and lead the team through the Design Sprint process while maintaining both neutrality and an unbiased position
• You have broad experience in public speaking
• You have experience navigating and collaborating with interdisciplinary teams
• You can think on your feet and work expertly under tight deadlines
• You have excellent decision-making and analytical skills
• You can prioritize against business, technical, and user constraints
• If the primary decision maker is not in the sprint, you have the authority to stop a Design Sprint and protect the team’s time
• If a team member is challenging the facilitator aggressively, pull him/her aside during a break first and have a conversation. If the problem continues, you can stop the sprint until this is resolved or remove the person from the Design Sprint
• This protection is to maintain the trust of the group. We want to foster a healthy environment for debate. However, it should be done outside of sprint activities.
Now that we have discussed our training program, we will take a deeper dive into the fundamental differences between the D&F Process and our Design Sprint Program. Keep an eye out for the next article and thank you for reading. Comments and feedback are always appreciated.
Links to other series articles are below.