Transcript
>> Hello everybody.
[ Applause ]
>> My name is Mike Stern.
I manage the Design Evangelism
Team at Apple, and it is my
honor to be with you today to
talk about design.
Now, at Apple, we often use the
term human interface to describe
what might otherwise be called
user interface.
Human interface is an uncommon,
not widely used term, but it has
a really long history at Apple.
Our design documentation, this
is the newly redesigned macOS
HIG, it is called the Human
Interface Guidelines.
This document goes all the way
back to 1978, a full 15 years
before I was even born.
I'm just kidding.
I'm old [laughter].
The word user can have a
clinical or anonymizing effect.
It narrowly defines people in
relation to the interface.
Human evokes a much more nuance
picture of who it is that we are
designing for.
If I say I'm only human, it is
to acknowledge that I have
imperfections, and I have
shortcomings.
I might fall short of your
expectations of me.
Hopefully not right now.
But the word human is also how
we express our highest and most
noble qualities.
When you acknowledge someone's
humanity, you're recognizing
their kindness, their
compassion, their generosity and
goodness.
Designing an interface is
fundamentally about serving
other human beings.
The goal isn't to make a
beautiful app, or a
well-organized app, or a simple
app or a focused app.
Those things are all really
important, but they're not the
real goal.
The real goal is about serving
the human beings or positively
affecting the lives of the
people who use the apps that you
make.
The only thing that really
matters is how well your app
satisfies the emotional and
practical needs of the people
you are designing for.
We have the need for safety and
predictability.
We have a need for knowledge,
for meaning, and understanding.
We have a need to accomplish
tasks, to achieve our personal
and professional goals.
And we have the need to
experience beauty and joy.
Well-designed apps should
provide these things.
Well-designed apps make it easy
for people to predict the
consequences that their actions
will have.
They feel stable, solid,
trustworthy.
They help people to make
informed choices by providing
information that is clear and
helpful.
They have streamlined and
simplified workflows, so that
people can effectively and
efficiently accomplish their
tasks.
And they should have an
aesthetically pleasing,
enjoyable, and even delightful
experience.
Using apps that provides these
qualities is so gratifying, so
satisfying, you can tell that
the people who made the app
fully considered your needs.
You sense all the time and all
the effort that went into
figuring out how to help you get
things done quickly and
successfully.
Everything is there for a
purpose.
Everything is understandable.
It just feels so human.
When an app makes us feel this
way, we sense the humanity of
the people who designed it.
So how does the design of your
app accomplish this?
Now, when we talk about design,
we often focus on technique and
process.
And while these are important
considerations, they don't lead
to great designs.
At least not on their own.
Great designs are guided by a
deeper understanding about what
design is, at a more
fundamental, more human level.
This is what design principles
offer us.
They express core truths about
how we perceive the world around
us.
How we process information, how
we make decisions, and how we
communicate.
These truths are universal and
timeless.
They apply to all kinds of
graphic design.
Graphic design architecture,
interior design, retail design,
landscape design, landscape
design, automotive design, I
think I said landscape twice,
and every other type of design.
Design principles don't tell us
how to do specific things in our
design, they tell us why we
should do those things.
They serve as the foundation
upon which great designs are
built.
This session is about sharing
those principles with you.
Now, some of the things I'll
share today might seem kind of
basic or obvious.
But the most profound things are
often the simplest.
I've been designing for over 20
years.
I've been fortunate enough to
have worked with many brilliant
designers, both at Apple and in
the developer community.
I've had in-depth discussions
about a wide range of
interaction design challenges
across a full spectrum of apps
and games with people from
across the globe.
And in all of those experiences,
I'm constantly reminded, I
constantly return to just how
clarifying it is to evaluate a
design against the core
principles that we are about to
explore.
Okay. So, because design
principles are universal, I
thought it would be fun for us
to explore how these design
principles shape our experiences
in the real world.
Now, there really is no better
way to explore the real world
than to travel.
So, with that in mind, I thought
we would all go on a little trip
together.
Now, it took quite a bit of
persuading, but we managed to
allocate a portion of the
evangelism team's travel budget
to buy each one of you here
today a ticket to Hawaii.
What? Right?
That's pretty awesome.
Sandy beaches, rainforests,
tropical drinks.
Sounds pretty great, right?
Okay who is down?
Who wants to go on this trip?
[Applause and cheering] Yeah?
All right.
Let's go. Now, our journey to
lovely Hawaii is going to begin
somewhere slightly less lovely,
at the airport.
As we approach the airport, we
are going to see all sorts of
signs.
At first, we see signs about how
to get to our terminal.
Then we see signs that provide
more specific information about
what's at each terminal, and
after we find our terminal and
park, we head into the terminal,
and then we get directions to
our gate.
And once we get to our gate, we
are going to know we're in the
right place, because there is a
big old sign telling us so.
And if we are in the wrong
place, or if our flight was
moved, we get directions to
nearby gates.
And in case there is an
emergency or we just want to
leave, nearby exits are clearly
marked.
The system of signs that we
followed is what is called a
wayfinding system.
Wayfinding systems help people
to navigate complex environments
quickly and successfully.
They are critical for helping
people feel oriented and safe.
People at airports are tired,
they're jet-lagged, they're in a
rush, they're stressed out.
So airports need to think really
deeply about wayfinding.
Good wayfinding systems offer a
comprehensive and understandable
list of general locations that
people can visit.
They provide needed detail about
what's in those locations.
They are highly contextual.
They become increasingly
specific as we navigate deeper
and deeper into the system.
They help people to orient
themselves by clearly
highlighting their current
location relative to other
locations.
And they provide a clear exit
path.
It's so comforting to know that
you can return to a place that
is more familiar and start over.
Wayfinding helps us to feel safe
by answering really basic
questions like: where am I?
Where can I go?
What will I find when I get
there?
What's nearby?
And how do I get out?
Without answers to questions
like these, we'd be lost.
Now, your app's interface is
really just one big old
wayfinding system.
The navigation bar, the content
area, the tab bar, they're all
just tools for providing
wayfinding in your app.
The navigation bar title and
selected tab bar item lets
people know where they are.
Tab bar in content areas lets
people know where they can go
and what's nearby.
Simply rendered and recognizable
tab bar glyphs and
understandable labels suggest to
people what they will find when
they get there.
And back buttons offer an exit
route, and can help people to
identify what area of the app
that they're in.
Now every screen in your app
should answer all of these
questions, or else people will
feel lost.
So go through your app.
Go one screen at a time, and ask
yourself, how well is each
screen answering these
questions?
Does every screen help people to
know where they are?
Does every screen help provide
options to people to tell them
where else they can go?
If some screens aren't answering
those questions clearly, then
there is some work to be done.
All right.
So we have a flight to catch.
Paradise awaits.
Wow. That was a quick flight.
If only they were all so quick.
So we have arrived in paradise,
and it's time to pick up our car
and head to the hotel.
What a sweet car it is.
It has got a sweet candy red
paint job.
Check out those rims.
Looks like it will do zero to 60
in like 10 or maybe 11 seconds.
It is a pretty small car.
If I were you, I would yell out
shotgun right now.
>> Shotgun!
>> [Laughs] All right, all
joking aside, cars are actually
quite dangerous.
The fact that we let people
drive around two-ton metal
objects at high velocities is
kind of ludicrous.
Especially when those people
could be tired and navigating
unfamiliar roads.
Now, because of the inherent
danger of driving a vehicle, car
manufacturers have to think
carefully about the design of
interiors.
Safety is a primary
consideration.
And so they're a great way for
us to learn about the design
principle of feedback.
Feedback helps us to operate
cars confidently and safely.
Feedback helps us to anticipate
problems that might cause the
car to stop functioning properly
or to stop moving all together.
Our vacation definitely won't be
very fun if that happens.
Now, cars provide various forms
of feedback.
There is status feedback to let
us know how the car is doing.
There is completion feedback to
let us know whether actions
we've performed are completed
successfully or failed.
Warning feedback, to tell us
about potential problems.
And there is feedback to let us
know when something we've tried
to do has caused an error.
Now, for our safety, for the
safety of other drivers and
pedestrians, the feedback that
cars provide must be clear,
immediate, and understandable.
So let's check out how cars
communicate with us, starting
with how they tell us about
their status.
Now, we have all loaded into the
car, and we are ready to go.
So looking at the gear shifter,
I can see that the car is in
park.
Knowing what gear the car is in
is super important information.
It is so important that it's
displayed twice, on the
gearshift, and in the instrument
cluster.
It would be really bad if I
thought the car was in park when
it was actually in drive, or if
I thought the car was in drive,
when it was actually in reverse.
Other status feedback lets me
see the fuel level, so I can
anticipate and predict how far
we can go before we need to
refuel.
And seeing our current speed
helps me to avoid getting costly
speeding tickets.
These are two really critical
pieces of information.
I don't want to run out of gas
before we get to the hotel, and
the lovely folks in finance have
told me repeatedly that I cannot
expend speeding tickets.
Now, status information in apps
should be just as clear.
So, for example, in the mail
app, unread status indicators
help people to prioritize which
emails to read first.
In Calendar, status indicators
help people to see when someone
can't make a meeting and it
helps them determine if they
need to reschedule.
In the Camera app, there are
three elements to let people
know that a video is being
recorded.
The red dot, the incrementing
time code, the state of the
record button.
They all let people know that a
precious but fleeing moment is
being recorded.
Showing status clearly and
directly is crucial for saving
people time and helping them to
avoid making mistakes.
Next up is completion feedback.
We are ready to go, so I start
the car [engine starts].
We can hear the engine turn
over.
We can feel the vibration of the
motor running.
We see that instrument cluster
come to life.
There is no doubt that we are
ready to go.
And as I shift, from Park into
Drive, I get tactile feedback to
let me know that I'm moving
through those gears.
And as we pull out of the
parking spot, we hear [clicking]
the doors lock.
This happens automatically, so
it is even more important that
we get this feedback.
All of this feedback is
reassuring.
It's our car's way of saying it
is all good, I'm doing exactly
what it is that you wanted me to
do, and this frees me up to
focus on other cognitive tasks,
like making sure it's safe to
pull out of the parking spot.
Completion feedback in apps
serves the very same purpose.
The sound of a locked iPhone
[clicking].
The animation of an email being
marked as unread, or the
animation of an email being
deleted.
These cues are discreet, and
they're non-invasive, but
they're hard to ignore, and they
provide that necessary
reassurance that our devices are
performing as expected.
Of course, confirmation feedback
can be even more obvious.
The animation and sound of a
successful Apple Pay transaction
[tone sounds].
It's very hard to miss.
Every action taken in your app
should provide some form of
confirmation feedback, because
it is absolutely necessary for
letting people know that actions
they've performed were
successful.
Warnings help people to
understand in advance about
potential errors.
Low fuel level.
Low break pads.
Low oil level.
Warnings can be communicated
using status indicators,
messages, and the instrument
cluster, built-in display,
sounds, or all of the above.
These warnings are important.
They keep us safe, and they
protect our car from damage.
And lastly, error feedback in
cars, as with apps, is crucial.
If you try to start a car
without gas, you will get an
error message about that.
Now errors are always
disappointing and frustrating.
It's best to help people avoid
making errors in the first
place.
Warnings and confirmation
feedback can help.
For instance, in-line form
validation is a fantastic
technique for letting people
know what values will be
accepted, and what values will
not.
Getting this feedback in real
time helps people to course
correct so that they don't run
into errors later.
You can also try to infer what a
person was wishing to do, or
what they intended to do when
they made a mistake, and then do
something reasonable.
So, for example, in the new
version of Things 3, if you type
in the date June 31st, which by
the way is a date that does not
exist, but it's a common mistake
for people to make, the app
doesn't throw up an error or
show a warning.
No. Instead, it automatically
corrects the date to July 1st.
It's such a subtle thing.
It's kind of brilliant, and it's
a very human thing to do.
Now, as you can see, clear,
timely, and understandable and
informative feedback is
essential.
Feedback answers super important
questions.
What can I do?
What just happened?
What is currently happening?
And what will happen in the
future?
Many apps do not do a very good
job of providing feedback.
The reason for this, I think, is
that when you're designing, it
is so easy to start to think
about static screens, and you
can lose sight of the fact that
interactive experiences happen
over time, with lots of back and
forth.
Good feedback is like having a
conversation with the person who
designed it.
As a designer, feedback is your
way of letting -- answering
people's unspoken questions.
It is your way of letting people
know how they're doing, and
providing helpful guidance to
them.
So when designing your app,
imagine that you're having a
conversation with the person who
is using it.
What would you say if you were
in the room with them?
How would you say it?
I have a very simple, but highly
effective technique to share
with you.
Ask someone who has never used
your app before to use it.
Have them tell you what they are
thinking, what they think is
unclear, what they find to be
confusing.
Then simply explain to them how
your app actually works.
Guide them along, explain to
them what's happening, and what
they should be paying attention
to.
Then step back.
Consider how what you've said
might differ from what the app
is communicating.
In my experience, when someone
needs to explain their design to
me, it is usually so much more
clear than the design itself.
What people tell me fills in the
gaps that are left by their
design.
We tend to be much better
communicators when we're sitting
with someone in person to try to
capture that experience.
Okay, so that is feedback.
Now, the next design principle
is closely related to feedback,
and that is the principle of
visibility.
Good feedback does not matter
very much if people can't see
it.
Visibility captures something
very obvious.
The usability of a design is
greatly improved when controls
and information are clearly
visible.
See? It's kind of obvious.
Consider how important
visibility is in your car.
The instrument cluster presents
status information and warning
indicators directly in front of
you.
Instrument clusters are visually
cluttered.
There's all sorts of text, and
numbers and moving gauges and
blinking lights and status
indicators.
They're not called clusters
without reason.
But all of this is necessary for
operating a vehicle, and needs
to be plainly visible, without
you having to move your head or
your body.
Hiding some of this information
or putting it elsewhere in the
car would hurt usability.
Critical feedback would just get
ignored, and the same is true
for apps.
In the Mail app, badges provide
helpful status information about
email messages.
Removing that information might
reduce clutter.
It could look a little bit
cleaner, but it would greatly
reduce usability.
People would have to navigate
into each email message to get
that information.
It would be very inefficient,
and it would be very tedious.
So it is important to surface
key status information at higher
levels whenever possible.
Or, consider the navigation in
the Clock app.
What if that was hidden into a
hamburger menu.
People would have a much harder
time seeing what other functions
the Clock app offers to them
beyond what is currently
visible.
Obviously there is a tradeoff
here.
Densely packed interfaces can be
overwhelming and they can slow
decision-making, especially for
people who are new to your app.
So visibility has to be weighed
against other considerations.
Now, with so many of us in the
car, I'm starting to feel a
little bit cramped, and I cannot
wait to get to the hotel, but
there is one more insanely
important design principle to
point out while we're here, and
that is about consistency.
The principle of consistency is
about representing similar
design features in similar ways.
If you've driven a car before,
there are symbols and terms that
you are no doubt familiar with.
You will recognize the symbols
for door lock, for window, for
gas, headlights, battery, oil,
and so forth.
You will be familiar with the
definitions of words like Park,
Drive, and Reverse, as they
apply to the operation of a
vehicle.
Consistency also applies to the
location and the configuration
of controls.
We all expect the brake to be on
the left, and the accelerator to
be on the right.
Consistency greatly improves the
usability of a vehicle, or maybe
it is more clear to just flip
this around and say that
inconsistency undermines
usability.
Whoops. All cars share a common
design vocabulary for these
symbols and terms.
All cars position controls in a
relatively consistent way, and
because of this consistency, we
don't have to re-learn how to
drive a car every time we get
behind the wheel of a new one.
Now, maybe this is obvious, but
consistency is actually hard to
achieve.
You have to make a conscious
effort to be consistent, and you
have to be consistent with the
right things.
You have to fully consider what
expectations people have when
they come to your app.
Those expectations are mostly
informed by their experiences
with the other apps that they
use.
The other apps that they use,
how do you figure that out?
Of course, it is impossible for
you to know.
But you can make some informed
guesses.
Perhaps they've used other apps
that are similar to the things
that your app does.
Maybe not.
But it's very likely that they
have used other apps on the
platform.
So you should pay attention to
platform conventions.
Things like iconography and
terminology, navigation schemes,
and even common work flows for
typical tasks.
Now, let me give you just one
example to make this, I think, a
lot more concrete.
On iOS, the glyph that we use to
represent the concept of an
action is an arrow that points
up and away from a box.
Because the most common action
associated with this glyph is
share, we affectionately call
this a "sharrow."
I love that name.
Now, some apps use a different
icon to represent a similar
concept.
This icon is commonplace.
It is used on websites and other
platforms.
Now, this is a great glyph.
Do not get me wrong.
There is nothing wrong with this
glyph at all.
But it's not the symbol that iOS
users are most familiar with.
This glyph shows up in iOS apps
because of the desire to be
consistent, to consistently
represent this concept in a
consistent way across platforms
or with your website.
This is a perfectly rational and
reasonable thing to do, but it
is not the right call.
From the perspective of the
person who you are designing
for, it is best to be consistent
with the symbol that they are
most familiar with.
Being consistent will go a long
way towards making your app more
approachable and usable.
Now, look, there is always the
impulse to, you know, do things
a little bit different.
And to be clear, this is a
really good thing.
You should absolutely be trying
out new ideas.
That's how innovation happens.
But inconsistencies about simple
things, like icons and labels,
can really trip people up.
So it's always best to be
consistent unless you have a
very strong justification to do
otherwise.
Now, I'm sure you're all
consistently ready to get out of
this car and get to the hotel,
but there is one last point
about consistency that I'd like
to make, and it is about
internal consistency.
Internal consistency is about
designing controls to share a
similar look and feel, that
match each other.
Your app's glyphs should have a
consistent visual style.
Text in your app should have a
limited number of font faces and
sizes and colors and so forth.
Internal consistency helps to
make an app feel cohesive or
whole.
When everything matches, when
everything fits, people are
given a deeper sense of a
product's integrity.
We intuitively believe that
design choices were deliberate
and thoroughly considered.
And with very good reason.
Being consistent takes
self-control and restraint.
All right, now because our car
was so darn consistent, we
finally managed to arrive safely
at the hotel.
That car ride was really stuffy.
So you decide to head up to your
room and freshen up a little
bit.
Perhaps you go throw on that
fresh new Aloha shirt you picked
up at the airport.
So, when you get to your room,
you head to the bathroom, and
you turn the handles on the
faucet and let the water run a
little bit.
And after a couple of seconds
you put your finger under the
water to check the temperature.
It's still a little bit cool, so
you increase the hot water a
little bit.
You wait another couple of
seconds, and the water warms up,
and you commence face washing.
You feel refreshed and
reinvigorated.
Compared to driving a car, a
faucet is really basic.
But at some point, you had to
learn how to use a faucet.
You learned by adjusting the
controls of various faucets and
observing the results.
For example, how do you know
which handle controlled the hot
water?
You knew because for the most
part hot water is controlled by
the handle on the left.
And why would you keep testing
water temperature for a few
seconds?
You did this, because you expect
there to be a delay between when
you adjust the temperature and
when the water actually gets
warmer.
Looking at the water, it is
really hard to tell if the water
is cold or hot, and we have all
experienced burning our hand
under a faucet.
Now, you don't think about these
things every time you use a
faucet.
You just intuitively expect
them.
Within each of your brains,
there is this tiny, little
adorable model of a faucet, and
that model represents the faucet
as a system of parts and
functions and behaviors.
There is a spout for producing
water, there's handles for
controlling temperature and
flow.
Those parts are arranged in
specific configuration, and your
model has certain behaviors,
like the latency between when
you adjust the hot water, and
when the temperature of the
water actually increases.
This model is referred to as
your mental model.
You have a mental model of every
system that you've ever
interacted with.
Those mental models are
over-simplifications.
They don't fully capture the
inner workings of these systems.
Though, the more experience you
have with a system, the more
sophisticated your model
becomes.
Mental models are developed
through personal experience, and
they're based on an incomplete
set of facts, so everyone's
mental model is unique.
Now, real quick, there is
actually two parts of a mental
model that are worth
understanding separately.
A system model is the model
about how a system works.
Our system model might involve
thinking about two independent
sources of water, one hot, and
one cold.
And the system allows those
inputs to be mixed, to create a
range of temperatures.
The system is not immediately
responsive.
Changes to temperature could
take a little bit of time,
especially when we first turn on
the faucet, right?
Our system model includes this
understanding of variable
latency and temperature.
Okay. The other term is
interaction model.
Now, does anyone care to guess
what that model is?
Just go ahead and shout it out.
No, I'm just kidding.
Okay, you guys didn't fall for
that.
You're a smart crowd.
If you guessed that it's a model
about how we interact with the
system, then you are correct.
Our interaction model is that we
adjust the temperature and water
flow with the handles that are
provided.
Okay, so now that we know a
couple of fancy terms, you might
be wondering how all of this is
relevant to you?
Well, when a system such as a
faucet matches our mental model,
then our expectations of that
system are met.
When this happens, and we're not
really conscious of our own
expectations, we perceive the
system to be intuitive.
Conversely, when a system
doesn't match our mental model,
it breaks our expectations, and
we perceive it to be
unintuitive.
Now, let's just sit with this
concept for a second.
Because it's a really, really
important one in design.
And to do that, I would like to
share with you a little story
about a faucet designer named
Mortimer.
Now, like all of you, Mortimer
has a mental model of faucets.
Though obviously Morty's mental
model is way more sophisticated,
and way more bad ass than yours.
I'm just being real with you, he
is a faucet designer for a
living.
Now, consider that job that he
has.
His job is all about making
amazing, best in class,
delightful faucet experiences.
And one day, like a bolt of
lightning, he's struck with this
amazing idea.
We have been doing this faucet
thing all wrong.
He has a new concept about how
to make things better.
Instead of using one handle for
hot water flow, and another
handle for cold water flow, we
should just have one lever to
control temperature, and the
other should control flow.
This way people won't
accidentally increase or
decrease temperature when they
are adjusting flow and vice
versa.
It is brilliant.
This is why they pay Mortimer
the big bucks.
Now, at this point, Morty has
this new and super awesome
mental model about faucets in
his mind.
Unfortunately, there is just one
tiny little problem.
Morty's mental model doesn't
match the mental model that
people have about faucets.
When people use the Morty
faucet, it doesn't match their
expectations at all and they say
it is unintuitive.
What is worse, the Morty faucet
looks nearly identical to a
regular faucet, but it behaved
totally different.
When people turned on the hot
water, no water came out.
This mismatch between expected
behavior and experienced reality
created a major usability
problem.
Perhaps alterations to the
faucet's form could suggest that
it had a different interaction
model.
Maybe adding labels would help,
but these are just remedies to a
deeper issue.
Labels and subtle variations of
form are design cues that can
easily be overlooked, especially
when people have deeply
ingrained notions about how a
system works, and how they
interact with it.
This is a big issue in app
design.
Trust me, I have been there more
than once.
Trying to get people to change
their mental model of how your
app works is risky.
This becomes even more true the
more familiar people are with
your app.
Changes to any long-lived
existing product will inevitably
be hard for people to adjust to.
It really doesn't matter how
good or how necessary those
changes may be.
When considering big changes to
an existing app, you have to be
100 percent positive that those
changes will lead to clear wins
for the people who currently use
your app.
Making changes just for the sake
of it is not a good
justification.
Go carefully.
Test your design.
Prove to yourself beyond a
shadow of a doubt that your
innovations are objectively
better.
If you can do that, then it's
good to push through.
People will come around
eventually.
Okay. So it's time to start
getting ready for dinner.
So you decide to throw on that
dope new Aloha shirt, and you
exit the bathroom and you turn
off the lights by flipping a
switch.
The sun is setting outside.
It is a bit dark, so you turn on
a light in the hallway.
Then you walk over to the
bedroom and you flip on another
couple of light switches to turn
the lights on out there.
This, in a nutshell, is the
design principle of proximity.
Proximity is about the distance
between a control and the object
that it affects.
The closer a control is to that
object, the more we assume there
to be a connection between the
two.
Of course the bathroom light
switch is in the bathroom.
Of course the hallway light
switch is in the hallway.
Of course the bedroom light
switch is in the bedroom.
Greater proximity also makes
ergonomic sense.
In general, the closer you are
to an object or region of
interest, the more likely you
are to want to interact with it
and control it.
People think to turn on the
bathroom light when they walk
into the bathroom.
So, by putting the light switch
right by the door, it is within
arm's reach when they need it
most.
Proximity is also useful for
expressing relationships between
controls.
So, for example, if you see a
set of switches on the wall, and
you know that one of them
controls lights, then it's
reasonable for you to assume
that every switch is a light
switch.
If one of them controls the
shade, then it would be better
to separate it out from the
rest.
This configuration makes it
easier for people to remember
which switch controls the shade,
and which ones control the
lights.
Okay, now it's probably worth
pointing out right now that we
have a very special name for
this configuration, this
arrangement here on the right.
Does anyone care to guess what
it is?
Just go ahead and shout it out.
Okay, you're smart, you're not
going to fall for it.
I just tried to get you.
Okay, if you guessed in your
mind that it is a group, then
you win a prize.
It is a trip to Hawaii.
Grouping is a very fundamental
and significant design
principle.
Grouping helps people to
understand the relationships
between elements, and it is key
for giving a design structure.
Now, while we all understand
this, many apps don't
effectively use grouping.
It can be easy to overlook.
Now, let's take a look at a
couple of examples of how
proximity and grouping can be
used to structure a design, and
establish relationships between
controls and the objects or
views that they affect.
And keynote, proximity helps us
to associate the view menu with
the slide navigator and the
canvas area.
The objects that it affects.
The object creation tools are
positioned right above the
canvas, which is where those
objects go.
The anime format and document
visibility switches are located
just above where those panels
get displayed.
In Sketch, you can see how
grouping is used to cluster
related controls with each
other, like the grouping
controls.
The Transform and Edit tools.
The Pathfinding operations.
And the Layer Ordering actions.
Now, I just shared two Mac apps,
and the need for proximity and
grouping is definitely higher
the larger your interface is,
but the principles are still
crucial for smaller screens,
like iPads and iPhones, and even
the Apple Watch.
Okay, so I think there is time
to learn about just one more
design principle before we head
downstairs to the hotel
restaurant and grab some dinner.
Let's go back to that Shade
control again.
Now, looking at this control, do
you suppose that the Shade is
open or closed?
How about now?
Just show of hands here.
How many people think that it is
closed?
Okay, okay, and how many of you
think that it is open?
Yeah, you guys are a really
smart group of people.
All right.
Mapping is how you know that it
is closed.
Mapping is about designing
controls to resemble the objects
that they affect.
Shades go up, and shades go
down.
So it makes sense to use a
control that mirrors that up and
down movement.
There is no ambiguity about how
to raise or lower the shade.
Mapping also relates to how
controls are arranged relative
to each other.
Their order should resemble the
configuration of the objects
that they affect.
So let's say that these light
switches control three sets of
ceiling lights in the bedroom.
Good mapping involves arranging
the switches to mirror the
layout of those lights.
By focusing on mapping, it is so
much easier to make choices
about where to position
controls, how to order them, and
even which controls to use.
I mean, we've all seen light
switches that look like this.
You will often find labels when
mapping is unclear.
It is a telltale sign.
But it is not a particularly
good solution.
Reading takes time, and it
doesn't help people to memorize
the location of controls or how
they should interact with them.
Now, in the context of
interface, adjusting a
horizontal property is much more
intuitive with the horizontal
slider.
Similarly, using a dial for
adjusting rotation is much
better than a slider or a
stepper.
Of course, the best mapping is
the most direct mapping.
Providing the ability for people
to directly manipulate an object
is more straightforward, it's
more intuitive, and precise.
Whether that is with a pointer
on macOS, or Gestures on iOS.
Okay, so enough about light
switches.
I don't know about you, but I am
starving, and it is time to head
downstairs and get some dinner.
Now, we all meet up in the lobby
and we make our way over to the
restaurant, and as you sit down
at the table, you see in front
of you an empty dinner plate.
What can you do with this dinner
plate?
Well, of course, you can put
food on it, #putfoodonit
[laughter].
But you can do all sorts of
other stuff too.
The plate is smooth, so it looks
like it is easy to rotate and
slide around.
There is a nice little gap along
the edge, so it looks easy to
grab and lift up.
It looks like a Frisbee, so you
consider how far you can make it
go.
Or maybe not.
Our notions about how we
interact with this plate are
called affordances.
In other words, a plate's
physical characteristics provide
visual and tactile cues about
what interactions the plate
afford to us.
A plate's physical
characteristics make certain
actions seem possible, and
others less possible.
We look at the plate, and we
think, I am going to put food
onto this object.
Or, we might also think, I'm
going to use this object to
transport my food to a different
location.
We don't look at this plate and
think, I'm going to use it for
drinking water.
Affordance is not an attribute
of the object itself.
It is more about the
relationship that individuals
have to an object.
Affordance varies based on one's
physical abilities.
So, therefore, affordance varies
from person to person.
So, for example, this is kind of
an extreme one.
A Frisbee affords me with a
possibility of catching and
throwing.
For my dog, a Frisbee affords
the ability of catching, but not
throwing.
A plate affords me with the
ability of eating food off of
it.
Interestingly, my dog perceives
the very same affordance.
Now, because affordance is
subjective, one person can
perceive an affordance when
another does not.
People are more likely to
perceive an affordance when it
is related to an action that
they are more likely to take.
So, for instance, I could use a
plate as a saucer, and it would
make a really great saucer.
I don't think I would get any
argument from you guys, but this
is an unlikely action to take,
so I wouldn't readily perceive a
plate's glass-putting
affordance, whereas I'm very
likely to put food on it.
So I readily perceive the
plate's food-putting affordance.
You perceive affordances with
every environment and every
object that you have ever
interacted with.
When you walked into the
restaurant, you passed through a
door that afforded you the
ability of passage.
The door is human-sized, so you
can imagine your body moving
through it unobstructed.
There was a continuous grounds
plane, so you can imagine
yourself walking along it,
without stumbling, tripping.
The chair that you sat in
affords the ability for sitting.
The table in front of you
affords the ability of putting
objects onto it.
The ground below your feet
affords the ability for resting
your feet.
Manufactured objects include
cues to evoke affordances.
They let people know what
actions are possible, and the
obviousness and visibility of
those cues helps people to know
the correct or the intended ways
of interacting, and the same
should be true for apps.
Sliders afford dragging a knob
along a track.
Dials afford rotating.
Buttons afford tapping, and
clicking.
In each of these examples,
affordance is communicated with
maximum efficiency.
In fact, over time, we are all
becoming more comfortable with
increasing levels of
abstraction.
The button, after all, is just a
highly abstracted version of a
physical, real-world button.
All that's necessary to create a
strong connection between the
two are the rounding of the
corners.
A subtle drop shadow around the
slider knob separates it from
the track that it is positioned
over, and this separation
suggests that it can be moved
independently.
And even that visual cue might
not be completely necessary.
For most people, simply seeing a
filled-in circle over a line is
all that is needed to express a
sliding affordance.
And sometimes affordance is
communicated using animation.
Tapping on the Weather app, we
see it slide up a little bit.
This suggests the possibility
that the content areas can be
scrolled.
And sure enough, they can.
Regardless of the exact
technique that you use, your
app's interface must make clear
what action possibilities it
affords.
If not, people won't know how to
properly interact with it.
They'll interact in ways that
your app doesn't support, and
they'll confuse controls for
non-interactive objects.
Okay. So, now that we know where
our food is supposed to go, it
is time to order.
Now, I am thinking about getting
a cheeseburger because they're
delicious, obviously, and when a
waiter comes by to take my
order, I say, "Cheeseburger,
please."
He then asks how I would like it
cooked, and "medium," I say.
He then asks what kind of
cheese, cheddar, Swiss, Jack,
Gruyere, cottage?
"Cheddar," I say.
He then asks whether I would
like bacon, egg, avocado on it?
"None," I say.
I am trying to keep my figure.
He then asks whether I'd like
salad, fries or onion rings.
"Onion rings," I say.
He then asks if I realize that
cheeseburgers and onion rings
are very high in calories, to
which I reply, "Fake news"
[laughter].
This [applause] in a nutshell is
the principle of progressive
disclosure.
Progressive disclosure is a
technique for managing
complexity.
The term is used almost
exclusively in the context of
interaction design, and to my
knowledge, this is the first
time that anyone was dumb enough
to try to use it to describe
ordering a cheeseburger.
The basic idea is this.
Progressive disclosure gradually
eases people from the simple to
the more complex.
And progressive disclosure is
also about hiding away
complexity, so that people can
accomplish basic tasks with
simple and more approachable
interfaces.
Ordering a cheeseburger would be
way more complex and daunting if
you had to consider all of those
options at once.
Customizing your cheeseburger is
way easier when someone steps
you through the process one
decision at a time.
And some choices that you make
early on could make other
choices irrelevant later.
So, for example, if I'd asked
for French fries, the waiter
would have then asked whether I
wanted regular, truffle or
garlic fries, and because I
didn't ask for fries, I don't
really care what kind of French
fries they have, and telling me
about those options would just
be a waste of my time and my
limited mental abilities.
Or would it be?
I mean, I like garlic fries a
lot, and had I known that garlic
fries were on offer, I would
have gotten them.
So herein lies the rub.
Progressive disclosure is a
necessary and helpful technique
for managing complexity and
simplifying decision making.
But the same technique can bury
information or functionality.
So what do you do?
Well, discussions about how to
properly use progressive
disclosure often come down to
the 80/20 rule.
If you're not familiar, the
80/20 rule is a design principle
that says in essence 80 percent
of a system's effects come from
20 percent of its causes.
For an app, this might mean that
80 percent of its benefit comes
from 20 percent of the actions
that it presents, or 80 percent
of the people who use an app are
only going to use 20 percent of
its functions.
Now, the exact percentages are,
of course, different.
But the basic point is valid.
Not all information or
functionality are created equal.
Some is much more important than
others.
So, in order to reduce clutter,
and simplify decision-making, it
is a really good thing to use
progressive disclosure to hide
things of lesser importance.
In other words, if your app is
complex, it is okay to make the
most useful 20 percent of
functions easier to find by
hiding the other 80 percent.
A classic example of this is the
print dialogue.
Most of the time, people only
care about the basics, which
printer they're printing to, how
many copies, what the range of
pages are.
These are way less than 20
percent of the functions
available, and it is what people
want way more than 80 percent of
the time.
When more control is needed, a
bunch of options are just one
click away.
Not only does progressive
disclosure reduce visual
clutter, and make printing less
difficult, it also lowers the
likelihood of people getting
confused and changing a setting
that they don't really
understand.
Most of us have experienced
receiving this call from a
parent, or a family member, or a
friend, who is kind of freaking
out because their computer is
not working properly, and they
changed something, and they
don't really know what they did.
This is why progressive
disclosure is your best friend.
By keeping things simple for
novices, they are less likely to
feel intimidated, overwhelmed,
or get themselves into trouble,
while more experienced users can
quickly reveal the options and
actions that they require, that
they understand, and that they
are capable of using.
Okay. Anyhow, in case you were
wondering, the cheeseburger and
onion rings were delicious,
thank you very much for asking.
Okay, so it is time for us to
get some sleep.
We will be getting up early
tomorrow, and we are going to be
doing some snorkeling, so guys,
rest up.
Okay, did everyone sleep well?
Was your room comfortable?
Were you able to turn on your
lights successfully?
How is that Morty faucet?
That was pretty weird, right?
Okay, enough small talk.
It is time for us to go see some
fish.
Now, after another highly
successful car ride, we get to
the beach, and you put on your
goggles, and you put on your
flippers, you adjust your
snorkel just so, and you get
into the water.
Now, there are some tropical
fish.
There is a blowfish.
There is a school of tuna fish.
There is a giant squid, for some
reason, because I had the emoji
[laughter].
It is a magical underwater
wonderland.
It is so utterly beautiful, but
why?
This brings us to our very last
design principle.
Symmetry. Symmetry is a concept
that we are all deeply familiar
with, and when we think about
symmetry, we typically think
about reflectional or bilateral
symmetry.
But there is more.
There is also radial, and
rotational symmetry.
And there is also translational
symmetry.
These three types of symmetry
are ubiquitous in nature.
Symmetrical forms are efficient
forms, and we tend to associate
them with good health, with
stability, balance, and
orderliness.
And we consider them to be
aesthetically pleasing, probably
for very good evolutionary
reasons.
Symmetrical elements, even if
they are not physically
connected to each other, are
perceived as though they are.
So when we see these two facing
square brackets, our mind
unconsciously integrates them
into one coherent object.
And as you swim around, you'll
find all three forms of
symmetry.
Bilateral symmetry, rotational
symmetry, and translational
symmetry.
As a matter of fact, just about
every type of plant or animal,
both in the sea, in the water,
on land, in the air,
demonstrates one or more types
of symmetry.
And most human-made objects do
as well.
Light switches are symmetrical
across both the horizontal and
vertical axes.
Faucets are symmetrical.
And cars are symmetrical.
[Laughs] Now there is obviously
some very practical functional
reasons why cars are
symmetrical.
I mean, there is a very rational
reason why you don't want to get
into that car.
But there are clearly aesthetic
benefits as well.
Attractive interfaces tend to
demonstrate a mixture of
reflectional and translational
symmetry.
In the Weather app, reflectional
symmetry provides a sense of
balance.
Key elements are centered along
a median line, while almost all
of the other elements are
counter-balanced with each
other.
This is a pattern which is
reflected in apps like the
Camera app, the Clock app, and
the Phone app, and many, many
more.
Translational symmetry gives an
interface a sense of structure,
and order through the repetition
of like elements.
You can see translational
symmetry in the even repetition
of cities and times in the Clock
app, or the even cadence of
locations in the Weather app.
When laying out your app's
interface, look for
opportunities to use symmetry to
provide a sense of balance and
order.
Okay, so, everyone, I am sorry
to be the bearer of bad news,
but it's time for us to get out
of the water.
There are a lot of you, and we
can only pay for a half day
trip.
Also, I don't know if you saw,
there was a shark in the water,
and I am really starting to
freak out.
So we return back to sunny San
Jose.
Now, the snorkeling here is not
quite as beautiful as Hawaii,
and I strongly urge you not to
go into the bay.
But our technical and design
content is way better, so it's a
win-win.
Now, the design principles that
we explored today express
fundamental truths about human
perception and cognition.
They are simple, but powerful
reminders about the true nature
and purpose of design.
They provide a framework for
understanding, and a language
for articulating a design's
strengths and its shortcomings.
My hope is that in sharing these
principles with you today, you
will come away with a clear
sense of how your app's designs
can help to fulfill those basic
needs that we all share.
The need to feel safe.
The need to understand.
The need to achieve our goals,
and the need to experience
beauty and joy.
Now, to be sure, while these
principles are, in many ways,
quite simple, applying them to
your work is not.
Each of these principles could
lead you into different
directions about what you should
do with the design of your app.
Designing is so often about
resolving those differences.
This is something that the very
best designers struggle with.
It is also possible to have too
much of a good thing.
Too much feedback is annoying.
Too much visibility is
distracting.
Too much progressive disclosure
can make work flows inefficient.
So you have to be measured in
your approach, and exercise
judgment and discretion.
And the relevance of each
principle can vary depending on
what kind of app you're making.
Platform. Screen size.
Use case. The experience level
of the people who you are
designing for.
These factors and more should
influence what principles are
most relevant at any given
moment.
Working through this can be
challenging.
No one said that designing is
easy, but I do not want you to
be discouraged.
Designing is a lot easier when
you understand the fundamentals.
Let these principles be your
North Star.
They will guide you toward
making apps that better serve
the human beings that you are
designing for.
And that is the thing that
matters most.
And in turn, the people that you
are designing for will
recognize, on some level, all of
the hard work that you have
invested.
They will appreciate the
thoughtfulness and care, and
they will sense the humanity of
the people who made it.
Okay, so for more information,
check out this URL.
And, I want to highlight how
many amazing design sessions we
have for you this week.
We actually have eight design
sessions, which is more than we
have ever done before.
We have three sessions that have
five mini sessions in them each.
There is a lot of fantastic
content.
In particular, I want to
highlight a couple of sessions.
One is called Designing Sound.
It is being given by the person
who makes basically all the
sounds that are on your devices.
It is nothing, like nothing we
have ever done before.
It is really fantastic.
It is this afternoon.
And you should go check out
tomorrow, a presentation called
Designing Across Platforms,
which helps to solve really
tricky issues about how to adapt
your app to different platforms.
It is really awesome.
Okay, you guys, it has really
been an honor and my pleasure to
talk with you today.
Thank you so much.
[ Applause ]