Running a Design Sprint – how hard can it be?

Sprint - Book by Jake Knapp with John Zeratsky & Braden Kowitz from Google Ventures

First of all, if you don’t know what a Design Sprint is you should start here or just google it. There are a lot of good articles out there describing what a Design Sprint is and how you should go about running one. As always, nothing will go by the book; even less so the first time you do one, so this article will focus on our key experiences from running a Design Sprint for the first time.

The short version is that there is a well defined process from Google Ventures (GV) for solving big problems and testing new ideas in just 5 days. The rough outline goes something like this:

  • Monday: Map out and understand the problem
  • Tuesday: Sketch multiple variants
  • Wednesday: Decide on the best idea and create your storyboard
  • Thursday: Create your prototype
  • Friday: Test and validate your prototype on real customers

We are going to develop a new software product or simplify a relatively complex process for the occasional user, to make it a lot easier to use, and we thought “Why not run this as a Design Sprint?”. The alternative of running lots of smaller workshops and meetings has proven over and over to be inefficient, and did not sound tempting for a task of this size. Why?

  • Trying to schedule a series of meetings in between all the other meetings can waste a lot of time.
  • People forget discussions, decisions and context between meetings, forcing you to play catch up at the beginning of every meeting, again wasting valuable time.

Of course it can be hard to justify that people from all over the business should lock themselves into a room for 5 days, not attending client meetings, ignoring day to day business etc. However if you summarize the time spent for the alternative it is often worse, as it is less structured and the outcome will not be very well defined. Luckily I work for a company where management realize this, and they only saw the positive side of running a Design Sprint.

Unfortunately, due to the nature of the product we are developing, I can’t share photos from the session we did.

So what did we learn?

Lesson #1 – Read the book

Although there are a lot of nice and relatively short articles out there, you should read the book from cover to cover. You should know the concepts and GV’s intentions, and you should know whether they are a good fit for you and the problem you would like to solve. There are other processes out there as well; this is about making sure you have the right tool for the job.

 

Lesson #2 – Read the book again

Second time around you should try all the tasks and tools in the book against your problem. I.e. run through the entire process in “fast-forward” mode. This helps you to understand the process even better and helps you stay calm when hosting the workshop. When running this workshop for the first time, you will focus on being a good, well prepared facilitator – knowing the tools, knowing the next steps, keeping track of time, making sure the discussions stay on track etc. Having gone through the process in advance makes it easier to participate in the different sessions and actually think of the problem, not only of the process.

 

Lesson #3 – Expect the unexpected and plan for the unplanned

Although the book prescribes a very detailed agenda and tools to use, be prepared to deviate if you have to. Sometimes the problem you are trying to solve takes a different direction; we had to adjust the process a bit along the way in several directions to accommodate for this:

    • First we realized that we couldn’t just focus on a small part of the flow; we needed to know more about the entire application. If we had discovered this sooner we might have gone with another process such as Lean Inception instead. But at least we discovered this before we started, and we were able to use most of the process and adjust the last 20%. On day 4 we had a prototype covering most of the application.
    • We also had to postpone day 5 where we should have demoed the prototype to customers. We have a partner with which we wanted to align the proposed UX before we tried it out on real customers. Finding enterprise customers that can participate on a large project like this isn’t done in one day either, and we needed to make sure we found the right customers.
    • Myself as the facilitator, and the designer, often played a bit of catch up during lunch hours; we cut the lunch a bit short to ensure we had the progress we needed – we summarized the first half of the day and prepared for the second half as we had changed parts of the agenda.
    • When you bring together people from various departments they bring different knowledge and experiences to the table. We often found that we needed to let some discussions just play out, even though we were short on time, to get everyone on board with how certain things work in real life. Of course the trick is to choose the right discussions and cut the other ones short.

 

Lesson #4 – Stick to the book, the agenda and the tools

I know I just said you should change things if you have too, but that doesn’t mean you should just change or swap things you don’t like or don’t think will work. We kept most of the process, but we wondered how tools like Crazy8 would be received within the group and if they would work – but you should not change based on that. After all, this is a well-tested process and set of tools – try it as prescribed and then make up your mind. And at least I was continually surprised how well the different tools worked and how willing people were to contribute and participate.

 

Lesson #5 – Get a big room (and book it for the entire week)

Make sure you have plenty of wall space to put up your sticky notes, and at least two decent sized whiteboards. A big room with good ventilation is a must. We had a room that was a bit too small, and after lunch the air gets heavy and it is harder to focus. We ended up switching to another room for the last two days.

 

Lesson #6 – The outcome

For us the prototype was a very valuable outcome, and certainly what we needed. But having something to go along with that prototype, to “tell the story”, summarize goals and challenges, is something we felt was missing. It could be we felt this way because we changed the problem to be solved at the last minute to focus on the entire application rather than a small part of it.

 

Lesson #7 – Have a plan for what’s going to happen next

When you run a workshop like this you tend to gear up, not only those participating, but large parts of the organization. They expect not only to see the resulting prototype, but to hear and learn about the process itself and not least to actually start implementing something. We ended up with some dead time after the workshop and the customer demo where we lost a bit of momentum. Having a plan for what’s coming next makes it easier to keep the momentum and spirit within the organization.

 

Lesson #8 – Do not fill your calendar the first two days after running the Design Sprint

You will need a day or two to summarize and follow up on all the actions that you noted during the sprint, but that didn’t get any focus during the sprint. Also, if you plan to create a document or presentation to go with the prototype, having set aside time directly after the workshops helps a lot.

 

Lesson #9 – Was it worth it?

Short answer – a big YES! Maybe Lean Inception would have been a better fit, but the main takeaway is that spending an entire week (or 4 days as we did) is really effective. You get a lot done, you get everyone on the same level regarding the challenges and what you would like to solve, and you have a great starting point for the implementation.

 

So to answer the question in the title; how hard can it be? It is not hard, but it requires quite a bit of preparations; do those and you will be rewarded. Good luck.