Back to main page
Design Sprints Explained
As a product development company, Mooncascade builds a lot of products from scratch. One thing we always keep in mind is testing. For an idea to succeed, we have to know if it provides a solution to the problem our client wants to solve. And we need to do this quickly. You know what they say: fail fast…
But most of the time, building a minimum viable product takes too long. It can take months agreeing on what it’ll be, and even longer to build, launch, and monitor its performance.
That’s why we often turn to the design sprint to test out ideas. For those who don’t know, the design sprint is a five-day process for answering critical business questions that’ll take you through designing, prototyping, and testing a product idea with customers. It was pioneered by the Google Ventures program, and it’s used by some of the best agile development teams across the world.
To help you understand if design sprints are right for you, I’d like to go over their main value, as well as a few use cases to help you identify when (and when not) to use them in a project. Let’s jump right in.
What value can you get from a design sprint?
Say you have an idea for a new product, or for expanding one that’s already been developed. You need to build a solution to a problem. Design sprints are useful because they make you frame your idea as a question and ask: what problem am I trying to solve, and how can I solve it? In other words, your solution becomes a hypothesis that the design sprint will set out to prove.
This helps avoid wasting time figuring out a solution without knowing if it will actually work or not. With a design sprint, you’re forced to get to the core of an idea right away, then immediately jump into determining its value.
Design sprints also align you with the talent that’s best-suited for your project, improving deliverables and speeding up the decision making process. You’ll have to pick experts, deciders, and people to represent the voice of your customers, working closely with each of them throughout.
Not only does this structure give you better, faster results, it also gives you proof of your solution’s performance by integrating user testing in the process. The whole thing will take you five days, or four if you’re doing a design sprint 2.0. That’s lightning fast by any standards.
Using design sprints for kicking off a new project
Design sprints are perfect for kicking off new projects. If you don’t yet have a software product but have an idea for a problem you’d like to solve, this is a fast, effective way of getting started.
By picking one solution to test out in the sprint, you’ll give your team something tangible to work with and greater control of the idea from the start. Everyone involved will work together, dedicating each day to a single goal: understanding, diverging on, making decisions about, prototyping, and validating the idea. This will compress the early stages of the development process into something much more productive than it typically is.
Of course this won’t give you a complete solution from the get-go. But that’s not the point! The idea is to push your project forward without worrying about a full solution right away.
That said, one thing to keep in mind is that the scope of a sprint is always relatively limited. For example, if the problem you’re solving is that people can’t make payments fast enough in a given context, a sprint will only help you answer what you can do to make their payments faster. It won’t take into consideration any other functionalities or ideas that might add to your product’s value, which you’ll have to figure out at a later date.
Using design sprints to solve new problems when expanding a product
Design sprints aren’t just useful for getting started. You can also benefit from them when adding new services to a preexisting product.
You may remember reading about Savioke’s Relay robot, a robot engineered for hotel delivery service. Right before its launch, the robot’s primary functionalities worked just fine: it could navigate on its own, carry items to guests without a hitch, and even ride the elevator. But the Savioke team had one concern. They were worried hotel patrons might find the robot creepy when it spoke to them, especially if it had too many human features.
To test this, Savioke opted for a design sprint. They narrowed down a context in which they could measure guests’ reactions to the robot’s behavior, then prototyped and tested it on hotel customers. The results showed Savioke that the human features they were most worried about were what guests preferred. Thanks to the sprint, they were able to quickly validate a product feature they had been uncertain about, then implement it without worry.
When shouldn’t you use a design sprint?
Still, there are a few cases where sprints just won’t work. If you’ve already figured out a solution to a problem and you’re unwilling to change it, for example, sprints are pointless. In cases like these, my advice is just to user test your idea.
However, if you’ve noticed that a solution you’re trying isn’t working out, a design sprint can help you come up with an alternative. Sprints work best when you have the freedom to adapt your ideas to their results.
One last thing to note: if you can’t assemble a team with enough expertise, including a dedicated decision maker and a voice representing your customers, your sprint will likely fall apart. You need to be able to produce a solution, test it, and make a decision regarding its implementation. If you don’t have a team capable of doing this, set the sprint aside and come back to it once you do.
Design sprints: big value to those open to change.
At Mooncascade, we use design sprints for anything from building new products to creating or improving specific services or processes in something that’s already been developed. It’s a very flexible tool—you just have to be aware of the scope you’ll be working in and be open to change. So next time you’re looking to fail fast, consider a design sprint. It can quickly confirm you’re on the right track, or take you down new roads you didn’t even know was possible.
Thinking about having a design sprint yourself?
At Mooncascade, we’ve run many design sprints, and we even run workshops that’ll help you run them successfully yourself. With our support, you can be sure that after the sprint you’ll have:
- A functional and good looking prototype
- A user-tested solution
- Concrete steps on what to implement and what to improve
- A methodology for how to keep testing
