So now that we have a prototype, we're moving to the validation stage, right?
>> That's right.
The validation stage answers the hardest question in product design.
The hardest question in product design is
how do you know if your work is any good?
>> Okay, that's an important question.
>> [LAUGH] It's very important.
How we answer this question has three different stages.
At Google we use something that we call triple validation.
Just like in the beginning we looked at a problem from the perspective of
business, technology, and users, at the end
we want to validate the solution from the same three touch points.
The most important opinion, and the most important votes and
validation, is that of the users.
So the critical piece not to miss is the opportunity to
test your prototype with your users.
We recommend sprinters and the sprint lead recruit users from the very
beginning of the sprint, so they know that, at the end, the users are coming.
>> Right.
>> And they have to prepare for it, and
else, all the efforts that they have spent in prototyping could go to waste
because they don't actually know if this is solving the needs the users have.
So meeting the users at the beginning is useful to learn their needs, and
meeting them at the end is crucial in order to test.
This type of test is called usability test or Cognitive Walkthrough.
It allows you to put the products or the early prototype in
the hands of a user and watch them walkthrough all the different stages.
What do they like?
Where do they get stuck?
Do they understand what the idea is about?
And it's important that they have and they expressed earlier on.
>> Do I need to explain to the user what he needs to do?
>> What we like to do in this stage is kind of like it's based on one of
the ideas of writing, show, don't tell.
A great design prototype should be able to stand on its own
without too much explaining.
Generally we'd like to set up the user and say, imagine you're shopping for
a new product, or imagine you're looking to write the review, and
now tell me what you see, and now tell me what you're doing from here.
So we ask the users questions, and ask them to imagine themselves
solving a specific scenario, and we watch what they do.
We ask them questions to clarify, but
we're not trying to sell the product to them.
One of the mistakes that people make in this stage
is that they imagine this is a marketing pitch and
they start explaining how awesome the product is, or why they love the idea.
This is a useful approach if you're trying to recruit that specific person
to buy your product and they might, just because they're trying to be nice.
But this approach does not answer the critical question,
is the product any good?
Like you force someone in person to buy something is very different from
creating something that's popular, and that works on its own.
>> That people love.
>> That's right [LAUGH].
>> And are users the only people I want to get in front of this prototype?
>> Well, the user validation is one of three points in the rapid
evaluation process.
The other two points involve the business and the technology.
It's really useful to test with the stakeholders of the team.
Is it still meeting the business goals?
Is it still answering the promises that you made to investors, or
the goals that you have as a company?
And if yes, fantastic, and if no, we need to go back to the drawing board.
More often than not, teams are aligned with the business goals and
the stakeholders are happy with the results.
But if you skip the validation, they might not approve the design or
block it at a later stage.
So, having your quick check-in with the stakeholders, even if they didn't attend
the entire sprint, can be very useful at this stage.
>> Very cool.
>> Another piece that's important here is doing a technical check.
A design solution that's beautiful but no one can implement, it's only so
valuable.
So what we want to do is encourage teams to check in with a technical staff.
Is this still going the right direction in terms of feasibility?
And if this seems challenging, let's clarify it.
What are the pieces here that seems like they're going to take the longest and
how might we be able to point is designing a way that's not creating
hurdles, and it's something that we can test and deliver quickly?
>> Okay, so what I'm hearing is we need to do three validations,
validate with users, validate with business stakeholders, and
validate with technology people.
>> Yeah, these validations can be rather quick.
A user test can be 20 to 30 minutes and you can test with three or
four or five different people.
For most teams, you can even test with one person, it's already a success.
The business validation can be a five to ten minute discussion, or
longer if the issue is very problematic.
Or the technical validation can be similarly short, five to ten minutes.
We're doing this as a best practice.
Sort of like covering a checklist to make sure that all the possible ways in
which something can fail to deliver after this point are addressed.
And there are also people vouching to the solution,
which makes it easier to deliver afterwards.
>> So what could go wrong in this stage?
>> That's a great question.
What could go wrong is that teams can
be overly confident in their own solution and skip the user testing.
That is a common pattern that we see with teams that are new to sprinting.
They think, well, we can do the user testing later.
It is true that the user test can be done separately from this print, but
that is a miss.
While the team is together and they're fresh in the space
of all the prototyping, it is really valuable to right away get feedback.
If you do the user test with your whole team present and
right after the creation session, this gives the need to write any research
documents and it keeps all the ideas fresh in their minds.
That makes it that much more likely that the products and
the problems will get addressed in the next phase.
>> And what happens if they don't like the solution, if the users hate it?
>> [LAUGH] Well,
if the users hate solution it's a great opportunity to learn.
We try to be humble with our designs.
After all, we only spend two to five days working on them.
We hope that the life of the company will be much longer than that, so
those two to five days were valuable if you learn something.
So if the users don't like something,
it's a great time to seek to understand again.
So we go back to the first way of thinking, which was let's understand.
What is it that they don't like,
is there something that could be solved better?
Asking questions and
probing deeper into the things that users don't like is great opportunity.
The best time to learn if the users don't like something
is right after you have created the prototype, into the five days.
And not after you spend two years of your life telling everyone you love and
maxing out your credit card [LAUGH] this is a great idea.
>> So in this stage,
we take the users, we let them play with the prototype, and we listen to them.
>> That's right.