I'm sitting here with Carl the UX engineer from Google.
>> Hey Jay. Thanks for having me.
>> So Carl, let's talk a little bit about how to get useful feedback
from our users when we're sitting down with them to test.
>> Hm, so sitting down with users,
there's a variety of ways that we can go about it.
I think I like to start out with when we're looking at paper,
I like to start out kind of an informal setting.
I like to leverage folks that are nearby.
And involve them in the brainstorming process
as we start to flesh out features through our prototype.
>> Ok, and do you start with a task that you want them to do,
do you start with just like a flow that you've designed,
do you start with a blank piece of paper?
>> Sometimes it's actually all three.
It could be any of the above.
There are certain times when you're trying to conceptualize new features,
things like that.
Simple sketching is the right place to start.
Just drawing boxes and arrows and circles, and
things like that on paper is a really good way to start,
especially when you have folks that are in non-design roles.
Making them feel comfortable with paper is a really important part of
the prototyping process, but we want to collect as many ideas as we can.
So, we want to make sure that we include those folks.
So, paper sketching is a good way to start.
We can then evolve into looking at specific tasks.
So, we might choose to prototype a specific task.
We might choose to look at holistic flow.
We might choose to do that through a set of drawings or
through high fidelity mocks, maybe that we print out.
And then we can walk through specific screens within that flow.
>> Awesome.
So, pretend for a moment that I'm a user and I've sit down with you.
How do you get me to give you the feedback that you need?
>> So that's a great question.
We like to be really,
really specific about the feedback that we're looking for.
We really want to make sure that we don't just leave an open slate, because
when we leave an open slate, folks will tend to focus on maybe design elements.
Oh, I don't like the color of that thing,
I don't like the position of that thing.
So we want to very specific with the feedback that we're looking for.
The best thing to do is come up with a set of directed questions that will lead
the user in the direction that you're wanting them to go anyway.
>> Okay. >> Maybe through a flow or
with a specific screen.
>> Okay, so you'll ask me a set of directed questions and
I'll sort of go through and talk about them.
When I'm stuck or confused, you ask me to do a certain task,
at what point do you intervene and say the button's right here?
Do you ever do that?
Do you say, just let them be confused and
record that you're confused about where this menu button is?
>> Actually it's a really good thing to record confusion, right?
So when a user gets stumped,
we want to do our best to help them move through the flow.
But we also really need to capture that the user got stumped in that case.
The value there is that we can understand why they got stumped.
We can probe just a little bit more,
understand the difficulty that they came across with that UI.
Was a particular affordance missing, is there something that we can do,
maybe highlight it with a different color, make it bigger, make it bolder,
that kind of thing?
But it also is good to nudge the user through a flow.
>> Mm-hm.
>> If they do become hung up,
you want to progress through the entire test, right?
You need to address all of the research questions that you set out with.
>> Right.
>> And so, letting your user get stuck and spin in a particular area or
on a particular screen is something that we want to avoid.
>> So let's talk a little bit about the questions that we might want to answer.
We've got, you said we need to go through the entire set of questions,
what kinds of questions do we want to be asking about an app.
So we've got some design in our head or on mocks already.
What kinds of questions do we want to be asking about those mocks,
about that prototype?
>> Sure. Questions will tend to be
very specific to the prototype itself.
And so you are going to look for things.
Particular interaction questions might come out.
Does the user know how to get from screen A to screen B?
Do they know where to find button A?
Can they complete a specific task or
something along those lines going through a flow?
Can they find something that maybe is buried three or four screens deep?
>> Right. >> Those are the types of questions we
want to start with.
>> Okay, perfect.
So in our example app,
we might have questions like, can a user check off this task?
Does a user know where the menu button is?
Things like that?
>> Mm-hm.
>> Perfect.
>> Yep.