So now that we understand tasks, what comes next?
>> Well, then you actually start to get drawing the screens.
You get to pick up the pen, or the white board marker, or the mouse and
start trying to imagine what these scenes,
these environments the user's going to interact with actually look like.
So you're going back to the tasks and
kind of figuring out what are the pieces of information that they need to see.
What are the pieces of information they need to provide.
How do those all fit together on the screen to support that task?
And from there you can kind of start building one screen and
maybe a couple of screens that cover that task.
And then look for connections.
You can start looking for things that happened earlier to the user,
that brought them to this stage.
You know, those screens want to be related in some way.
Or you think about things that they want to do from
that point once they complete that task, well where do they go?
And as you start to kind of get all these screens you start to build these
flows and connect them.
You have a sense of which things are really important which things are less
important or frequently used.
You start to build out the structure for this experience.
And you think about the user might come in this way and spend a lot of time here
and then hop over into this different condition and spend time there.
That starts to guide you about how the overall navigation of that experience
is going to work.
>> And which tool do you love to use to do that?
>> I love paper and pencil.
>> Right.
>> But at some point you get more and more detailed with what you're doing.
So you can start very coarse.
You can just start with a white board or
scraps of paper because you want to kind of fail quickly.
You want to draw out things, realize what's wrong with them,
crumple them up, and throw them away.
And draw them again.
A lot of what I do as a designer is iteration.
And there's a saying that writing is rewriting,
that applies to design as well.
>> Right. >> Design is redesigning.
>> So you design it to show it to someone, you get some feedback, and
then you redesign it.
>> Yeah, absolutely.
And you often will draw a lot of different things.
And just kind of get a feel for, from feedback and from your own experience,
and from the understanding of the user that you've built up through all those
other steps.
Which ones are the best bets, which make the most sense?
And some of that is about making a choice based on the whole product.
It's good if you can get to a smaller number of patterns that the user has to
learn rather than the user having to learn 100 different styles of
working with your app.
>> Right.
So when do I know that I'm done with all these checks?
>> Okay. So you're never done.
That's a joke.
That's design. >> Oh that sounded unfortunate.
>> No sorry.
>> Okay. >> I mean it's great you could try but
you're never going to quite get there.
Like there's always going to be something that you want to change.
You learn something else from the testing or from putting it out.
Or there's some new capability that comes around that you
want to incorporate into the product.
You'll get closer and closer.
You'll continue to approach it, but you'll never quite land there.
So you'll kind of go through and you'll iterate, and you'll redesign, and
you'll go to higher and higher levels of fidelity.
You'll go from those pencil sketches to mockups to very polished mockups to
prototypes.
And you'll start building it at some point.
So that said, there's things you can look for.
>> Okay. >> You don't have to give up all hope.
>> Okay. >> So,
have you covered all of those tasks that you want to address, right?
Have you completely solved the problem you were looking at?
Does the product have a point of view about what things are important and
which aren't?
You know, if you have the tasks that are high priority make them feel like
they're important to the user.
Like stress them so that they know this is what this product is about.
You've done user testing, right?
>> Of course >> Okay, so
have you covered all of the issues that arose from that?
Have you kind of addressed those high priority items?
And then finally, have you solved the problem you set out to solve?
You go back to those original goals and
see am I actually meeting what I understand I need to do for that user?
>> And what would be a good mark or signal to tell me that I need to move
from design to actually do rapid prototyping or stuff like that?
>> You should do that as rapidly as you can.
You know, even if you're just testing things on paper Prototyping it out.
Using kind of the simplest tools that you can do.
You have that analysis phase and then once you move into design,
you know design and prototyping should be very much hand in hand.
The closer you get to something that feels like a real experience to a user,
the better feedback you're going to get from them.
>> Of course. >> In many cases.
So, you want to get to that point as rapidly as you can.