デザインの基本原則

Hello everybody. 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 .

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? 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! 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 .

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 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 . 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 . 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 . 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" . This 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 . 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. 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 ]