WEBVTT

00:00:00.000 --> 00:00:32.155
In this video, we'll teach you how to use  Google's design sprint process
to create great design faster.
In an age of tight resources, companies  are more reluctant than ever to commit 
to big design projects without a thorough  understanding of their chances of success.
Google has developed a method to make the design process fast and still offer valuable insight.
The process developed by  Google Ventures is called a *design sprint*.

00:00:32.155 --> 00:01:00.347
It focuses on getting insights into *critical  business questions* within a very short timeframe
– just five days.
The process is based on *design thinking*, so it attempts to gain those insights
via *rapid design*, *prototype development* and *user testing*.
The design sprint is a five-phase process.
Each phase takes approximately one day or eight  hours to perform.
So, a sprint can be done in five days.
The five phases of Google's design sprint are
*understand*,

00:01:00.347 --> 00:01:31.692
*sketch*, *decide*,
*prototype* and *validate*.
The design sprint is a *linear process*, but you  are strongly encouraged to *make revisions*
based on your first sprint and then *reiterate the prototype and validate phases*.
You can also move further back to earlier phases and reiterate from there.
In the following, we'll look at each step in more detail,
but let's start by taking  a quick look at how to plan a design sprint.
To ensure that the design sprint will be  successful, some *planning ahead* is required.

00:01:31.692 --> 00:02:04.288
Before the sprint begins, here are some things you should consider.
You should *write a brief* to state the sprint's goal and bring everyone on the same page.
You might also need to collect or *conduct user research* to get insights that can inform the work you do during the sprint.
*Consider who should be on the sprint team.*
Google's sprint process is designed to be run by teams rather than individuals.
That means getting everyone together and ensuring  that they're all aiming in the same direction.
The ideal team would include representatives from  all relevant functions and at all levels in the organization.

00:02:04.288 --> 00:02:34.090
You could also invite external people –  for instance, a representative user or stakeholder.
You need a *suitable space* for the  sprint, typically somewhere bright,
quiet, with lots of wall space and enough room  for people to move about will be suitable.
You have to *gather supplies* for the sketching  and prototyping phases.
Typically, you need office supplies like Post-its, blank sheets of paper,
color markers, tape, and so on.
Finally, you should choose a good *icebreaker exercise* to kick off your design sprint.

00:02:34.090 --> 00:03:00.384
Some members of your team might not have worked together before,
so it's good to start off with an activity to warm people up.
Now, let's take a look at each stage in the  execution of the actual sprint.
In the understand session, your goal is to *create shared knowledge* about the business problem you're working on.
You bring everyone together and unpack all of your  team's knowledge about the problem.

00:03:00.384 --> 00:03:32.702
*Lightning talks*, where knowledge experts use 10 to 15 minutes to share their knowledge about the problem,
is an important part of the understand session.
Typical topics for a lightning talk are *business goals*, *insights from user research*,
an *overview of competitive products*, *technical opportunities*, and so on.
As part of the lightning talk, it can be a good idea to have a presentation by someone from senior management
outlining why the problem  you're working on is important to the business.
Other typical activities of the understand phase are demonstrations of solutions that are already available,

00:03:32.702 --> 00:04:01.799
a detailed walkthrough of any proposed  solution, creating user journeys
and performing user research.
In the understand session, it's also  a good idea to be *clear on the metrics of success*.
And remember, your metrics should be  useful and not pulled out of thin air.
When you do the understand session, it's  important to involve the whole team.
Don't let an individual or group dominate the  proceedings.
The idea is to ensure everyone is on the same page,
and the only way to do that  is if everyone is heard from.

00:04:01.799 --> 00:04:30.480
Once everyone is on the same page, it's time to split the team up and get them to start working on solutions.
Sketch day is an *individual effort*.
Everyone is tasked with coming up with a detailed solution to the problem.
It's a good idea to do this on paper for two reasons.
First, it's quick and it takes no time  to make changes.
Second, everybody is able to sketch so they can participate even if they don't know any wireframing tools.

00:04:30.480 --> 00:05:05.458
For particularly complex, large-scale problem solving,
you might want to break up the problem into *manageable chunks* and assign people a chunk rather than the whole problem.
The aim of sketch day is to get as many ideas down as possible.
If your team is large and you generate a ton of ideas, you might want to allocate an hour at the end of the day
to quickly *reduce the number of ideas* to a more manageable number
before you go into the third day of the sprint.
As you might expect, decide day is all about  *making a decision* about which idea

00:05:05.458 --> 00:05:33.045
you're going to take to the prototype phase.
But there's more to decide day than making a decision.
It's also about working out how your solutions  might conflict with your objectives and abilities.
You can start the day by quickly  listing any assumptions that you
are making about things like budget, users,
technology capacity and business drivers.
Then it's time to review each idea and look at  the conflicts that it generates.
You should have an objective in mind during your review.

00:05:33.045 --> 00:06:01.516
Would you be looking to take a single great idea forward to prototyping?
Or are you going to pick, say, a top  5 and take those forward?
You should be looking to constantly *refine* your list and remove ideas that
simply aren't feasible early in the process.
The entire team takes part in the decision process  by participating in discussions
and through voting for ideas.
Once you have an idea or ideas you  want to prototype,
the last part of decide day is to *create some storyboards for your ideas*.

00:06:01.516 --> 00:06:33.038
The storyboard should show each interaction with the user in a step-by-step process,
and they'll be your specification for your prototype.
You might also want to define a *user story*  or two to help beef up the specification.
As the title implies, on prototype day you have  a single day to *create a prototype*
that your users can test on the final day.
First of all, storyboard what you're going to build if you haven't already done that.
To build a prototype, you can use any tool of your choice.

00:06:33.038 --> 00:07:00.156
Just pick one that you master enough for  rapid prototyping.
The important thing is, don't attempt to learn a new tool on this day.
Just use *whatever you're most comfortable with*.
Finally, remember to *leverage the whole team*.
Assign tasks and get everyone building or helping with something.
Prototyping isn't just for the engineers.  Get people to document,
write, review, plan a user test – any activity that contributes towards your end goal.

00:07:00.156 --> 00:07:31.253
On day 5, you *validate your idea*.
The most important part of the validation  is to bring in a group
of your end users to test your prototype.
It's important that the entire team gets to *observe the users interact with the product*
either directly  or through watching recordings of your test.
A *cognitive walkthrough* or *brief usability  test* are great tools to use in this phase.
Other good activities to validate your design –  to bring in experts and management stakeholders
to review your idea.

00:07:31.253 --> 00:08:00.252
Everyone on the team should make  notes and record what they feel they've learned.
You want to take these notes and  summarize them at the end of the day.
This should help you decide if  anything needs iterating and improving.
At the end of the final day, take some time with  the whole team to reflect on your experience.
As Google puts it, there can be three possible  outcomes to a sprint:
an *efficient failure* – perhaps your ideas didn't work so well, but you learned a lot in the process

00:08:00.252 --> 00:08:30.611
and saved your team a lot of time from going down the wrong path;
a *flawed success* – perhaps some ideas worked nicely, while others didn't:
this gives you insights on what  can be improved and what you could work on next;
finally, an *epic win* – the ideas your team had have  shown great promise and seem to work really well.
You're ready to move into a more serious  implementation phase.
Either way, you can only win!
Whether it's by avoiding failure, learning where more work needs to be put in

00:08:30.611 --> 00:09:04.578
or generating a killer design, you can only emerge from the design *wiser and more experienced*.
The added bonus is that the time you've sacrificed  for this is relatively *short*.
Though this is a tried-and-tested method by Google,
it's also a relatively new concept adapted from Agile methods.
It might take a few tries within your organization  to keep the sprint to five days.
That's OK. You can work towards delivering faster sprints as  you get more practice.
Google design sprints should help you take a process that currently takes months and make it lean and efficient. 

00:09:04.578 --> 00:09:31.805
It's not a substitute for all design processes,  especially not for very complex products,
but it's one that lets you ideate and test  ideas incredibly fast.
A highly productive design team working in sprints is more likely to add business value
and be recognized for their work within the larger organization.
Finally, we encourage you to take a look at Google's Design Sprint Kit
to get more ideas and tools for how to run your own design sprint.