With the upcoming launch of Apple’s newest and shiniest product, the Apple Watch (err, WATCH) there are many designers out there itching to get a feel for the newest toy to come out of Cupertino. There are some new ways to interact with the device; like Apple’s force touch menu and digital crown, as well as many UI elements you may already be familiar with like buttons, text styles, and switches, oh my!
Before exploring UI elements present on the Apple Watch let’s first cover some of the basics that you should keep in mind when designing for this new device. At the time of writing the Apple Watch is yet to be released, so if you have any tips, comments or corrections please let me know on Twitter or in the comments.
Firstly, the Apple Watch is physically attached to the user. Be mindful of this connection and how it will make your users feel when interacting with the UI.
What do you think Apple’s intentions are towards their users’ emotions with the Apple Watch? If this commercial is consistent with Apple’s content strategy, then the emotions it conveys are happiness, excitement, awe, and wonder, all while conveying a sense of personalization with the use of different watch bands, colors, and watch faces. How might you convey those same feelings with the design of your watch app? How does the fact that the watch is attached to the user change the way the user might feel about the design of your app?
The Apple Watch isn’t as powerful as your new smartphone. When designing for web and mobile I’m sometimes guilty of using a pretty image over a smaller one. In the case of the Apple Watch we’re reminded to keep things as lightweight as possible, because those extra kilobytes really do make a difference.
The crappiest devices on the web (low end phones) have similar specs to the coolest new tech (smart watches). Design for everyone, always.
— Todd Parker (@toddmparker) March 19, 2015
Users do not want a slow and sluggish experience. The use of larger images and animations will not only create a poor user experience, it will also likely get your app rejected when the time comes to submit it to Apple.
— Henry Ton (@archtrainer) April 3, 2015
Ask yourself, “are my animations really necessary?” Animations are bad if they are causing a delay, regardless of their enhancing qualities. Remember you are building something for a computer the size of a postage stamp which also has to wirelessly stream data from the phone. A bottleneck exists there.
“If you measure interactions with your iOS app in minutes, you can expect interactions with your WatchKit app to be measured in seconds. So keep interactions brief and interfaces simple.” – Apple Watch Human Interface Guidelines
The use of color and typography is important in the branding of your application, but there are some key considerations to keep in mind.
“Color helps provide visual continuity and branding for your app.” – Apple Watch Human Interface Guidelines
By all means use custom fonts, but be aware that the system font was designed to work well on this new device.
“Above all, text must be legible. If users can’t read the words in your app, it doesn’t matter how beautiful the typography is.” – Apple Watch Human Interface Guidelines
Benefits of the system font (San Francisco) include:
Text styles are semantic descriptions of the intended uses for your fonts. Examples are things like Headline, Body etc. You are probably familiar with the HTML equivalents of
<body> and the like. If you use the built-in text styles, you get free Dynamic Type support which responds automatically to users’ accessibility preferences. If you use custom fonts, you must do some work to adopt the feature.
The Apple Watch is smaller than a smart phone, obviously. All of the space available needs to be used intelligently to make the interactions your users will be making as pleasant as possible. Keep your buttons large so it’s easy to interact with them. Consider ways to use the force touch menu for additional options. Resist the temptation to display your logo in the app, there are other ways to brand your app through the use of colors and imagery that is meaningful and contextual.
“Space on Apple Watch is at a premium, and every occurrence of a logo takes space away from the content that users want to see.” – Apple Watch Human Interface Guidelines
The Apple Watch has a bezel around the edges which adds physical padding to your designs. You therefore needn’t add margins to the edges of your screens.
It looks a bit odd at first when developing in Xcode, as you won’t see this padding at the edges, but keep it in mind for your designs:
Apps display the same interface on both sizes of the Apple Watch, (38mm and 42mm) so by using relative units you can allow your items to grow and shrink to fill the available space on both sizes. The screen is always in portrait mode: the height is greater than the width.
|Device Size||Width (in pixels)||Height (in pixels)|
In WatchKit apps you’ll encounter two completely different navigation patterns:
“Hierarchical” is a navigation pattern which involves a vertical scrolling list to allow the user to make one selection (by tapping) per screen until they reach their desired destination.
“Page based” is a horizontal scrolling navigation style which indicates the current page by a series of dots along the bottom of the watch screen.
You can’t combine these two systems into the same app but you can display “modal sheets” regardless of your navigation type.
You can think of a modal sheet as a card that gives the user a way to complete a task. Modal sheets contain a single screen or multiple screens displayed in a page-based layout. The only difference between the two is the addition of dot indicators at the bottom of the page-based interface.
Don’t add a close button to your modal sheet, as there is one in the top left of the screen by default. It is always white, though you can change the text from close to cancel or something else to add more meaning. A user can also close a modal sheet by swiping from the left of the screen.
Any buttons you add on your modal sheets should perform the action they are designed for and close the modal sheet, so the user doesn’t have to perform that extra step. Apple suggests you don’t add a second modal interface from the initial one–should you do so it could be cause for rejection upon app submission. If Apple warns against something it is usually best to listen unless you have a very good reason not to.
There may be more ways for a user to interact with your app in future generations (such as multi touch and new gestures), but for now these are the only ways.
The Glance Interface is described by Apple as “a supplemental way for the user to view important information from your app”. Think of information you may need quickly on one screen, like the time. Does your app have information the user will want to look at frequently? Consider building a “glance” to display that information.
Glances are built from a series of predefined templates for the upper and lower half of the screen. Glances are not scrollable by the user and will open the app to the appropriate screen when the user taps on one. Glances are optional and are not required.
Groups are containers for objects in your app, you can think of them as being a bit like divs in html. Groups have a default padding that you can change or remove if you wish. They have no default appearance, but have attributes for setting position, corner radius, size, margins and background. You can set a group to layout items horizontally or vertically and you can nest groups inside other groups to create more sophisticated layouts.
Here are some of the upper and lower group templates for the glance screen:
Notifications are displayed to the user in two different ways: a short-look and a long-look.
These tell the user which app is notifying them and gives a headline. If the user lowers their wrist quickly or doesn’t tap, the notification is dismissed. The user doesn’t have to manually interact with the notification to remove it. The design of the short-look notification is template-based and contains the app icon, app name and a title string. Keep your title strings as short and meaningful as possible.
These provide more detail about the notification and are more customizable in their appearance. The basic structure is the same for all apps and includes a sash at the top which displays the app’s icon and name, your app’s custom content, up to four action buttons and, finally, a dismiss button at the bottom.
With these basics held firmly in your mind, let’s explore the different elements of the Apple Watch’s User Interface.
“As you design your app’s graphical elements, remember that each custom element should look good and function well by itself, but it should also look like it belongs with the other elements in the app, whether they’re custom or standard.” – Apple Watch Human Interface Guidelines
Dynamic animations have to be transferred from the iPhone leading to an inevitable delay. A watch app might been rejected due to heavy reliance on animations, so use them only to communicate status and provide feedback to the user. Gratuitous use of animations is not recommended (even if the animation is of a hilariously life-like dancing baby). Store pre-rendered animations using a sequence of static images in your WatchKit app bundle so that they can be presented quickly to the user instead of transferred from the phone.
Use icons instead of text for buttons placed side-by-side and never have more than three next to each other (Apple says in one instance not to use more than two buttons next to each other, and in another instance not to use more than three.)
This may sound obvious, but remember the Watch screens are small so keep your buttons as large as possible–don’t make it difficult for users to tap on a button. Buttons can have an image or color set for the background, as well as a different color for the text. They can contain a label or group object and will have rounded corners (the default corner radius being 6 points).
The force touch menu displays the current screen’s optional context menu (if one is set) with up to four actions. It will display the actions from top to bottom, left to right, depending on the order they are added to the menu. They do not scroll.
Menu actions (buttons) require an image and a label. The image should be line art and a single color with a transparent background. Use line weights that are appropriate for the device size and the complexity of the icon, between 4px and 9px according to Apple.
Remember the force touch context menu, as this is a new and exciting way to interact with the device. Instead of adding extra buttons to your interface, consider using the force touch context menu.
Icons are png circles. You can create them as indexed colors to save space, 24 bit and no transparency. Icons do not have text on them on the watch home screen.
Download this Apple Watch icon template for use in your own projects.
Icon sizes for a WatchKit app on Apple Watch:
|Asset||38mm Watch (in pixels)||42mm Watch (in pixels)|
|Notification Center icon||48 x 48||55 x 55|
|Long-Look notification icon||80 x 80||88 x 88|
|Home Screen icon||80 x 80||80 x 80|
|Short-Look icon||172 x 172||196 x 196|
Icon sizes for use by Apple Watch app on iPhone:
|App Icon||58 x 58||87 x 87|
Use one image for all screen sizes. Speed and efficiency are extremely important, so compress your images as much as possible. Try saving your pngs with indexed color on a solid black background instead of on a transparent background. Create all image assets as @2x resources; there is no need to create non-Retina images.
Maps are static screenshots of a location and are not interactive. Tapping on a map takes the user to the map app.
A label is a fancy way of saying “a static string of text”. It doesn’t allow for direct user interaction, though it can be updated programatically and can span multiple lines.
The separator is a simple, yet valuable UI element: a line for separating content.
Sliders let users make adjustments by tapping the images to the left and right. If you do not provide images the defaults are a plus (+) and minus (-)
Switches give your user a way to specify one of two options. On or off, yes or no, etc. Stylistically they’ll be familiar to you from iOS, and they always include a label.
A table presents rows of data in a single column that the user can vertically scroll through. Keep tables smaller than 20 rows, as more than that is difficult to scroll through. If you have more than 20 rows you can give the user the option to load more. Tables resize dynamically based on the number of rows they contain. As a result, tables ignore any height restrictions placed on them by groups. Apple recommends that you do not embed tables inside groups.
Apple’s Watch is an exciting new platform that will continue to evolve as designers and developers play with it and build amazing new experiences. The ideas involved with a device that is attached to the user and can gather heart rate and other information will continue to evolve. If you have new ideas on how best to work with and create interesting new interactions with these systems let us know!