Learnings from our first design sprint – part 1

By Natasha Popoola

Posted on

This is a story about a Google Ventures style design sprint. If you’ve not heard of that, you can learn more here or read the book.

Inspired by the many successful design sprints detailed on sprintstories.com we partnered with a specialist in flood risk assessment to ‘solve and test a big idea in 5 days’.

The design sprint is a process for testing big ideas, fast. In line with Lean thinking, it encourages validation of ideas before committing effort to delivering them (and avoiding expensive product misfires). The week starts by setting a goal and understanding the company and its domain. It then moves on to idea generation and evaluation before sketching and prototyping a solution. The sprint ends with user testing the prototype to decide if the idea is worth pursuing further. The design sprint is most effective for developing the ideas that you are uncertain of but have the potential to have high impact.

Having read the Sprint book cover to cover, ordered a tonne of stationery and purchased healthy snacks we briefed our partners and were ready to begin. The sprint team consisted of Tom Prior and Natasha Popoola as facilitators from Makemedia and 4 experts in flood risk assessment (CEO, Technical Director, Sales Manager, Environmental Consultant).

sprint overview diagram

Monday

The aim of Monday is to choose a ‘target’ for the sprint. We set the long-term goal to improve the sales process. We mapped out the existing process and quickly identified a pain point for both the customer and provider. We explored this further with the ‘ask the experts’ exercise and noted down opportunities using the ‘how might we’ method. The quality of the assessment needed to be demonstrated to a customer using their own data. This required customers to spend time preparing a representative data sample and send it to developers to run the analysis on, often with customisations. This meant that the sales process was started but then deferred until the customer had collated data and reviewed the analysis. By the end of the day we had a target for the sprint and a shared understanding of the domain.

Tuesday

On Tuesday we individually sketched ideas that could enable customers to self-test the assessment using their own data much earlier in the sales process. We started by using the ‘crazy 8’ method, 8 super quick 1 minute sketches, and then expanded on 1 or 2 of the ideas in detail. By the end of the day we all had produced sketches ready for evaluation the next day.

sketching

Wednesday

On Wednesday we used silent critique, dot voting and straw polls to determine what we would prototype. This was one of our favourite techniques from the design sprint as we were able to very quickly identify the best ideas without wasting time politely discussing the stinkers or falling victim to groupthink and the HiPPO (highest paid person’s opinion)! We especially liked how ideas were forced to sell themselves and be self-descriptive so that we were able to avoid selecting the ideas with the most persuasive sales pitches.

In about 10 minutes we were able to take our quick sketches and create a storyboard to determine the user journey through the prototype. Wednesday was so productive that we took an early lunch and enthusiastically forgot the ‘no heavy lunches’ rule (we had ribs, oops).

design sprint storyboard

Thursday

On Thursday we reconstructed our sketches and iterated on them to create wireframes in Omnigraffle. We created visual designs for each scene in Photoshop, loosely applying the existing brand and wired it all together to create a clickable prototype using InVision. Our aim was not to create something fully featured but just to create a prop for conversation with potential customers.

We were working in a very niche b2b domain and it was not practical to set up 5 user tests on the last day of the sprint due to a small pool of potential users and security hurdles. Consequently the prototype will be taken to customers over the next couple of weeks and we’ll let you know how it goes in part 2 of this blog and share the feedback.

So what have we learnt so far?

Firstly, we were really impressed by how quickly we went from rough sketches of ideas to a storyboard. Although we had used most of the critique methods before, we had never structured them in the same way. We will certainly be doing this a lot more and think they can be used on almost any project, not just in design sprints.

We learnt that complex domains (such as flood risk assessment) need more introduction. The sprint book is very much focused on mass market products (coffee, hotels, instant messengers) which require very little explanation but Makemedia specialise in complex domains (maritime, engineering, political intelligence and construction to name just a few!) and consequently we usually don’t have pre-existing knowledge. We have developed techniques for immersing ourselves in new domains and getting up to speed quickly so next time we will start a sprint with an induction session.

Finally we learnt that although the design sprint is intended to be ran over 5 consecutive days, in the real world we need to be more flexible. It is a big ask for our clients to dedicate 3-4 people for an entire week with no other distractions. Fortunately though, we found that it is possible to run the sprint with a ebb and flow of team members. Ideally however we would say that there should always be at least one subject matter expert involved throughout.

Stay tuned for part 2 where we run through our prototype and share our thoughts on Friday’s user testing.

Back to top