Design Sprints
Design sprints, when used properly, are a great way to get answers, quickly, and we use them to help identify solutions to the problems that come out of our discovery phases, and to form a tested, proved prototype for us to move into build as quickly as possible.
For client teams who can commit the time, we run full design sprints on every key objective we find. When scheduling doesn’t allow for such a deep involvement, we still apply design sprints to our internal processes to ensure we’re never simply working to a list of scope, rather constantly thinking about every problem and developing the right solution for the task at hand.
Importantly, we use them when it makes sense, and only then – it’s not our only project process and sometimes it makes more sense to work a different way.
What's involved in a design sprint?
A typical sprint is broken down into 5 key steps, usually run over 5 days, but easily adaptable to be more or less time as the individual problem being solved dictates.
First, we identify the individual problem we want to solve with this sprint, and how it fits into our wider project.
Key to this decision is to pick something that can actually be solved in the time we have. If needs more time, then either break it down more or allocate the time it needs for this sprint.
Individually or in small groups, we come up with a range of solutions, often benefitting from the naturally different approaches you’ll get from people in different areas of the business and project teams.
Again, the focus is solutions that both answer the question being asked, and can be feasibly prototyped in the time you have for this sprint.
Collectively, we review all solutions to decide on the optimal approach. This may be combination of multiple solutions, or one outright winner. It’s not a competition, rather just a way to bring the best ideas from several trains of thought into one, properly thought-out solution.
We’ll then form a brief for the next stage.
We’ll build a testable prototype of the solution. This doesn’t have to be full of tech and pixel perfect, but it needs to accurately reflect the problem you’re trying to solve – the closer it is to ‘reality’, the better the subsequent testing will be.
You test what you’ve built, with real users as much as possible, taking on board how they use your prototype (through observation as well as written feedback), and you input that feedback back into your project knowledge.
Need to make your budget go further?
We focus on your project’s objectives and the needs of your users and your business to make sure that you get everything need, and nothing that you don’t.