Dissembling Design Sprints

Yomal Gunarathna

January 24, 2023

Design

4 mins

A design sprint is a structured process for quickly solving problems and testing new ideas. It typically involves a small team of people from different disciplines (such as design, engineering, and marketing) working together over the course of a week to come up with and test prototypes of new products or features. The goal is to make rapid progress and learn as much as possible about the potential success of the idea before investing a lot of time and resources into it. The cross-functional nature of a design sprint ensures that many different types of thinking are brought together in one room, and the final outcome is tested with real users, making sure that no bias from within the team or organisation makes it past the chopping block.

What does a typical design sprint look like?

A typical design sprint schedule is usually 5 days long, but it can be shorter or longer depending on the complexity of the problem and the resources available. The 5-day schedule is broken down as follows:

  • Day 1: Understand - The team gathers information about the problem and the users who will be affected by it. They set the goals for the sprint and identify the key questions that need to be answered.
  • Day 2: Diverge - The team generates a large number of ideas for solving the problem. They use brainstorming and other techniques to generate as many ideas as possible.
  • Day 3: Converge - The team selects the best ideas from the previous day and starts to develop them into more detailed solutions. They create sketches, wireframes, and other early prototypes to help them visualise the solutions.
  • Day 4: Prototype - The team builds a working prototype of the best solution. This prototype should be detailed enough to test with real users.
  • Day 5: Test - The team tests the prototype with real users and gathers feedback. They analyse the results and use them to make decisions about whether to move forward with the solution or start the process again.

It's important to note that this schedule is a generalisation, and design sprints can differ in structure and time frame depending on the specific needs of the project or the team running it.

Is this the right process for me?

There are a few key factors to consider when determining if a design sprint is the right method for a specific challenge:

  • Time constraints: Design sprints are designed to be a fast-paced and efficient way to solve problems and test new ideas. If time is a critical factor, a design sprint may be a good option as it allows teams to make rapid progress within a short period of time.
  • Complexity of the challenge: Design sprints work well for problems that are moderately complex and can be broken down into smaller components. If the challenge is too simple, a design sprint may be overkill. If the challenge is too complex, a design sprint may not be able to provide the level of detail and nuance required.
  • Resources: Design sprints typically require a dedicated team of people with a variety of skills and expertise. If the necessary resources are not available, a design sprint may not be feasible.
  • Team alignment: Design sprints work best when the team is aligned on the problem, the goals, and the process. If there is a lack of alignment, a design sprint may not be effective.
  • Solution validation: Design sprints are mainly focused on idea validation, so if a solution is already known and the objective is to execute it, a design sprint might not be the right fit.

If you find that your challenge meets the majority of the criteria above, then a design sprint is likely a good option for solving it. However, it's always recommended to evaluate the different methodologies available and select the one that best fit the specific need.

In conclusion

A design sprint is a great way to bring together a cross-functional team to determine potential solutions and test new ideas. As it is typically a five day process, it saves both time and resources before going too deep into a solution for a problem. It's a suitable method when time is critical, the problem is moderately complex, necessary resources are available, the team is aligned and the objective is to validate an idea. However, it's always recommended to evaluate the different methodologies available and select the one that best fits the specific need.

Yomal Gunarathna

Find and Fix UI issues in your product

with our Free UX audit

Try for Free

Find and Fix UI issues in your product

with our Free UX audit

Try for Free