- I practice human-centered design.
And human-centered design, to me,
has four basic principles.
The first is, we focus on the people.
Second, we solve the real, underlying problem,
'cause quite often, what we're asked to solve
is the symptom of the problem.
But if we ask, well, why is that symptom there,
we can find something that is so fundamental,
that the symptom goes away.
Third, everything's a system.
Things are related.
You fix this, and that's a problem.
You fix that, and you have something else as a problem.
You have to think of the entire set
of interlocking, interacting components.
And finally, we're dealing with human beings here.
And human beings are difficult to understand and predict,
in an interesting and fascinating way,
but it means we're never gonna get it right the first time.
And so what we do is we quickly
build something that's, it's a mock-up.
It doesn't really work, but it looks like it's working.
And we can see how people might use it,
and we can see where the problems are,
and we do it again, and again, and again.
And each time we do it again,
we get closer to a real product or process,
a procedure, or service,
and eventually we get one that seems good enough.
But, you know, it's never perfect
because people will change,
and they'll start using the system
in ways we hadn't imagined.
So we're always iterating and improving.
Those are the four principles.
Understand the people, focus on the people,
think of it as solving the right problem, not the symptoms,
it's a system, and always be iterating and improving.
Now, how do we do that?
Well, there are many different ways of doing this.
And in my book, "The Design of Everyday Things",
I talk about a very logical, sensible way of doing it,
in which you start off, first of all,
we watch and we observe, and we understand how people
do their activities, and what's important.
Second, we think hard about what the issues really are,
and we work with the people to understand
what the underlying, fundamental issues beneath that are.
And we make sure we cover the system
and all the people who are involved,
and all the different issues.
And finally, we build prototypes,
and test, and build, and understand.
And so, we do this in that order,
and it makes good logical sense.
In fact, the London Design Council says
there's a double diamond, and the first diamond is where we
try to understand what the real issues are.
And the second diamond is where we try to figure out
what a possible solution is.
Well, all that makes great sense.
That is wonderful if you're teaching in the classroom,
and you have time to do that.
But in the real world, we almost never do it that way.
So, let me mention two or three issues
with doing it that way.
First of all is that there's never time.
When you're working for a client or a company,
as soon as you start, basically you're over your budget,
and you're behind schedule.
That's because we're never given enough time
to do the job the way we'd like to do it,
and we're never given enough money
to do it the way we would like to do it.
And so, when we say, oh, we, let's go and study
what people are doing now,
we go watch them and observe them,
the answer is, oh, yeah, you should be doing that,
but there's not enough time.
And so, how do we do this?
Well, the other problem is that,
if you actually watch designers,
this isn't how they do things.
Quite often, the first thing they do is build something.
Well, wait a minute.
Shouldn't that be last, after we understand the problem,
and the people, and all that?
Nope, because it turns out,
if you build something rapidly and quickly,
and give it to people, you will learn a lot
from how they interact with it.
And so that actually is a way of asking the questions,
by giving them something that you just built,
and they play with it, and they try to make use of it,
and they'll show you what's wrong or what's good.
And you can build from there.
So it's a great probe of their interest,
their desires, their needs, their capabilities.
So that violates what I've been talking about.
So, there's one other thing.
And that's what I will call community-based design.
But you know what?
Let's leave that for another video.