‘Everything starts with a sketch’. This has always been my philosophy when it comes to design, and it was nice to get some sort of validation on that at the recent BBC design sprint workshop which was part of the Thinking Digital Conference in Manchester last week.

Design Sprints are nothing to do with Usain Bolt or the Agile scrum sprint method used in software development. This Sprint is a method of working that has been developed by Google Ventures and is described as follows…

“The design sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. “

The process works over a five day period and attended by a team of usually around seven people. The days are structured into key focus areas and there appears to be quite a lot to go through, but I’ll try and condense it into readable chunks.

 Day 1 – Understand

Share knowledge, understand the problem and choose a target for the next five days sprinting such as drawing maps to show how the user moves through your product/service. Ask experts not in the sprint group to contribute, taking notes using a technique called ‘How might we’, for example…

“How might we ensure we can measure how effective our new product is?”

Day 2 – Sketch

The process of sketching can be a little daunting to some people, and judging by the look on people’s faces in the room at the workshop this was definitely the case. But it was explained really well by the facilitators and that “everyone can draw a stick man, speech bubble or a phone right?”. It doesn’t need to be any more complex than that. The day starts with reviewing existing ideas to gain inspiration, such as existing solutions already produced. The afternoon is where you get your pens and pencils out; this is more of a visual exercise rather than proving you’re the next David Hockney.

Day 3 – Decide

Hopefully the team at this point will have a load of solutions. The morning session is to agree the best solutions to the problem and which have the best chance of helping you achieve your long-term goal. Some of the processes include sticky exercises, this is something we’ve already used at HMA where users get to vote using coloured stickers on what they think should and shouldn’t be used in the prototype. The afternoon session is the case of storyboarding your sketches to help you create a step-by-step plan for the prototype.

Day 4 – Prototyping

Today is the day that all the previous three days’ work comes together in a realistic prototype to test with customers. The aim is to build a realistic façade to put in front on customers to get a reaction and answers to your questions. The tools you pick can be varied, but time is short so you need to pick the tools wisely. The team needs to be divided up and jobs allocated to each individual to all maximum efficiency to build your prototype.

Friday – Test

The idea is to test your prototype with customers, interviewing your customers whilst notes are taken. After testing its time to make a plan, maybe you need to tweak your solution based on the user testing? Hopefully you’ll have something to work with and enable you to produce an effective solution.

In summary

A really valid point was raised at the workshop that five days may seem like a long time to take seven people out of a working environment. But maybe those 240 man/woman hours used in the sprint stage will save you 500 hours in time when you actual start to run the project, who knows. Maybe for smaller agencies and companies this method needs to be used on appropriate projects that have a healthy budget; or are ‘healthy budgets’ like unicorns?

Overall It was a busy, fast paced afternoon and quite intense (in a good way). A really good mixture of people, including students, educational specialists, designers, and project managers.  The facilitators were a nice bunch of people and ran the workshop well, although sometimes people struggled to fully understand the methodology in such a condensed timeframe, but it made me want to learn more about the processes and how they can be used here at HMA in particular to complement the co-creation processes that are evolving within our digital health projects.

So much so that I’ve downloaded the book on my iPad, I’ll give it a read and let you know how I got on.