At 383 we believe that the best way to test whether a product or service idea has legs is to get it into the hands of real customers, fast. We’ve got a whole bunch of tools, techniques, programmes and workshops to help you get an idea off the drawing board and into the wild without the usual frictions that gum up the wheels of innovation. One of our favourite methods is the fast track design sprint – a super-quick rapid prototyping technique that can help you validate big ideas with real people in a mere five days (or less!).
The design sprint formula has spread like wildfire across the business and design communities to become the weapon-of-choice for innovating at pace, helping large companies to maintain speed and agility at scale. Since Jake Knapp first developed the process at Google in 2010, it’s been embraced by some of the most disruptive brands, helping to drive their exponential growth – think Spotify, Airbnb and Slack.
At heart, it’s a simple process: define your challenge, gather insights from experts, sketch and remix ideas, design a prototype, and test it with users. It’s powerful, fast and, done right, it can produce some great results. But if you’re just getting started with design sprints, and especially if you’re not used to working with agile methodologies, it can be a bit daunting.
Whilst Google’s original sprint format is a brilliant starting point, over time we’ve found that it only wins part of the battle. At 383, we created our rapid prototyping framework by adapting the design sprint process and combining it with other tools and techniques to help us amplify the impact and overcome some of the limitations. We’ve used it to great success with lots of large companies and big brands to develop propositions, products and services at speed.
In the spirit of adaptability, experimentation and iteration championed in the original Sprint book, we thought we’d share some of our battle-tested insights and tips gained from several years of running design sprints.
Rule one: be prepared
Whilst we can (and do) run sprints in a week or less, we find it’s best to do a little bit of homework in advance. Ideally we like to do at least a week’s research before starting the sprint to help us hit the ground running with some solid insights about what makes our customers and clients tick (something that Google actually does too, but they don’t specifically mention in their guide).
Talk to stakeholders, read any existing research, and get some customer insights up front – it will pay dividends when you start to sketch out your solutions. What’s more, once you’ve built up some solid intel, this can lay the foundation for multiple sprints in the future.
On this point, we’ve found that it’s also a good idea to ideate some potential solutions and build up a pipeline of opportunities in advance, before using sprints as a rapid way to test those ideas out. If you invalidate an idea and have to go back to the drawing board, it’s better to do that with some alternatives already in your back pocket.
Rule two: set clear, simple goals
Be realistic about what you can do in the space of a sprint – it’s not about solving every single problem or addressing every user need. Set specific parameters and make sure the goals are simple and achievable.
It’s easy to get over excited and go off-track, so make sure everyone understands the objectives and is accountable for remaining focused. Have a place to park moonshots or splinter ideas for future consideration.
"We need a multi-discipline team focused on one common goal, so the first thing we do is make a plan. This is really important to understand, what are we actually testing here? What are our assumptions? What do we know based on experience will and won't work? What are the things that we are coming to blind that we need to get some further validation around?"
Leon Barrett, Product Director, 383
Rule three: embrace uncertainty
Uncertainty is baked in throughout the sprint process. You will be figuring out something unexpected every day, and early ideas are supposed to evolve. Expect this to feel very different from day-to-day delivery, where deliverables are more defined.
Don’t panic if it feels like you’re not getting anywhere – the process is on rails. You’ll usually figure out what the blockers are when you come back to it the next day.
Rule four: bend the rules
Even though the process is ‘on rails’ that doesn’t mean you have to be a slave to it. Whilst the Sprint book lays out a great step-by-step guide over the five days, this can be both a blessing and a curse for novice sprinters. In your first few couple of sprints it’s easy to get hung up on executing the steps in the right order rather than focusing on the goal and the outcome. There’s so much to pack in to the week that, if you fall behind or mess up a step, the panic can start to set in and you can easily get derailed.
What’s more, being over-prescriptive actually sells sprints short. The beauty of the formula is that it can be really flexible and adaptable and doesn’t need to be as prescriptive as the guide suggests.
Once you’ve got the basic set-up of ‘get smart people in a room for 4-5 days with a problem to solve’, you can swap all sorts of things in and out depending on the challenge that you need to tackle. Time-boxing the process to five days or less is the thing that actually keeps up the momentum.
Rule five: pivot as required
With so little time to get results, it can be scary to realise that you might be heading in the wrong direction during a sprint. We’ve had moments in the past where a bit of eleventh hour stakeholder insight or a lightbulb moment in our thinking has suddenly invalidated or reframed the very thing we’ve been inventing. That is 100% okay and, to be honest, it’s the whole point of the rapid prototyping process.
Remember, invalidating something is just as valuable as validating it, and going back a step is not starting from scratch but from a position of hard-won insight.
Have we ever gone back to the drawing board on day three of a sprint? Yep. Did we still get something to test on day 5? Definitely. Was the final prototype stronger than our original concept? Abso-friggin-lutely.
"We'll either know that our initial assumptions were right, or actually, we thought one thing but as it turned out, people were after something different. Both those two things are absolutely fine. Because what it means is that we've reduced the risk, and we've got to the end of that week knowing that we can either take this idea forward, or that this isn't worth continuing anymore, and therefore we should kill it."
Leon Barrett, Product Director, 383
Rule six: wrapping up
In most cases, you’ll eventually be playing back the findings of your sprint to stakeholders outside of the immediate project team (especially if you’re agency-side rather than in-house). It’s easy to forget to factor this codification into your timeline which means either having to find additional time outside of the sprint week or panicking to cram it in whilst you’re doing the donkey work under extreme time pressure.
We’ve found that it’s essential to have really great templates set up in advance either in terms of playback decks or structured documents that you can populate as you go along (even if they’re really rough). Codifying as you go means that you can capture insights whilst they’re fresh and you can more easily measure your progress throughout the week.
Finally, definitely take some time to identify clear next steps following the sprint, ensuring that every insight is valuable and actionable. You’ve spent five days accelerating towards some powerful and potentially game-changing insights – just make sure you’re heading towards a launch pad and not a brick wall!
What’s next?
Want to know more about how to get the most out of your design sprints?
- Read Sprint by Jake Knapp. It’s a great introduction to this way of thinking, and often finds its way into our new starter welcome packs at 383.
- Read our guide to rapid prototyping. It’s a process we’ve developed, based on design sprints, to help de-risk and de-mystify innovation and new product development.
- Book an in-house talk. We’ll come to you and talk your team through design sprints over lunch — talk to our Partnership Lead, Tom, to find out more.
