How A Design Sprint Saves You Time And Money
In the design world, discussions about the “Design Sprint” are everywhere. With just one swift Google search you’ll find countless articles and think pieces about it. This isn’t surprising; the Design Sprint warrants a lot of attention because it is a remarkably effective design process.
What Is A Design Sprint?
Here’s the gist: a dedicated team discusses a problem, hones in on a solution, and then tests it with real users all within a fixed period of time. Pioneered by Jake Knapp of Google Ventures, the original design sprint was intended to operate over a five-day span: the first three days are spent identifying the key problems and brainstorming their solutions, followed by one day of Prototyping and one day of Testing.
By the end of the initial three days, many proposed solutions have been smashed together, split apart, and iterated upon until a single champion emerges. That champion is then modeled and presented to people in the outside world to solicit their baggage-free opinions.
At Clade, we utilize the Design Sprint across all of our projects because it’s the best way to begin making something, no matter what it is. We find it particularly useful at the beginning of software development projects as it immediately provides the focus required to create a sound, complete product.
By understanding the solution we’re delivering from the very start we are able to more effectively stay on track and avoid scope creep.
Why It Works:
There are a couple of things about this process that make it rather magical:
1. The sprint forces you through assumption-challenging and solution-proposing inside rigid time limits. Constraint breeds creativity.
2. Every idea is initially equal in weight and importance, and through the process of natural selection the best idea wins out.
After walking through the specific steps (challenging assumptions along the way), you finish with real, tangible feedback in just 5 days. Too good to be true, you say? Nope. It’s super true. And it’s all been curated down to a dead-simple process just for us, based on the principles of Design Thinking.
Design Sprints have been utilized by teams large and small. Some of the world’s most successful organizations and companies including Facebook, Dropbox, Nest, and Slack have heralded the process to make their own products, and for good reason! It works.
Why You Should Do A Design Sprint:
- Answer big questions: Gain clarity before building
- Challenge assumptions: Failing early is better
- Save time: Avoid huge pivots in the middle of a project
- Save money: Work in the right direction from the beginning
- Build trust: Teams work better when they are on the same page
Why You Shouldn’t Do A Design Sprint:
There isn’t a good reason to not do it… unless you’ve already done it. Even so, sometimes it’s good to do it again.
The Old Story:
As you can see, the learning and adaptation phase is literally the last part of the process. It places tremendous pressure on the product to be “correct” before you’ve even learned anything. Unsurprisingly, this wastes time and money as resources are spent overwriting work done in the past instead of doing it “right” the first time. If you’ve ever worked with an agency that started throwing around words like “pivot” after the development of your product had already started, you’ve likely experienced this waste of money and time firsthand. Unfortunately, much of the product design world still doesn’t incorporate Design Sprints into their process because they mistakenly see them as being an unnecessary up-front cost.
With our collective 40+ years of product experience, we at Clade have seen first-hand the benefits of starting projects like this — and the consequences of skipping it.
The Design Sprint Story:
By incorporating Design Sprint, the learning and adaptation phases happen before any resources go toward actually creating anything. This saves time and money by producing a clear vision, answered questions, and a testable prototype with user results from real people. In the end, that assurance and clarity will be taken into the creation of the actual product itself, avoiding huge strategic snags and preventing confusion later on in the development process.
Want to learn more?
Learn about it: https://www.gv.com/sprint/
Learn how others have succeeded using it: https://sprintstories.com/
