How I use Design Sprints for different projects

Thanks to Google Ventures, or their book Sprint, (or even through me!), chances are you may have heard of design sprints!

What are design sprints?

In the words of Google themselves,

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

For the past couple of years, I’ve been working with my team to figure out how to make the design sprint process work for us. I’m a firm believer in the idea that processes are made to be tweaked and flexed, depending on the unique circumstance surrounding projects and teams, so we’ve worked hard at figuring out how we can best utilise the framework.

One key takeaway was that the sprint framework can actually be pretty flexible and able to be used in various different ways depending on what you want to achieve.

In this article, I’m going to talk about 3 different ways that we have used design sprints in my team.

The ‘concepting for the future” design sprint

Objective

To conceptualise some future functionality.

Sprint team

We had a design team, an external design agency, and our Product Manager and Tech Lead.

How we ran the sprint

We customised the 5 day sprint recipe to fit over a 2 week period. This was due to the fact that none of the sprint team was dedicated solely to this project (the designers had other projects they needed to work on, the product manager and tech lead were super busy and could only dedicate chunks of time to the sprint, and the external design agency were only with us for 2 days a week).

The process was:

Understand the problem we wanted to solve, market landscape, business and technical constraints
Sketch and refine solutions with input from the product manager and tech lead
Storyboard the prototype/s we wanted to test
Build prototypes
Test prototype/s
Analyse results and pick strongest idea to go forward with

This process fit into the two week period like this:

Days 1 and 2 – we spent the first two days upfront on the Understand, Sketch and Storyboard phases, where we were all in a room working through the stages. I had booked out two hours of time each afternoon from our Product Manager and Tech Lead (the maximum amount of time they were able to dedicate to us) and the rest of us were dedicated for the whole two days.
Days 3, 4 and 5 – the external design agency built out the prototype according to what we agreed in the two days before.
The second week:
- Day 1 – feeding back on the prototype and the agency doing amends
- Day 2 – planning + prepping the testing script, as well as doing a pilot run-through of the testing
- Day 3 – testing
- Day 4 – analysing and writing up the results
- Day 5 – regrouping together to pick the strongest idea to go forward with.

What worked and what didn’t

We wouldn’t have been able to achieve all of this in only 5 days due to people’s diaries and also the scope of the work that we needed to do. Splitting up the design process to fit a longer time period worked in this instance.
Booking in timeslots with our busier stakeholders allowed them to be part of our sprint instead of flat-out declining an “All Day” invitation right out the gate because it would have been too long. We also made sure to invite them at the key points of the sprint that their input would be most worthwhile and effective. This allowed them to feel like their time was well-spent and allowed us to make the most of their attendance.
As this was a conceptual, ‘future-thinking’ project, having a time box of 2 weeks helped ensure that we didn’t spend too long concepting and meant that we actually got to some solid, tested, routes by the end. Without doing this in a ‘sprint’ process, I think we would have spent much longer concepting and not been able to whittle ideas down so effectively.

The ‘Requirements Gathering” design sprint

Objective

To get everybody agreed on a set of requirements for a new piece of functionality.

Sprint team

We had designers, an external partner who would be building some of the new functionality, an internal development team who would also be building some of it, and a Product Manager.

How we ran the sprint

We didn’t stick to 5 days. Instead, we followed a linear process to get to our goal of gathering requirements over a number of weeks, which was much more realistic time frame for the team.

Also, because this sprint was more about gathering requirements than coming up with design ideas, we didn’t follow the exact prescribed activities for each day of the sprint. Our process was:

Run an “Understand” session – to understand where we are now, who we needed to involve, and what we need in order to gather requirements successfully
Design a workshop to gather requirements – we in the design team with some sense checking with our project manager and tech lead created an agenda with a series of activities and prompts so that we would be able to gather the requirements effectively and efficiently
Run a 2 day intensive workshop to tease out the requirements – attendees were the design team, our external build partner, internal development team reps and Product Manager.

Analyse and write up the workshop outcomes

Use the outcomes to build a prototype of the new functionality with the new requirements fed in
Test the prototype!

What worked and what didn’t

Because we had a bunch of disparate teams coming together for this project, calling this a Sprint (rather than just having a set of discrete activities) helped the participants feel like they were part of something together, which was important.
There was about a month’s gap between designing and running the workshop because some attendees had to fly over to the UK and so the trip had to be planned in advance, with a clear agenda of the workshop days they would be flying over for. Obviously, this was not ideal and it would have been great to have run it all in compressed time frame. Keeping momentum during times in the sprint where there might be an enforced lull is challenging, especially when you have other work to do and you might start losing focus. We kept up some momentum by giving ourselves workshop preparation tasks for each week of the break so that we maintained some connection with the project.

The ‘Iterative’ design sprint

Objective

To redesign an existing piece of functionality.

Sprint team

We had a dedicated design team and space for the project, as well as internal stakeholders who would all be using the functionality.

How we ran the sprint

We ran three sets of weekly design sprints, following the sprint recipe almost exactly! We were able to do this because we had a completely dedicated team and space that meant that there were no extra demands placed on anyone’s time.

We did three week’s of design sprints, one straight after the other, as we used each sprint as an opportunity to refine from the sprint before so that each sprint could feed into the next.

Each week looked a tiny bit different. Week One looked like:

Day One – Understand the existing functionality, the market landscape, business and tech requirements, user needs
Day Two – Sketch ideas for redesigning using the Crazy 8’s method

Day Three – Refine ideas and storyboard the prototype

Day Four – Build Prototype
Day Five – Test the prototype

Week Two looked like:

Day One – In the morning, analyse testing results and identify what to focus on next; in the afternoon, sketch prototype refinements
Day Two – Refine ideas and storyboard the prototype iterations
Day Three – Build out Prototype
Day Four – Test the prototype
Day Five – In the morning, analyse testing results and identify what to focus on next

Week Three looked like:

Day One – Sketch prototype refinements
Day Two – Refine ideas and storyboard the prototype iterations
Day Three – Build out Prototype
Day Four – Test the prototype
Day Five – In the morning, analyse testing results and identify next steps for the project

For this sprint, our internal stakeholders weren’t involved in the day to day sprint, because there were so many of them and they were all incredibly busy. So we communicated via a system of emails:

Before the sprints began, I sent out an email explaining the purpose of the sprints, what we wanted to get out of it, the sprint dates, what we would need from them during the sprints, and inviting them to testing days.
I also sent out a link to a survey that would gather their important thoughts and requirements about the functionality that we were looking to redesign (that we explored during the sprint on the first Understand day)
Once the sprints began, I emailed the group every Friday with an update email that included the objective of the sprint, what we achieved in the sprint, what we learned in the sprint and the plans for the next sprint. The email was also an opportunity for the group to get in touch with any questions or comments for us while we were sprinting.
Once the sprints ended, I emailed the group with a wrap-up doc that gave the top-line findings and next steps, as well as doing a presentation to the group where I was able to go into more detail and answer any questions.

What worked and what didn’t

Running three design sprints one after the other was amazing in that we got so much done! However, the big takeaway from me was that too many concurrent sprints without some break can be incredibly wearing on the team. Each sprint is so intense and works people really hard, and so you really need a break in between sprints if you are planning on running multiple ones all in one go. For my team, I think it would have been better to have done a sprint and then have one day buffer before heading straight into the next sprint.
Because there was quite a lot to organise, I found keeping a very visual sprint calendar up in the team space super helpful so that everybody knew what was going on when.
For this set of sprints, we had a completely dedicated space from which to run our sprint out of. This was a game-changer as we were able to completely take over walls and floors (although we didn’t manage to colonise the ceilings!) with documentation and other paraphernalia from our sprint. Previously, we hadn’t been able to secure one space for a whole sprint which meant that we were forever carrying things between rooms and spaces, so this dedicated space was seriously cool for us. If you can secure a space, it makes the running of your sprint so much easier.
Coordinating the communication to our massive group of stakeholders on these sprints was a real challenge but approaching it in an ordered and organised way really helped both the team and the stakeholders.
It was especially important to invite our stakeholders to testing days early before their calendars got booked out. I recommend deciding on your testing day as early as possible and sending out invitations so that your stakeholders can be involved.

The essence of the design sprint process

By experimenting with and expanding the boundaries of design sprints, we’ve learned a lot about how to make the design sprint process work for us – a design team in a really large organisation with our own unique set of circumstances.

However, there are some core components that run through all the design sprints we run, that I believe keep the spirit of the Design Sprint alive, no matter the exact nature of the framework:

A timeboxed amount of time, not completely open-ended
A highly collaborative process, involving people from all relevant parts of the business
Validation of ideas – whether through testing, customer feedback, business feedback – our sprints always include some validation from users and the business