Design sprints are primarily problem solving tools, but they are also innovation tools. Even though the original design sprint format came from a giant like Google, it was adopted in large numbers by startups and smaller companies that appreciated the speed and efficiency of the sprint.

Somehow, as they grow, most businesses fall prey to their own inertia and cumbersome R&D processes, losing touch with the core traits that enabled that growth in the first place i.e. speed and agility in developing new products, features, or services.

Design sprints are one of the ways to keep the innovation flowing and deliver new value to the market with speed and in a structured format that suits larger organizations and their teams.

This methodology can help big companies hit the balance between speed and scale and quickly validate new product ideas.

In our parent company, SpiceFactory, we work with many enterprise clients and most of them are skeptical about using design sprints internally as they see them as a one-size-fits-all methodology. They are not completely sold on the idea that you can really solve critical business/product questions in 5 days through design, prototyping and testing with users.

However, they’re more open to the process when we communicate the real value of design sprint to them and explain the set of pre-conditions that should be met for them to even consider using a sprint either internally or through an agency like ours.

Do You Need a Design Sprint at All?

We’ve been doing design sprints internally and for clients for a few years now and they’ve been an incredibly useful tool for finding solutions that can move the business forward and fast.

However, they are not a solution to any product-related problem. In reality, they’re best suited for challenges that you can’t find an obvious solution for and that are difficult to tackle with more traditional processes. A challenge like this also needs to carry a lot of weight for you and your team to spend 5 whole days solving.

Before you jump into a sprint ask yourself if the problem you want to solve is something that can be prototyped quickly and validated through user testing at the end of the week.

If that’s the case, and if you feel like you’re on a creative stall, then a design sprint is just what you need to get the innovation ball rolling again.

Getting the Most Out of Your Design Sprint

Over the years, we’ve learned that any design sprint would fail miserably without a certain structure. Let’s look at the elements that need to fall into place for you to run a successful design sprint.

Do Your Research

Typically, the first day of a design sprint is dedicated to defining the problem. Unless you’ve done some research prior to this, you’d spend too much of your valuable time trying to make up for it.

Without proper user research and an understanding of the technical and business requirements for the problem you’re solving, the first day of the sprint can’t possibly go well.

The lack of research will also impact another integral part of the sprint process - user testing. You need to know the users well enough (ideally develop user personas) so you can test with the right group of people and validate your ideas.

Get the Right People

The success of a design sprint largely depends on inviting the right people. There’s no consensus about the size of the team that you’ll need. However, most sprint teams include up to 8 people simply because it’s much easier to handle the planning and logistics for smaller teams.

But who are the right people to invite? This will depend on the specifics of the problem you want to solve. You’ll want to gather the people who will help you get to the answers you’re looking for.

Typically, you’ll want a representative from the following departments:

  • Product management
  • UX/UI Design
  • Engineering
  • Marketing
  • C-level leadership

With this type of team configuration, you’ll have all the perspectives you need to formulate a solution and implement it smoothly after the sprint.

Prepare for Rapid Prototyping

Some companies we’ve worked with don’t have ‘rapid prototyping’ as part of their UX/UI design process and are not prepared for this critical part of the design sprint.

Without a prototype (preferably a hi-fi one that looks like a finished product), you can’t really test and validate with users. So, you need to prepare your team for this and arm them with a prototyping tool that can help them build a realistic prototype in a day.

Make notes diligently

Design Sprints can get messy. You’ll have tons of ideas written on a board, there’ll be more sticky notes and drawings around than after an ‘all hands’ with a design team. But there will also be a lot of discussions and arguments left in the air, meaning no one will write them down.

Some of these thoughts may seem random, but they could be diamonds in the rough. That’s why you need to have someone on the team who’ll take on the responsibility for taking notes, capturing all those ideas, and structuring the creative chaos that’s taking place.

The goal is to have all those creative outputs of the process easily discoverable and usable.

Takeaways

Design sprint is not a one-size-fits-all solution to every product-related problem there is. The complexity, size, and type of the challenge all matter when deciding whether or not it makes sense to run a sprint.

In short, challenges without an obvious solution that could benefit from different perspectives and could be prototyped and tested fast are a good case for running a design sprint.