Contact us: mail@poweredbyreason.co.uk
Powered By Reason

Design Sprints

Used properly, a design sprint is a fast way to get answers. We run them on the problems our discovery work uncovers, and come out with a tested prototype that can go straight into build.

Where client teams can commit the time, we run a full sprint on every key objective we find. Where schedules will not stretch that far, we still apply the method internally, so we are never just working through a list of scope. Every problem gets solved on its own terms.

We use them when they fit, and only then. A sprint is not our only process, and some work is better done another way.

A typical sprint runs to 5 key steps over 5 days, though it stretches or shortens to suit the problem being solved.

What’s involved in a design sprint?

Step one — Agree on the problem to solve

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.

Step two — Map out a series of solutions

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.

Step three — Reach a consensus on the best solution

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.

Step four — Build your solution into a testable ‘thing’

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.

Step five — Test it as close to real-world as you can

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.