Apple Watch Design Tips and Tricks

MIKE STERN: Hello, everyone.

My name is Mike Stern. I am a User Experience Evangelist at Apple, and it's a pleasure to be with you here today.

So today's session is about designing for Apple Watch, and in particular we are going to talk about tips and tricks about how you can do that.

Now, on Wednesday I gave a different talk on the same topic, but it had a bit of a different nature to it. And for those of you who weren't here for that, it's okay. I'm not totally hurt. But I do want to bring you up to speed a little bit. So there were three key themes for that presentation that I'll review very briefly. Those three themes were Personal Communication, Holistic Design, and Lightweight Interaction.

Personal Communication involves taking what we know about positive and effective interpersonal communication and using that as a model for how we design apps for Apple Watch.

Now, interactions on Apple Watch create a more intimate and personal experience with technology, and it's important that the apps that you design for Apple Watch take advantage of that and feel more intimate and personal as well. Holistic Design is about blurring the boundary between software and hardware, and that could be through the visual design of your app's interface and allowing it to seamlessly blend in with the Apple Watch bezel.

It's about harnessing the capabilities of the Force Touch display and using it properly. Same thing with the Digital Crown. And the Taptic Engine, especially now that we have haptic feedback.

You can use these things to create a more immersive, sophisticated, and nuanced experience for the people who use your apps.

And Lightweight Interaction is about designing for quick looks and fast interactions. It's about taking advantage of the Watch's unique position on the user's wrist. So together, these three themes are the foundation upon which you can design really great apps, notifications, and glances for Apple Watch. And everything we are going to talk about today relates in some way, some shape or form, to these three themes.

But this talk is a little bit different.

Now, in today's presentation, we are just not going to recycle the things that we talked about earlier; we are going to get down to the specifics, the nuts and bolts, the brass tacks about how to make really great Apple Watch apps, notifications, and glances.

And we are going to do that by talking about the top 10 common pitfalls that we've seen developers run into when designing for Apple Watch.

Now, Apple Watch is a new type of device for Apple, and you know, even for someone like me, I've never designed for a wearable device, so a lot of things are a little bit counterintuitive or new. So we see these kind of common missteps. So there's no issue with that, but we want to talk about these things we've learned along the way. Does that sound like a good thing? Are you guys on board with that? Yeah? All right.

Cool. Great. I am really fired up to talk about this, so without further ado, let's get into the number one common pitfall, and that's -- -- and that is not a very good user experience.

The number one common pitfall that we've seen are slow apps.

Apple Watch is all about convenience, so if your app takes too long to install, or it takes too long to launch, or pages take too long to load, that's not very convenient for people at all; right? The design of your app's UI and how you produce graphics can have a huge impact on the performance of your app. You want to design for performance.

So whenever possible, for example, you want to use progressive loading of pages, and that simply means that you don't need to make people wait for all of the content to be ready to display on a page before you let them go to that page. You can bring them to the page, show a few things, and then show the rest of the stuff as it becomes available.

You know, seeing this is pretty disappointing. We want to avoid this. When someone taps a button to load a new page or they swipe to it, they should get to that page immediately. It's a reasonable expectation.

So let's look at an example. Let's say we have an app that simply lists nearby Apple retail locations.

Now, on this screen, we have a list of all those stores, we have the store name, we have the address, and we have the distance from our current location.

Now, all of this information is going to be present on the detail screen for each of these stores, so we have a lot of data that's already ready and stored locally on the watch.

So when we go to that page, we already have a bunch of content to display.

Other things, like the store hours or maybe a description about how to get to the store, it's all text and it's going to load pretty quickly.

Now, perhaps there's also a photo of this store.

We didn't need to make users wait around until we had the photo on the Watch just to draw the page.

In fact, it's better to let people go to the detail page first so they could see specifically what it is that they would have been waiting for.

I mean, by showing a photo label, these labels here make it very specific about what remains to be loaded into the page. And people might not be interested in looking at photos at all of the store, and if that's the case, they have access to the other information on the page. They can get that and then leave. Now, if you use progressive loading like this, you want to make sure that you hold open the space for the things that will eventually load in by using placeholder graphics. The reason for that is when things eventually draw in, you don't want the height of the page to change because if you were looking at something like below the photo, all of a sudden it would jump out of view. It actually, I guess, would go down lower. And that's very disorienting, so you've got to hold the space open. Now, if you use this technique, you should also think about the way that you've ordered content onto the page. You want to put things that are likely to take longer to load further down on the page.

So with that photo offscreen, there's going to be more time for it to load in before the user actually scrolls to see it. They may never realize that it wasn't present onscreen when they had first gotten to this page. Now the next way to design for performance is to optimize your graphics. And the best way to do that is through compression.

When you are producing graphics, it's important to pick the right compressions type and use the right settings.

So for example, with photos, most of the time you are going to use JPEG. JPEG is what we call a lossy format, meaning whenever you save a JPEG, there's some loss to the visual quality or fidelity of the image.

But with moderate compression, that's okay. It may not really affect the perceived quality of the image.

Let's say we are going to compress this photo here. It's kind of blown up, so it looks a little pixilated. Let's compress this photo.

At the highest quality setting for JPEG, it's going to take about 125 K.

As we lower the quality setting, we see that the file size starts to drop off pretty dramatically. At the highest compression setting, the lowest quality setting, it's just about 25 K, or about 20 percent of the highest-quality image. That's a pretty big file size savings, but it's going to look pretty terrible there. Usually when you are compressing JPEGs, you want to find somewhere in the middle.

As you can see, we sort of hit a point of diminishing returns anyway.

So let's look at how these compare side by side.

It's pretty hard to tell that there's actually any difference in quality whatsoever, and yet we've saved two-thirds of the file size.

You can only really see those visual artifacts of compression when you look up close.

But that's not how people experience these images. That's not how we take them in. They look at it on a very high-resolution Retina display on a device that is kind of constantly moving around a little bit because it's strapped to their wrist. So it's hard for people to see those artifacts.

Next, let's talk about PNGs.

Now, PNGs are basically the way most other graphics other than photos are displayed on most apps, and by default, PNGs use a 24-bit color palette, which basically means that there's millions of colors that are at your disposal for drawing the artwork in the graphic.

But for most graphics like this icon, that's way more color than you actually need.

So when you save out your PNGs, you should be aware that there's also an 8-bit color palette setting that you can use.

That just means that you have 256 colors or less to draw your images, but for this graphic, it's more than enough. In fact, it's only at around 200 colors or less that we start to notice any kind of dithering or posterization of our artwork.

You want to be really frugal with file-size settings by using 8-bit pings.

As you can see here, the file size savings are really tremendous. It's almost a tenfold decrease in file size.

Again, there's no discernible difference in quality.

When your app has a lot of graphics, the overall file size savings can be really tremendous, especially when you have image sequences for animations. It can lead to significantly smaller sizes for your apps. So it's important to take this stuff seriously.

Now, next you want to avoid using transparency when it isn't necessary. Transparency requires alpha channels, and alpha channels take up file size. So avoid those unless you actually need it. Now, sometimes you do need transparency. For example, this graphic for the Weather glance, it's composited against a translucent dark background that blurs the watch face behind it. Because of that, you need transparency to let that color information come through.

But a similar icon for the Weather app doesn't need it. It's always composited against a black background.

So we can just assume and bake in that black matte background and not have an alpha channel at all. Okay. Now, the last main technique for optimizing graphics is to just make graphics at the size you actually need them. And this is especially true when you are sending over graphics at runtime. There is no sense in sending over a larger graphic or video than what you actually need to display on the Watch, and that's especially true if portions of it are just going to get cropped out anyway. So make sure images and videos are the right size.

Okay. So designing for performance means progressively loading content on pages. It means ordering things so people don't realize you are progressively loading content, and optimizing graphics through compression, no transparency, and using the correctly sized graphics. Now, for more information, I recommend watching the video for this session. There's lot of great, a little bit more engineering-focused tips and tricks about how to optimize for performance.

Now, there's another really good technique for optimizing the performance of your apps, and I'd like to share it with you now. It's a really, really good one, and it involves not making complex apps.

Common pitfall number two.

Now, a little bit earlier I said I wasn't just going to recycle content from my earlier presentation. That's a little bit of a fib because I am going to do that a bit. Apple Watch is not a miniature iPhone. This is so important that I want to say this twice. We've seen developers do this time and time again, and again, it's a natural thing to try to take our assumptions and processes for making apps from iPhone and apply it to Watch, but it winds up with apps that are difficult to use and difficult to navigate.

Apple Watch is ideally suited for quick looks, for convenience, and brief interactions.

So what information and actions do people really want quick access and convenient access to from your iOS app? Make sure that you focus on the essentials. Don't overload your app with too much information or functionality.

This is really a recipe for poor usability on Apple Watch.

So for example, the Calendar app on the iPhone does all sorts of things that the Apple Watch Xalendar app does not.

You can't search in the Calendar app on Apple Watch.

You can't add events. You can't manage your calendars.

And you can't see nearly as far into the future or into the past at all.

Calendar on Apple Watch is just a small subset of the overall functionality of what you can do on the iPhone, but it's the things that make sense for the Watch.

Right? You can check your calendar, what's going on today and what's happening in the next few days. You can get a little bit of detail about each of the events in your calendar. You can accept, you can decline invitations, you can contact the organizer in case you are running late or you need to cancel the meeting.

This is the things that make sense on the Watch. Not all of the other stuff that you can do on your iPhone.

Apple Watch apps should complement your iPhone app. As we just saw with Calendar, that could be by providing a small subset of the overall functionality from your iPhone on Apple Watch, or it could be extending the capabilities of your iOS app.

So for example, the Camera app for Apple Watch turns Apple Watch into a viewfinder for Camera on your iPhone, which allows you to set your iPhone far away from you, take a picture of yourself, friends from a distance, and make sure that everyone's in the frame. It's extending the experience of the Camera app on iOS.

Now, I challenge you to think about how you can do a similar thing for your apps with Apple Watch. How can you extend the experience of your apps in ways that were not previously possible? Okay. Common pitfall number three is tedious navigation.

Tedious navigation is the result of inefficiencies in the user flow that makes it harder for people to find what it is that they're actually looking for.

Now, tedious navigation often results from choosing the wrong structural model for your app.

There are two structural models, two core ones, for Apple Watch. The first one is a page-based model, and here we just have a series of pages that are sort of side by side with each other and you swipe to go between them.

That's the model that Weather uses. You swipe from city to city.

The other structural model is a hierarchical model, and in a hierarchical model, you have a high-level set of categories or content summaries, and then you tap one to go to more detailed information or more specific functionality.

Stocks is an example of a hierarchical app. At the top level, we have a list of stocks and markets, and if we tap on one of these, it pushes on a child view with more specific information on the item we selected.

In watchOS, it's not possible to mix these models with each other.

So you can't start with a page-based model and then transition to a hierarchical one at lower levels.

And conversely, you can't start with hierarchy and transition to a page-based model at lower levels.

The reason for this is because of screen size.

To explain why, let's look at this child view in a hierarchical app. So I just highlighted that little chevron or back arrow in the top-left corner, and that's your way of getting back up to the parent view if you tap that button. But it's a pretty small tap target, and the hit area for it is not very well defined. It's a little bit definitely bigger than the arrow, but not much.

So to make it easier for people to get back up to the parent view, you can also swipe in from the left edge of the screen.

And that will help you transition back up to the parent view, as we see here.

Now, the trouble is in a page-based app, very similar gestures how you go to the previous screen. And because the Watch display size is pretty small, it's difficult to support both of those gestures simultaneously.

So you must decide which model is best for your app.

The structure that you choose should obviously make it easy for people to find what it is that they are looking for with as few swipes or taps as necessary.

Now, usually deciding between hierarchy or a page-based structure comes down to the number of screens that are in your app and the type of information that you are displaying.

So a page-based structure works best when you are showing a flat collection of information in which all of the items are peers, and page-based apps shouldn't have too many screens because swiping between them is a relatively slow way to browse through content.

So Weather meets both of these criteria. Most people only want to check the weather for a few cities, so you don't have too many items, and it doesn't feel cumbersome that you have to swipe between them. When it comes to understanding weather conditions, all cities are basically equal. There is no need to organize or categorize them on some higher level.

On the other hand, hierarchical apps are better for larger or more complex data structures.

People may use the Stocks app to track dozens of stocks and markets at the same time.

By using a top-level list, navigating to any one of those individual stocks or markets is really easy to do. You just scroll the screen, find the one you are looking for, and select it.

Now, the other cool thing about this is there's a ton of really useful information just at this level. So people may get all of the information they actually need without even needing to navigate at all.

That's really efficient.

Okay. So, now just imagine if we had designed this as being a paginated or page-based app. It would take people forever to get through all of the stocks to go from -- to find the one that they are looking for if it was really far away.

And hopefully they would start swiping in the right direction because if they didn't, they'd have to double back and go all the way back to the beginning.

Choosing the right model is really important.

Tedious navigation can also result from overusing modal sheets.

Now, modal sheets support paging through multiple views, and I've seen people try to get around this limitation of not being able to go from hierarchy to page-based structures by using modal sheets instead.

Now, this is something that I would strongly advise against.

First of all, modal sheets don't display the time, and we think it's pretty important that most of the time people can see the time on their Apple Watch.

And the animation of a modal sheet sliding up is meant to be a bit disruptive. It's like this separate pane of information, which slides up over the main interface and takes people out of the main app experience. It's meant to signal a departure. It should feel a little bit disruptive. So if a primary aspect of the way people navigate in your app causes these modal sheet animations to occur all the time, the overall experience is not going to feel very fluid. It will feel jarring, disjointed.

Now, another thing related to modal sheets and tedious navigation, is you don't want to have too many modal sheets sliding up over each other or back to back. This is the same thing on iOS. People will start to feel like they are lost in this modal experience that never ends, and they will have difficulty or feel like it's difficult to get back to the main experience of your app. Now, regardless of what structure you choose, it's important to keep it simple.

So in a hierarchical app, you shouldn't have more than two levels of hierarchy, three at the most. Anything more than that, and it's going to take people a long time to find the things they are interested in, and they will start to feel lost in your hierarchy.

And with page-based apps, as I was suggesting before, avoid having too many pages. Again, swiping through all of these pages will take a lot of time and feel really tedious.

Tedious navigation is really inefficient navigation.

And there's that design principle I was talking about earlier, Lightweight Interaction. Lightweight Interaction is really all about efficient navigation, or a big aspect of it is efficiency.

So moving on, the fourth common pitfall is confusing labels.

Now, what I am talking about here is mostly about page titles and the Close buttons or Dismiss buttons for modal sheets.

Let's start with page titles.

Now, a common misconception is that in a hierarchical app, the title there where it says Do Not Disturb on the right side, that that's actually a Back button or Back button label and not a title for the current view. But that's not really the case.

If we were to use it as such, we would wind up having multiple screens that share the same title, and at a quick glance, they both are supposed to look like titles. So you should really avoid doing this.

Now, I understand why people do it. This is also wrong for the same reason. It's not a Back button, so please don't have Back here instead. So as I said, I got ahead of myself. I understand why people treat it as a Back button because it originally resembles a Back button from an iPhone or an iPad.

But on the iPhone or an iPad, you have space to show both the Back button and a title at the same time.

Now, in Apple Watch, the display is much smaller, so you can't show both. It would be kind of ridiculous. So you have to choose which one to show, and ultimately, showing a title is more important than showing a Back button. It's more important that people know what they are currently looking at than what's on the previous screen or the parent screen. Now, the other common misconception when it comes to labels relates to modal sheet Close buttons or Dismiss buttons.

Now, these can be renamed because, instead of saying Dismiss, it might be more natural to say Close, or Done, or Cancel. But however you rename it, it needs to be clear to people that these are actionable. People need to realize that they can tap that label and it's going to do something. And not just do anything. It's actually going to close the modal sheet and take them back to the previous screen.

So you don't want to do something like this, where you just use it as a title, because then people are not going to realize that it's actionable, and they are going to hunt around and try to figure out how they are actually going to close the modal sheet and be stuck in this screen for too long.

And for a variety of reasons, please, please do not do this. Right? As I said before, even in a hierarchical app, you shouldn't treat this as a Back button.

So this is just putting an angle bracket and the word Back in here. But this is going to be confusing for people. First of all, modal sheets slide up from the bottom of the screen, they don't slide in from the right, and you can't use the left-edge swipe to get back out of here. This is really confusing for people when they see this.

Okay. Now, the fifth next major common pitfall that we have seen on Apple Watch is using the menu control for primary navigation in your app. Now, menus like this one for Messages are really good for contextual actions, like making a new message.

Or for view mode preferences, like this one for Calendar for switching the visual appearance of your schedule. But when you try to use a menu for navigation, it causes a lot of usability problems.

The main one is that people just don't know where they are in your app structure or even that they can navigate.

So for example, in a hierarchical app, that arrow there serves a really important purpose.

It lets people know about what the structure is of the app that they are in. It lets people know that they are in a hierarchical app. More than that, it lets people know they are in a child view so they can go back up to access the navigation for the app.

That's pretty important, that's a pretty fundamental thing for people to know.

Similarly, in a page-based app, those dots at the bottom of the screen tell people that they're in a page-based structure. And it tells them how many other pages there are, it tells them where they are relative to those pages. It tells them that they can swipe side to side to navigate between pages. It's a lot. It's doing a lot; right? It tells people a lot about how to interact with the app.

But if you used a menu for navigation, there would be no onscreen visual cues about how to navigate, and like I said, you wouldn't see any cues that navigation is even possible. So you might feel like the screen you are currently looking at is the only screen the app has. So it's best to stick with just straight-up hierarchy or page-based structures in your app and not try to use a menu for navigation.

Now, this is a bit of a tangent, but it's related to menus, so I thought I would mention it here. It's sort of a bonus pitfall. You don't have to pay anything extra for this, but I accept tips. So in menus, like I said. Menus are -- have a very distinct visual style to them.

The appearance of the buttons here have dark liner icons. They are situated on these filled-in lightish gray circles, and they have light labels. It's a very distinct visual appearance.

If you design your app's UI to look like this, it's going to confuse the heck out of people.

They might think that they pressed the display too hard and they are actually looking at the menu for your app, and then they realize they don't want to navigate anywhere or do any of this stuff, so they try to close this by tapping outside. But that does nothing, of course, because they are not in the menu, so they feel like your app is frozen on them. Not a good experience for people to have. Fundamentally, there's nothing wrong with having a navigation system in your app that has these large graphical icons like this, but try to do something to distinguish it from the appearance of the menu control itself.

So rather than having those dark icons, light gray background, try adding in your Global Tint color. Or rather than having the dark icons there, maybe make them white and do an outline stroke for the buttons. Or do something more even different than that. Whatever you do, try to make it distinct from the appearance of the menu control itself. Okay. So that's it for menus, and that's it for me. I actually would love to hand it over to my esteemed colleague, Rachel Roth, to take this home. Rachel? RACHEL ROTH: Thanks, Mike.

Hi, everybody.

My name is Rachel Roth, and I am the other User Experience Evangelist at Apple. So I am going to take you through the rest of this list.

On the Apple Watch, it is really important that people can quickly determine what's tappable and what's not tappable, and a common problem that we see all the time are buttons that don't look like buttons.

The Watch has its own design language, and it's not identical to iOS.

On iOS, we primarily rely on color or position on the screen to tell if something's tappable.

So when a control is placed into a toolbar or a navigation bar and it's given a different color, people can assume that it's something that they can interact with. Like here on Maps, we know that each item in the corner is tappable because of its location and its color. Now, on Apple Watch, most controls are put inside of these rounded rectangle or circular shapes, and that's because of the limited space we are dealing with. There just aren't room to have a dedicated place like a navigation bar or toolbar.

Everything aside from the status bar is in one view. So there's no dedicated place to put those controls. And it's also trickier to rely on color as a visual indication of interactivity because page titles are colored on the Apple Watch. And we do this to reinforce context and also branding.

It aids in usability because the color of the titles can help you understand what app you are in, especially if you look away because -- to see if your bus is coming and quickly look back. Here are two apps with very similar content. We have Yelp on the left, and on the right is Foursquare.

Again, both have similar content, but because Yelp has their red branded color and Foursquare is more of a pink, that page title color lets you know what app you're in. Same thing. We have Timers on the left and Runtastic Six Pack on the right. The color really helps reinforce the identity of the application. A lot of people have said they are not sure how to set that color, so that's the Global Tint color. Now, another convention that we use on iOS is we add chevrons to things that are tappable, like we do in table rows of settings and next to text labels like the developer name in the App Store. But if we put chevrons on the Apple Watch, well, they just take up too much space.

If the label for voicemail was any longer or my font size was set larger, it would cause the text to wrap or truncate.

And also, they just become noisy. You are dealing with a very compact width on the Apple Watch, so the chevrons become a distraction from the icons and the text, and that's the important information.

If you are using the rounded rectangle shapes, there's no need to add chevrons to indicate interactivity. They are going to instinctively look tappable. Now, another convention that we use on Apple Watch is to put buttons into a circle, and without the circle, these phone icons would look pretty ridiculous, and they would also seem maybe more like a status indicator or a decorative embellishment.

But the circle makes them unmistakably button-y. When you are dealing with these short interaction times and quick decisions, you really want to -- people need to be able to quickly react to something. I have a phone call. Do I want to accept or decline it? The circles help make the actions very clear.

But it's not as though rounded rectangles and circular shapes are these revolutionary new concepts. This is where there is similarity to iOS.

We use circles on the iPhone when buttons might otherwise be ambiguous.

Same with the rounded rectangles. You see them all the time with segmented controls and the Buy buttons in the App Store.

In fact, if we didn't have the rounded rectangle, that Buy button might be ambiguous, and if there's one thing we can all agree on, we want to make it really obvious how to buy apps in the App Store.

So on Apple Watch, the rounded rectangles and circles help people quickly understand what's actionable, and when you are dealing with those really brief interaction times, like Mike said, you really just have a couple seconds while someone holds their arm up before it gets tired.

Every fraction of a second counts. So you want to be sure to put anything that's tappable into a rounded rectangle or circular shape, and just as importantly, don't use these shapes for anything that's not tappable. They will look tappable and confuse people if they aren't.

Now, in iOS, we sometimes do use these shaded backgrounds to group like items together.

So it might be tempting to do something like this on the Apple Watch, but if you do, all of these things would look tappable.

And if the person using your app thinks they're tappable and they try tapping and nothing happens, they're going to assume that your app is broken. So if you have a situation like this, you are much better off using separator lines to group things together, just like we do in Stocks.

They demonstrate which items are related, and they'll also help your eye track across that horizontal list.

So make sure your buttons look like buttons, and make sure your noninteractive content doesn't. Which brings me to the next item, which is inadequate tap targets. Now, knowing what is interactive is a start, but if people can't easily tap those things, you still have a usability problem.

Designing for Touch is critically important on the Apple Watch, especially since someone might be using your app while they are in motion. So something like this might seem usable when you are in Photoshop or in Sketch. You are sitting nice and stable in your office chair, you've got a nice big monitor at your desk. And even in the simulator when you are using your mouse, this seems very easy. But once you get it on the Watch, it's going to be a problem to hit those tap targets if they aren't adequately sized.

Scrolling is so easy on the Watch. You've got the Crown. It's easy to swipe your finger. So don't be afraid to let things scroll out of view, especially if that means you can avoid truncation and make your buttons really easy to hit. Now, on the Apple Watch, you want your circular controls to be at least 80 by 80 pixels on the 42 millimeter or 75 by 75 on the 38 millimeter.

But there's nothing wrong with going bigger.

That's what Chipotle did.

The primary action, the one thing they want people to do with their Watch app is order a burrito, so they've got this nice, big button that does exactly that. I mean, there's no way you are going to have trouble tapping that button. Now, when it comes to the rectangular buttons, you absolutely should not go smaller than 53 pixels in height on the 42 millimeter or 50 pixels on the 38. But we tend to go larger everywhere throughout the system. Usually 80 pixels in height or more.

Again, bigger is better. And always be sure to extend your buttons to that full width of the canvas, even if you have a short label, because this is not going to be as easy to tap as this is, especially when you are about to step out the door to go for a walk.

Now, in some cases, you may need to have two buttons side by side, and this will still work, but you are going to have to find really short text labels.

And three side by side with text is really not a good option, even with the shortest words.

Now, if you have individual numbers or single characters or icons, you can get away with putting three side by side, but they're still going to be really close together, especially on the smaller-size watch, and this often gives people trouble tapping accurately.

Definitely don't go more than three. It's highly unlikely that more than three buttons side by side is going to be usable, and that will just frustrate people. So be generous with your tap targets because this is the one time you want to make it easy for someone to push your buttons. It's Friday afternoon. We are going for bad puns. Next I'd like to talk a little about legibility because it is so hard to use an app if you can't actually read the content it's displaying to you, and when you are looking at fonts in Photoshop or Sketch or even the simulator, it's easy to get a false sense of how legible they are. Again, you are sitting at your desk, you've got that nice big display, you are probably in some bright office lighting.

Something like this might look totally fine. But then once you get it on the Watch, it's going to look more like this.

That's not legible. Not at a glance, at arm's distance when you are moving on a train. Larger type is going to be easier to read. And you don't just want to look at this in Photoshop or Sketch or the simulator. You really need to look at your apps in context on your wrist. You need to make sure the most important content is legible when the person's going to be needing it. Can you tell the important information as you are rushing out the door to catch a bus? Or while you are actively doing crunches? How about if you are outside on a sunny day actively running? People need to quickly be able to glance and see the information that they are looking for.

Now, to optimize legibility, I strongly encourage you to use SF Compact, the system font for Apple Watch.

Custom fonts are able to be used, but even at reasonable sizes, thinner fonts just aren't going to be as legible as San Francisco is. And San Francisco was specifically designed to be the most legible font for digital display that we can make.

And I could go on and on about all the care and detail that went into crafting this typeface, but it's better if you hear it from the type team directly, and if you didn't see the session that was right before this one, I highly recommend checking out the video. It's really fantastic insight into everything that went into that typeface creation.

Now, the best way to use the system font is to use the system type styles so that you can take advantage of Dynamic Type. Dynamic Type scales when people adjust their preferred reading size.

Now, if someone changes their preferred reading size and your app doesn't adjust to match that preference, they are either going to be disappointed, or worse, they may not be able to use your app at all.

Implementing Dynamic Type is straightforward. You just need to use one of the five text styles that we have here. And then for each text setting that someone specifies, the system will adjust a number of properties to ensure optimal legibility and typographic integrity.

We adjust the size. We also adjust the leading.

So that's the vertical space between the lines of text. And we adjust the tracking, which is the space between the letters. And if you are using a custom font, you will have to handle all of these sizing adjustments manually.

Now, like I said, we do have five styles, Headline, Body, Caption 1, Caption 2, and Footnote.

It's called Footnote for a reason.

Don't be tempted to use that for every piece of text in your app just because it's the small one.

Bigger is better when it comes to everything on the Watch, especially fonts.

Now, as Mike was saying earlier, we really strive to blur the lines between the hardware and the software when it comes to Apple Watch, and nothing wrecks that faster than gratuitously bright background colors and unnecessary padding.

Suddenly the screen feels tiny, and everything is cramped into the center.

You are already dealing with a small screen. You need to use every precious pixel of that for your content. Don't waste it on padding. And bright backgrounds are the worst because the majority of the platform is on black, so you are going to get this blast of color, and you can't change the background color of the status bar, so it's always going to be black, which means that your content area is going to look even smaller.

And I also see a lot of people putting photos in the background just to kind of jazz up their app, and while this can be done well, more often than not, it's a distraction from the content.

It increases your file size because you need more images, which affects your launch times, like Mike was talking about, and it makes the text harder to read.

Again, you are dealing with these incredibly short interaction times, so you want to eliminate any friction to interaction that you can.

Fractions of seconds have never been so valuable as they are on the Watch. And while this lack of padding is very uncomfortable to look at in Photoshop, it does make me cringe, everything is going to be great when you get it to the Watch because of that hardware bezel. The bezel is the illusion of padding.

So this means you don't need to add any in. You can use all of the screen real estate for content and controls, and you will have less truncation and text wrapping that way. And like I mentioned a few minutes ago, buttons that go edge to edge are going to be much easier to tap.

If your app has a black background, it's going to blend seamlessly into that bezel and feel at home on the hardware.

It will be so much easier for people to focus on your content of your app. But this doesn't mean you have to make your app boring.

There are so many ways to carry over branding and add personality without relying on a colored background.

I've got a few great examples for you. Hailo is one, a popular taxi app in the UK. They have this recognizable bright yellow color and cheery car icon you see throughout all of their app.

Citymapper relies on their green color for branding recognition.

They have the Citymapper face that they use as loading graphics, but most importantly, they carry over their cheeky sense of humor that they are known for. Next time you guys need directions someplace, I highly recommend checking out the teleport option. Rules! is a really fun memory game, and they took the background texture that they use throughout their iPhone app, and they've turned that into the button texture here on Apple Watch, and they also have these really adorable characters and charming animations, so there's no way that you could call this app boring or confuse it with some other app.

So there's no need to do anything like this when you have so many better options available to you.

So avoid those bright backgrounds for embellishment, and never inset your content. Let the hardware bezel take care of that for you.

But really, none of these things matter if people can't find your app in the first place.

Now, unlike iOS, Apple Watch icons aren't labeled. So it's especially important that people can find your app just from the icon.

And as you've undoubtedly noticed, the Watch App icons are circular and much, much smaller.

So that can present some design challenges as well. Now, most of these Watch App icons would be familiar to you if you have their iPhone apps on your phone.

Making an exact match of your Apple Watch icon to your iOS icon is the best way to help people find it on the Watch. Citymapper and Nike+ Running and Procreate all directly translated their App Icons for the Apple Watch, and that's because they already had very simple shapes that would read well in that circular format.

But I know it's not always that easy, so I have some techniques you can try if you need to make modifications to get your App icon to read well in a small circle and still be recognizable.

The first thing to do, really, is just simplify as much as possible. So what can be removed and still be recognizable as your brand in your app? Start with text. Text is going to be particularly tough at such small sizes. So can you eliminate it altogether? That's what Yelp did.

Their burst icon and their signature red color is enough to make the app recognizable. So start by removing the text, or if you absolutely can't, look for an abbreviation. And if you have a lot of detail in your icon, consider simplifying it because that will help it be much easier to read at those small sizes. Take the Twitterific bird, which many of us recognize.

Just scaling it down and masking it into a circle wasn't going to work very well on the Apple Watch. The white space becomes awkward, and the bird is just not as recognizable this way. So the Iconfactory team redrew the bird to work better in the small circular format.

Now he is facing you dead on, and a lot of the features have been simplified or removed. It's no longer got nostrils on the beak, and the pupils and the eyebrows are much simpler graphically rendered.

Complex shapes with a lot of detail will be harder it see at small sizes, so do everything you can to simplify. Now, unless you have a strong justification for moving away from your current color palette, you want to retain your current color scheme and overall visual style.

Color is a very strong branding element, and that will be very important in helping people find your App icon. What if messages were suddenly a different color? You would probably think this is a different app altogether, or a beta version, or a trial version.

So here you can see how Fanatee simplified the App icon for their game, Letter Zap.

They removed the text, which would have been impossible to read at the small size on the Watch, and enlarged the lightning bolt, but most importantly, they retained that green and gold color scheme, which is what makes it so recognizable.

So even though it might seem scary to remove text or change that icon that you have been using for so long, as long as you retain the overall color and visual style of your App icon, it's still going to be recognizable.

Now, as Mike said earlier, it is not a goal to offer all the functionality of your iPhone app onto the Watch, so sometimes using an identical App icon may not be appropriate.

Your Watch app might offer complementary functions to your iPhone, so maybe a complementary Watch App icon concept might be better.

As we were talking about earlier, the Camera app on the iPhone offers a ton of functionality. You can take pictures, edit them, share them.

But on the Watch, it really just acts as a remote for the shutter button.

So we could have taken this App icon and just put it in a circle and called it done, but it didn't feel right. Instead, we came up with a complementary concept.

It's still a recognizable Camera icon, but we've simplified some of the texture, retained the color scheme, and really emphasized the shutter button because that's what this app does for you. It presses the shutter button. Another great example of this is Sky Guide.

Now, masking their icon into a circle just doesn't read very well. The composition is off, and it doesn't exactly feel right because of what the app does for you. On the iPhone, Sky Guide is all about telling you, What am I looking at? What am I seeing right now in the sky? But on the Watch, it's alerting you when there's about to be an event in your area, like the International Space Station might be about to fly overhead.

So they came up with a complementary concept for their App icon, and it looks great in a circle and implies an astronomical event.

But because they're using similar color scheme and visual style, the relationship is very clear.

So if you are struggling how to adapt your iOS icon for Apple Watch, try some of these approaches.

Because none of these Apple Watch icons are literally the same as their iOS counterparts, but the resemblance is clear, and as a result, the apps are easy to find.

And as I've said many times, it is not necessary for your Watch and iOS icons to be identical twins, but you do want them to look like siblings. So that takes us to the end of our list, and as you're working on your Watch apps, I hope this will be a handy tool for you so you can avoid some of those common usability pitfalls.

It really has been amazing for us to see how many great Watch apps are out there already, and we're so excited to see what you guys come up with for watchOS 2.

We had a ton of great design sessions this week, and the WatchKit Tips and Tricks, again, from this morning was particularly fantastic. And loads of information online, especially the Designing Great Apps page.

It has been a tremendous week. I hope you guys have had as much fun as we have. There's still a few more hours of labs left, so go take full advantage of that, and we'll see you next year. Thank you.

[Applause]