How can we help?

Design? Check. Strategy? Check. Bulletproof code? Check! People who can manage it in an agile and efficient manner? Check. Someone to help you create your next big product? Of course.


- 1201 18th St. Suite 250, Denver, CO 80202

Grand Rapids

- 125 Ottawa Ave NW Suite 270, Grand Rapids, MI 49503


BLOG:Apple Watch: Questions, Answers and Speculation

Apple Watch: Questions, Answers and Speculation

With Apple’s release of the latest Human Interface Guidelines, we’ve gained new insight into the workings of the Apple Watch and how apps may work with this new piece of hardware. This has also spawned a new wave of questions.

Q: How can companies (and their apps) differentiate when the UI for the watch is so prescriptive and so many apps will look the same?

This is a great question, and the main answer that I can come up with is, you’re not supposed to. Apps rarely differentiate solely with glitzy features, but instead, strong and lasting apps seperate themselves from the pack with how much utility they provide to the user.

The Apple Watch UI is very prescriptive , the app navigation within the watch is direct and simple. Given the very small real estate available, user frustration could become very high when forced to deal with new and unique navigation methods. According to the Human Interface Guidelines (HIG) that Apple put out recently, all apps will have either a hierarchical navigation or a page-based swipe left to right navigation.

My speculation: I don’t think the Apple Watch is another app ecosystem. When it was first unveiled, many developers and designers started thinking about what app they could design for the Apple Watch - this is not the right mindset. When Apple released the iPhone 6, good designers didn’t ask, _What app could I design that will make use of the larger screen size? _Instead, they started to think about how they would be able to adapt their apps to work with the larger phone. This is myapproach to the Apple Watch - rather than thinking about what I can design that will require use of the watch as much as possible, I’m thinking about how can the applications I’m designing make use of this new peripheral? What content can I send over to the watch that is important and relevant to the user?

The HIG stated that the apps will run off of your phone and content will be streamed over to the watch, meaning the watch is dependent on co-use with your iPhone and you’re not actually installing any native apps on to the watch itself. The watch is simply an external display device, with limited content, meant to drive notifications to the user so they don’t need to fish out their phone to discover what the latest chime indicated. Being that the watch is not a stand alone device, it’s important to think of it as just another display, another device, or protocol, that you use to add value to the user.

The value of your app and how you differentiate it is the same as it was before the watch came out, utility. Make a good app that services user needs and delivers content in a quick and intuitive manner. The watch is offering an opportunity to deliver the most important information to the user’s wrist - don’t rely on whiz-bang styles, instead focus on what can your app provide to the user’s wrist that creates more utility than the same content on the phone.

Q: Wait, does this mean that without the iPhone, the watch is “Bricked”?

While there’s speculation as to whether or not the watch will be useless without an accompaning iPhone, the watch will still do a number of things with it’s own battery supply. There will be a small number of “built-in” apps on the watch that run natively. The watch should still work as a time-telling watch, but it likely won’t update dynamically to the user’s location and time zone the way the iPhone does. Additionally, the accelerometer should still work as well as the heartbeat sensor.

My speculation: My feeling is that similar to how the stocks app, weather app, photo stream etc., all require a data connection to operate on the iPhone, the data on the watch would still not function correctly without a paired phone. My hope is that some apps, like Voice Memo, Notes, and Passbook will run even if the iPhone runs out of power, but I’m not betting on it. Being that non-native apps are run from the phone, and all messaging, data, and GPS information is also passed from the phone, the Apple Watch, without an iPhone, will likely be just a watch.

Q: What can you do with the pre-packaged animations? Apple recommends using pre-rendered animations. What does that mean for app developers and designers?

Let’s start off by talking about two different ways you can animate content. First is pre-rendered animation, where you have an image of each frame of the animation and when you show those frames quickly, one after the other, it looks as though the content is moving across the screen. This form of animation is tried and true from old Disney movies, to flip books, etc. In a more modern development, this is also called sprite animation, where you can have clusters of these mini-movies on the screen at once. Lots of browser-based games use this kind of animation.


Another form of animation is known as keyframe animation, where, rather than drawing a frame for each step in the animation, you instead send instructions to the computer to have it move an asset from one position to another. The instructions tell the computer where an asset should start and end and how long it should take it to get there. This type of animation is commonly used in modern user interfaces. CSS3, HTML5 and Javascript are all used to define what assets on the screen should do given various user inputs.


The HIG states that you should use pre-rendered animations using a sequence of static image, ordered in an array and streamed over to the watch rather than having an animation that uses WatchKit extensions and animates the asset using code or in theory, keyframe animations. This is a shift away from how animation has been done in recent years. In terms of memory and bandwidth, keyframe and dynamic animations are preferable over having separate files for every visual possibility that an app could display. Instead, you can simply tell an asset how it should animate based on user input.

Apple is recommending we don’t use this method though, that instead, we pre-render these animations and include them as part of the app. This could result in increased size of apps, and it certainly has an effect on development efforts - developers potentially needing designers to render out these animations in bulk rather than writing the animation scripts themselves. Duplication of efforts could also be a result, as animations that are made for the watch display are rendered out in advance and other animations done in the iPhone app itself are done dynamically.

My speculation: My guess is that the watch will accept a “dump” of data from the phone when the app powers up (either a query from the watch to the phone or a push from the phone to the watch). Over a bluetooth 4.0 connection, we can transfer a large amount of assets to the watch for immediate use, but in order to conserve the life of a very small battery (in comparison to a smart phone’s battery ) the watch likely has fairly limited processing power. So while storage and bandwidth are in surplus, processing power is the bottleneck we have to deal with. If you can load large numbers of simple assets over to the watch and have them play out rather than reach back and forth for the rendered assets over on the phone, it should create a faster and more seamless experience for the user. My feeling is that this doesn’t just apply to animations, but also to photos, video and other assets, I think the watch will receive a large push of assets and then page through them locally.

Q: How should I use typography? How does dynamic typography impact us?

To start, the HIG has a lot to say about typography: that designers should use the font San Francisco, that we ought to use high contrast colors, and a black background. The HIG also specifies a dynamic topography setting, which gives the watch permission to scale the text and spacing as it sees fit. Why are the recommendations so restrictive, and why does Apple think we can’t scale our own type? Because Apple knows this is a new kind of device, and one that’s smaller than we’re used to designing for. Dynamic typography is meant to help smooth the transition as we all learn to deal with smaller interfaces.

Let’s dig into the dimensions of the watch. Paul Sprangers has done some nice deductive measuring of the various Apple Watch samples and determined that the size of the 42mm Apple Watch display will be 24.3mm X 30.5mm. With what we know about the pixel dimensions of the display from the HIG, we can deduce that the pixel density of the screen would be 325ppi.

My speculation: Based on the given information, my predictions for the physical size of the watch displays will be:

38mm: 21.26mm X 25.57mm (272px X 340px) @ 325ppi 42mm: 24.3mm X 30.5mm (312px X 390px) @ 325ppi


The physical size of a watch face like this is going to be much smaller than it appears here on a computer screen.

Why am I talking about the size of the watch? Because designers have been used to working with sizes that are much larger than the tiny Apple Watch. Using Apple’s above example the date display on the watch is actually 1.3mm tall, the numbers on the sub seconds dials are.9mm tall, and this is on the larger variant. On the smaller 38mm watch, the size of the characters drops to 1.1 and .7mm. Typography and readability will be one of the major challenges when designing for the Apple Watch.

Dynamic typography will provide some assistance, but it’s important to test if something will be readable at a glance, or if the watch needs to be moved closer to the face in order to read the display.

Want to learn more about designers should consider when designing for the Apple Watch? Check out our Director of User Experience, Joe Johnston’s blog on 5 Things to Know When Designing for the Apple Watch.