How I use the Design Sprint process

for different types of projects

Yael Levey 19th April 2017

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

Design sprint resources

Want more? Here are some more posts Iʼve done on all things design sprint!

How to use Crazy Eights to generate design ideas and then Download my
free Crazy Eightʼs template

Organise your Design Sprint supplies!

How to prepare for your next design workshop

Boost your creativity – handy prompts for ideation

Using Hopes and Fears in a design sprint

How to create a design sprint calendar