Design Sprints — whats all the fuss about?
How often do we face problems at work that we know need fixing, that we know are costing the business money? How often do we try to drive initiatives that will fix these problems, but they take too long to get off the ground; too many people need to be involved and decisions are not made quickly enough. How often do these solutions then take too long to develop, costing the business money each day, and when developed are not fit for purpose?
Sound familiar?
What if we could work with you to design and test a solution that fixed your problem? And what if we could do it in less than a week?
Not possible? Well it is! It’s called a Design Sprint and it’s being used by the Digital Factory.
So, what is a Design Sprint and what does it do? Design Sprints require experts and decision makers to be available for three solid days with no distractions. The concept is to “lock” these people in a room and use a range of techniques to generate a solution that truly meets their needs, resolving their high priority problems.
It’s a unique experience that necessitates an initial “leap of faith” from participants, requiring them to leave their fears at the door. ALL attendants are expected to contribute equally; ideas are king and ugly is OK (don’t worry we make it look great before the end of the week)
On the fourth day actual users test the prototype of the solution that has been created and provide reactions that feedback into a continuous loop of improvement.
Sounds simple and effective? Yes, it really is. But why is there a natural resistance to this approach?
It simply boils down to changing people’s mindset around the investment of time. The Digital Factory needs the business to invest the four days upfront and consistently the kickback is “we can’t spare people for that long”. But the irony is that the key benefit of a Design Sprint is the speed at which you can progress from a bunch of problems to a tested proof of concept, after which development of the product can begin. Think of the money that’s been saved — a process that can average 6–9 months can be done and dusted in 4 days; not 4 months, not even 4 weeks, just 4 consistent focused days!! And to top it off the product has been approved by users before any development costs have even been spent. As a result, when it comes to spending money on the coding of the solution you know you are developing the right product for the right problem.
So, the question should not be how can we afford to spare resources for four days but rather how can we not?
