Working in a large organization with over 100+ employees? Discover how Dovetail can scale your ability to keep the customer at the center of every decision. Contact sales.
Companies in the tech industry must constantly innovate to stay fresh and maintain a competitive position in the marketplace. But quickly developing new products, user experiences, and ideas can be challenging in a workplace full of diverse needs and tasks.
Many companies use design sprints to fast-track the design process and cultivate innovation.
Design sprints are planning sessions that help prevent teams from spending too much time brainstorming, arguing, and sending endless email chains. Instead, it allows them to explore solutions productively and create and test prototypes in a more structured way.
If you’re trying to get out of a design rut or the departments across your business are too siloed for effective collaboration, a design sprint could be the solution that will help get the ball rolling with your company’s next big project.
So, how do you know if a design sprint is the right process for your organization and project? This article explores what design sprints are, how they work, and what you can learn from them.
Use Dovetail to analyze all your customer interviews and uncover hidden UX issues that are costing your business every day.
Analyze with DovetailA design sprint is a short but intense process that uses design exercises and methodologies to allow a team to collaborate effectively without distractions.
The process is typically structured into five full business days. It is designed to be carried out in a single working week and cover all design stages from ideation to prototype testing.
Small teams can hear everyone’s voice within a limited time to deliver quality results and keep costs down. Following the sprint’s format, selecting a dedicated team, preparing speakers, reserving a space for an entire work week, and stocking up on tools and supplies are all essential steps in achieving the desired results.
Today’s design sprint originated from Google Ventures and was created by Jake Knapp. The goal was to develop a process where companies wouldn’t have to develop and release a product to learn what works and what doesn’t.
No set number of participants is needed to run a design sprint. However, it helps to keep the number of participants between five and eight.
Team members may be chosen from various departments to serve specific roles. For instance, you’ll need a stakeholder for the project, an engineer, a visual designer, a UX specialist, and a representative from any other department that would be involved in the project’s completion.
Remember to consider whether you need a copywriter. They will be a useful participant if your product is heavy in copy or if writing is something you struggle with. Note that you won’t need to include a marketing representative if you don’t need them to contribute to the product itself. In this case, you’ll likely only need them to provide a marketing narrative post-launch.
Finally, don’t forget to include a team leader (called a design sprint facilitator) to keep the process running smoothly.
Your goal should be to choose the right team members to represent the most critical aspects of the project. However, the team needs to be small enough for streamlined collaboration. It if becomes too large, not everyone will be able to contribute. If it’s too small, you might miss something important and not produce feasible solutions.
A design sprint is typically carried out over five days. Each day is dedicated to completing specific tasks through different collaborative exercises.
By the end of the week, the team will have learned critical lessons and perhaps developed a usable prototype to start developing a new product.
A design sprint requires a full work week that’s free from typical distractions. Scheduling will depend on each team member’s organizational requirements and responsibilities. It will also depend on how quickly you need to devise a design.
Without proper preparation or dedicated time, a design sprint could fail to meet its goal and become a time-wasting setback.
The design sprint process is suitable for all industries because it acts as a framework for focus but leaves room for creative innovation. It’s used by highly successful companies like Google, Uber, Slack, and Meta.
You may want to consider running design sprints if siloed departments across your organization prevent collaboration. For example, your “right hand” might not know what your “left hand” is doing. Regular design sprints can help mitigate those problems while also giving your team the space and methods they need to find the best solutions. It breeds cohesiveness while encouraging creativity.
It might make sense for you to include design sprints as a first step in developing new features if your company depends on innovation. The process is also useful if you need to fast-track the design of a new product. This might be the case if your competitors are constantly introducing new products and features.
In some cases, it’s best to keep design sprints for brand-new innovations only. This might be the case if you’re a more established business in your market and your teams already have working processes. Note that design sprints are too heavy for small iterations of existing features.
One five-day working week provides team members with a structured schedule that includes five clearly defined phases. By using each day to complete a specific task, the team can track progress and reach the intended goal by the end of the designated week.
Remember to carry out preparation tasks—like identifying challenges, scheduling “lightning talks,” and assembling the team—before the sprint begins.
The typical five-day plan for a design sprint is carried out as follows:
A design sprint must begin with a specific focus on a tangible goal. Monday is dedicated to identifying this goal and developing a foundation and structure to get as much work done as possible during each of the phases that follow.
Mapping the design sprint includes defining an overall objective and creating a simple map of the planned product or service. If you’re developing a new feature, only map those that provide value to the first version. However, in some cases, it’s easier to start with the broader concept and then shave off the “fluff” as the value becomes clearer.
Bear in mind that the designers will only have a single day to create a prototype—so the simpler the map, the better.
During this initial phase of the sprint, you’ll find it useful to hold lightning talks. These are timed five-minute briefs from the people most affected by the current problem or those with the most tribal knowledge of it.
Using a “How might we…” exercise during lightning talks is common practice. Team members are tasked with finishing the statement “How might we…” based on what the speaker is talking about.
Imagine you’re running a sprint to design a virtual school feature for teachers. You might ask:
“How might we give teachers a way to call on students?”
“How might we keep students engaged with what the teacher is saying?”
“How might we empower teachers with analog tools in a virtual environment?”
Ask these questions to get a better understanding of where the team’s focus should be directed. You can use the answers to create customer journey and empathy maps to guide product development.
On Tuesday, each team member will devise detailed solutions based on their different professional opinions.
The sketching process focuses on design rather than artistry and relies on simple line and box drawings. Each team member will work independently to generate a single solution, typically following a four-step process to emphasize critical thinking and limit distractions.
The four-step sketch process is as follows:
Note-taking – usually restricted to 20 minutes and acts as a refresher to get the day started. It allows team members to conceptualize the ideas generated the day before by writing down important details and asking questions for clarification.
Idea development – each participant will take 20–30 minutes to explore ideas and develop a low-fidelity wireframe of a distinct solution. Team members can develop several ideas during this phase. In the final moments, they will choose their favorite solutions.
Crazy 8s – a fast-paced exercise where each person rapidly sketches eight versions of a design in eight minutes, typically using the eight squares of a folded piece of paper. The limited time forces members to quickly push forward their best ideas without overthinking. The session can include multiple rounds and usually lasts 20–30 minutes in total. The remaining time is used to choose and further expand everyone’s favorite designs.
Solution sketch – also called a three-step sketch, this session allows each team member to develop a more detailed sketch of their best idea. It will include a three-panel storyboard with sketches that are self-explanatory and easy to follow. They won’t be viewed until the following day.
On Wednesday morning, the team will review the sketches but won’t debate them.
Each solution will be displayed, and team members will review the sketches without discussion. Each individual uses the five-step “sticky decision” method to apply stickers to the parts they like, meaning the winning sketches will have the most stickers. These sketches will be combined into a storyboard as a step-by-step plan for the agreed-upon prototype.
You can give stakeholders a “super vote” where they use a different colored sticker to determine their preferred approach.
The stakeholder needs to make a decision in front of the team. If they disagree with the wider team’s sentiments, they will be expected to explain their decision to the team. This is somewhat unusual due to all the collective collaboration that has occurred up until that point. They will likely have been influenced by where other team members have placed their stickers.
Day four will be used to quickly develop a high-fidelity prototype of the solutions on the storyboard. By the end of the day, the team will have a workable prototype that will be used for user testing on Friday.
The limited time may seem extreme, but it should keep the team focused on solving just the first iteration of a feature. It should be barebones and not include any irrelevant features the team can save for future iterations.
The final day of the sprint is for testing. This is where the team shows the prototype to five customers in separate one-on-one user tests.
The testing phase is designed to get immediate answers to the most pressing questions about the product design. The design can then be tweaked based on the test results and delivered to the development team to build with confidence.
Like any other design method, design sprints have advantages and disadvantages. Valuable lessons can be learned, even if the sprint doesn’t end with a successful product design launch.
Before you decide whether your team should conduct a design sprint, consider these pros and cons:
Eliminate distractions and debates with a structured process on a strict timeline.
Create an environment for dynamic, focused collaboration.
Develop a clear understanding of customer pain points.
Reduce the cost of failure by having users test a workable prototype.
Stimulate creativity for experimentation and explore a range of ideas that’s broader than typical design methods.
Build team ownership and relationships with enhanced collaboration.
Innovate across siloed departments that may not have connected otherwise.
Fail quickly and more affordably if the design is destined to fail (remember, not all ideas are meant to be).
The short timeframe can limit complex products down to the bare bones, resulting in a simplified result.
Success isn’t guaranteed—the team can walk away from a week of intense work without a solution.
It requires an intensely busy week of hard work.
If the company isn’t fully invested, some members may be forced to abandon the project or only offer partial involvement.
A design sprint’s overarching goal is to create a prototype for a new product or service. However, complete success isn’t guaranteed.
Even if a design sprint isn’t successful, the team can still walk away with critical learning points to use in future product development ventures. Here are some of the lessons your team can learn from a design sprint:
Design sprints are suitable for approaching only specific kinds of problems or ideas—those that aren’t fully formed, have multiple channels of input, or need to be refined down to their specific value propositions. These ideas usually come from research or user feedback asking for a new feature.
On the other hand, design sprints can fail when goals are too advanced to solve within a short time frame, or if the problem is too small to warrant such an intense process.
As a rule of thumb, it’s usually best to leave new innovations for design sprints at the top of a development life cycle. Redesigns, if big enough, can count if the team is open to exploring and innovating extensively.
Remember, if you run an unnecessary sprint, perhaps because the problem was too small or you needed to design an entire product suite, the team will still learn important skills—including when a design sprint is most helpful.
If the prototype fails, the team can likely discern what features caused the failure. They can use this knowledge to tweak their prototypes and test them again before handing them over to the development team. This is similar to any research methodology where even a loss can teach you what not to do.
Insights from a failed prototype help you avoid wasting time and resources on creating an unsuitable product. Depending on what failed and how, you’ll probably just need to do some tweaking and iterating until the design is ready to be developed.
When a design sprint has positive results, you can use the prototype as a clear path to work toward your end product. This method is particularly useful for companies that need to quickly develop new ideas where teams are siloed and cannot collaborate effectively.
Design sprints don’t apply new revisions to an existing design, nor do they fully conceptualize advanced complex functionality. They simply fast-track the early steps of the design process to eliminate distractions and second-guessing.
The approach keeps the team focused on the iteration process and shows them effective workflows. It also prevents them from building out a roadmap based on guesswork and releasing unnecessary features.
Do you want to discover previous user research faster?
Do you share your user research findings with others?
Do you analyze user research data?
Last updated: 18 April 2024
Last updated: 24 June 2023
Last updated: 29 May 2023
Last updated: 22 October 2024
Last updated: 22 October 2024
Last updated: 13 May 2024
Last updated: 22 October 2024
Last updated: 22 October 2024
Last updated: 24 October 2024
Last updated: 22 October 2024
Last updated: 30 September 2024
Last updated: 16 March 2024
Last updated: 24 September 2024
Last updated: 30 January 2024
Last updated: 30 January 2024
Last updated: 24 October 2024
Last updated: 22 October 2024
Last updated: 22 October 2024
Last updated: 22 October 2024
Last updated: 22 October 2024
Last updated: 22 October 2024
Last updated: 30 September 2024
Last updated: 24 September 2024
Last updated: 13 May 2024
Last updated: 18 April 2024
Last updated: 16 March 2024
Last updated: 30 January 2024
Last updated: 30 January 2024
Last updated: 24 June 2023
Last updated: 29 May 2023
Get started for free
or
By clicking “Continue with Google / Email” you agree to our User Terms of Service and Privacy Policy