Design Sprints Don’t Solve Problems

Put a finger down if you’ve ever…

• Wanted to snap your fingers and poof the solution appears
• Searched high and low for that genie that grants those 3 wishes
• Considered going to a psychic to tell you the future
• Wished on a shooting star for the answer to your problems

Just me? Well, if you happen to find the holy grail that lists out the secret formula for building winning products again and again…don’t be greedy. Until then, we’re left to sift through the many frameworks and tools that promise to get you to the solution. They’re not all made equal, but the one that has consistently delivered in our experience is…*drum roll* the design sprint.

If you’ve heard about Google’s design sprint, then it might seem like magic. I mean, you’re telling me that there is a clear, already written step-by-step process AND by the end of day 5 we’ll have a solution? What’s the catch?

The catch is that you use design sprints to learn. Don’t expect some perfect solution in one week.

Sure, design sprints are magical, but they are no magic potion. Design sprints are not a band-aid and they can’t fix or solve a problem. They are more like a diagnostic tool or a magnifying glass, or a fuzzbuster for your ideas.

Hear me out. Imagine you’ve just been tasked with creating the company’s next big product. You start by gathering information to build something to fill this gap. Peers are sharing their version of what the most critical challenge is, researchers are telling you what users need and desire out of a product, engineers are telling you what is and is not possible to build, and the list goes on. So how do you turn all of that information into a valuable and successful product?

Cue the spotlight on design sprints

This is where design sprints can be your diagnostic tool. Think about each of those pieces of information as different symptoms. If we considered them separately, we might identify hundreds of solutions, but only a few will be effective. However, if we consider them together, we get the full picture.

Now, this picture can easily turn into one of Monet’s gardens, so how do we know where to focus? Remember, design sprints help with identifying the problem AND narrowing it down. Bringing different perspectives together gives us a more holistic understanding and enables us to identify where there are commonalities. These areas of convergence can bring alignment and prioritization for what challenge to solve first.

Let’s consider a real-world example. We are trying to create the next big product for healthcare. If we only got our information from one source, we might hear:

• From a key business stakeholder…AI is the future- we have to create a tool that leverages AI. Imagine how much that could help doctors with their patients!

Based on this, the solution should be an AI tool, right? It could be, but there are many unknowns that could impact if this is the most valuable tool for physicians or even how patients could respond to this being used during an appointment. Not to mention if the development teams have the capacity and right resources to build the tool.

This is where a design sprint is especially useful. It brings different experts into the room together to share and build a more holistic view. In the sprint we might hear:

• From a researcher…People don’t trust technology with their symptoms. They want to talk to real people and feel heard. They also need their providers to be accessible. Most people cannot afford to take time off to go to an appointment and only make time when it’s an emergency.
• From an engineer…We’re still fixing the bugs in our current portal and app. We could build a new product, but it’s going to take a lot of time or require new resources.
• From a data analyst…We’ve seen a major decline in our app usage over the last six months. Our users are not engaging with our digital products like they used to.

Now we have a more thorough list of symptoms: keeping up with emerging technologies, making physicians more accessible so people can get the care they need, and needing endless time and endless resources. With this new information we can identify where there is convergence or overlap to help define the challenge most worth addressing.

Fast-forward, your team goes through different ideation and prototyping activities to brainstorm potential solutions. There is a massive range of concepts on sticky notes, sketched on paper, or even built with cardboard. You complete testing with real users to get quick feedback on if an idea addresses their needs and pain points. At the end of day 5, your team is aligned on the challenge and confident in a concept that solves a real problem.

To clarify, solving here doesn’t mean at the end of the sprint we’ll have the solution. The activities and discussions that occur during the sprint help us break out of our typical thinking and push beyond the obvious. It gives us the ignition to ideate based on data and create solutions that solve real problems. It’s a learning tool that leaves us with a lot of confidence in how to move forward and sometimes with more questions to explore.

So are design sprints magic? No, but they sure are magical. Design sprints bring clarity and help put things in focus. It can take you from trying to solve every problem in the garden to having confidence in an idea that helps a specific flower. It may not be the holy grail or a genie that can grant three wishes, but it’s pretty close.

Put a finger down if… you’re ready to try a design sprint!