At Zopa we are great at delivering production features by working agile. However, how do we always know what adds real value to the customer, meets their expectations and therefore which features to build? Enter the design sprint, a new process that we have been experimenting with at Zopa.
A design sprint helps cross functional teams focus in on customer problems and, in just a few days, concept, build, test and learn about the solutions that matter. It’s intensive, a little stressful and a lot of fun.
Design sprints have become widely known recently due to a fantastically written book called ‘Sprint’ that was released by Jake Knapp, John Zeratsky and Brandon Kowitz from the Google Ventures team early this year.
A design sprint however is not really a new concept. Many service and product design agencies that started working with agile methodologies needed a way to formalise the creative process that can otherwise seem rather chaotic. They also needed a way to work with their clients (usually not creative) that would be cost effective, productive and valuable. As a result they looked to break down the creative process into defined steps and fit those steps into a sprint timeline.
Service and production design agencies began to acknowledge that they could never know as much about their clients’ industry as the clients themselves. It was vital that the clients not only bought into design but actively contributed in the creation process. Otherwise at best all an agency could hope to do was create art at worse waste money.
Recently, we did a design sprint at Zopa to tackle a problem our Investor customers have with waiting for their deposits to be lent out. We generally stuck to the format as outlined in the ‘Sprint’ book, but had to make a few changes to fit into the Zopa Sprint cycle.
The book suggests to start on Monday but at Zopa our sprints start on a Wednesday. This introduced a weekend lull into the design process that we actually found beneficial. It gave more time to consider the tools and approach for building the prototype.
We also shortened the time allowed for each day from the suggested 6 hours to 4 hours. This allowed team members the chance to address other work tasks, and although it disrupted the sprint flow it wasn’t as bad as we feared.
The basic design sprint format is.
Is all about planning the sprint, deciding on sprint roles, understanding the challenge and picking a focus for the sprint. It’s about getting a shared understanding of the problem by listening to experts and doing lots of listening and talking. You need to look ahead and see what success looks like and also to imagine how you might fail.
Is the creative and fun day. It’s about being inspired and being free to think of ideas that might solve the problem, everything from the wacky to the mundane. By the end of the day you’ll have sketched lots of ideas. It’s also the time to start the process of recruiting participants for the user test you plan to run on day 5.
Is about critiquing the sketched ideas from the previous day, discussing the merits and concerns of each and then choosing the ideas that you think answer the problem the best. After that, you need to prioritise, plan and storyboard the prototype(s) which you plan to test on day 5.
Is all about building something to test. It’s time for no more ideas. It’s about producing the chosen concept(s) in a way that will seem real to users but not actually build it for real. It’s the customer experience that ultimately matters after all, and thats what we are looking to test, customers reaction to our solution. So whatever means necessary to simulate the idea.
Is about learning. You start a design sprint with nothing but a problem. By day 5 you have researched the problem, made many great solutions, decided on the best and built a realistic prototype. That’s a pretty amazing result for four days work. Now you need to test with real users and learn if you’re ideas were right.
We found design sprints an amazing process that really helps bring the team together and really focuses us on real customer issues. They are probably not for every sprint or every team as the demands of a consistent group can be taxing on normal work flow, but used as and when a customer problem arises that needs some clever thinking they are perfect.
The work we’ve recently created using this process has so far tested really well and we are already implementing parts of our prototypes into the Zopa product.
Find out more from the Google Ventures team http://www.gv.com/sprint/
Or buy the book and try it yourself https://www.amazon.co.uk/Sprint-Solve-Problems-Test-Ideas/dp/150112174X