Get essential design guidance for creating Apple Watch apps that support quick and efficient interaction, make accessing features and information more convenient, and compliment their companion iOS apps. Learn key tips about information architecture, layout, typography, color and app icon design that will make your app easy to use, beautiful and delightful.
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?
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 --
[Laughter] -- 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
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
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
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 ROTH: Thanks, Mike.
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
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.
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
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
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.
[Laughter] 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
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.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.