On Apple Watch’s Physical Controls

A recent post by Craig Hockenberry (via Daring Fireball) regarding his use of the watch while swimming revealed that Craig has some of the same questions about the use of physical interactions with the watch as I do, so I thought that this would be a good time to publish my own thoughts on how the physical controls link to the functionality of the watch.

Dimensions of interaction

While my overall impression of the Apple Watch is very positive, I do have a couple of quibbles with the way it requires me to interact with it. Before we go into the specific areas that trouble me, let’s have a quick look at the different dimensions of physical interaction.

Firstly, there are the controls. These are the parts of the watch that I physically touch in order to access the functionality of the device. The Apple Watch has 4 controls; the button, the crown1, the screen and the accelerometer. For the purposes of this post, we’ll exclude the accelerometer. Mainly because I think that Apple has already nailed the functionality there. In terms of UI, the accelerometer does one thing (wakes the watch) and does it well, so I don’t think there’s much more to discuss.

Next, there are actions. Actions are how I use each of the controls; press, tap, double-tap, force touch, etc. There are different actions for different control types but some are very similar in nature. We can assume, for example, that a single press of the button is more or less equal to a single press of the crown.

Finally, there’s context. If I press the button from the watch face, the software can perform differently than when I press it inside an app.

Sidenote: There’s actually a 4th dimension and that is combination; using more than one control at the same time. Again, I’m going to exclude combinations for the purpose of this post. There are really only 2 controls you can use together on the watch and Apple has already put this to good use.

While 3 controls might not seem like much for such a complex device, when multiplied by actions and context, a huge range of options are available to the interaction designers. However, not all of these options are equal when it comes to performing a specific task.

So far, I’ve spoken about what the watch is able to do. We need to think about what we require it to do.

User requirements

We all like to make lists (mentally, or publicly) of what Apple needs to do to satisfy our craving for functionality. That’s not what I’m talking about here. I’m going to limit our requirements to what the watch can actually do at this time. Like interactions, our requirements have multiple dimensions.

First, there’s intent. This is what we want to do with the device. We want to open an app. We want to start a workout to track an outdoor run with the aim of burning 500 calories.

Next, there’s physical context. This is where things get a little tricky. If I’m sitting at my desk, pretty much everything is fair game. I have access to all the buttons on my computer and I can take my time pressing them if I want. Now, what if I’m on public transport and I’m holding on with one hand and using my device in the other? Or if I’m running in a busy park and can’t look at my device for more than a split second? In these situations, physical context reveals itself to be crucial to how we use our devices. 2

Then, there’s frequency. How often I access functionality is a big driver for how I access it. It often makes sense to make the most frequently used functions the most accessible. However, this is something that UI designers often give more importance than necessary. Just because we use a function less frequently, doesn’t mean it shouldn’t be accessed in the most efficient way. The least frequently performed action during a sky dive is the deployment of the parachute. We definitely want the control for that to be the easiest to use.

This brings us, finally, to urgency. If I need to access functionality, can I afford to step through a couple of options or do I need to action it immediately?

Putting it all together

Matching interactions with requirements is a crucial design artefact that can make or break a device’s usability. It’s something that Apple does exceptionally well. When executed correctly, the device is a pleasure to use. At the very least, the interactions become invisible. When done badly, the interactions become jarring or even prevent us from using the device.

Let’s have a look at a couple of the interactions.

We’ll start off with my current pet hate, the force touch (action) on the screen (control) while the watch face is showing (context). This opens up a really nice piece of functionality in the watch; the customisation of the face. I really like that this functionality exists and I really like the UI of the configuration manager. So, why is this my go-to example of a bad match between interaction and requirement?

My issue is that this is prime interaction real-estate. It’s the biggest control on the device, the action is really simple to use (and remember) and the chances of you being in the correct context to use it are really high; it’s available to you pretty much every time you raise your wrist.3 Why, then, would you assign this interaction to functionality that is not urgent, infrequently used and requires full concentration and both hands to complete your intended action? It seems like a missed opportunity. The watch face configuration could easily have been accessed from the Settings app (on the watch or the phone).

The next interaction, again prime real-estate, is the single button press (from most contexts). Now, admittedly, I’m not a big user of Friends functionality. In fact, I haven’t even configured any friends yet. I just don’t use my watch to initiate contact. Therefore, I can accept that this one of the cases where the button functionality is for the majority of users but not for me. My issue here is that the functionality doesn’t change when the context does. As Craig points out:

If you feel the need to text someone during a workout, you need to re-evaluate your strategy for good health.

I can’t think of a good reason for a single button press in the context of a workout to access the Friends app. Taking a cue from Craig (but disagreeing very slightly4), if we take the urgency and physical context requirements into account, assigning the single button press to trigger a lap time seems like a far more useful match.


Although I’ve highlighted only two of the matches between interactions and requirements here, (specifically ones that I don’t like), the UX of the watch is incredible. I’m getting a lot out of my watch and these minor niggles don’t really detract from that.

Matching interactions with requirements is a tricky business, especially with a new category of device. We have little history to learn from. What works well for the limited number of people involved in the creation and testing of the Apple Watch might not work well with some, many or all of the real-world users.

In a non-Apple world, there’s a possibility that we’d have some control over the interactions. A frequent runner might choose to trigger the start of a workout using the force-touch. A commuter might use the same interaction to play Beats 1.

In the meantime, WatchOS evolves. There’s already a new generation of apps on the horizon and I get the feeling we’ve only scratched the surface of what’s possible.

  1. 1 – Yes, I call it the crown, not the digital crown. It’s the only crown on the watch. Everything about the watch is digital. The word digital in this case is superfluous.
  2. 2 – At this level, we’re talking about physical context causing situational inconvenience. What if I don’t have the use of my eyes or hands at all? That piece of key functionality that requires two hands or is buried deep in the menu structure is now very difficult to use.
  3. 3 – The exceptional cases being when you raise your wrist soon after interacting with the watch and during a workout
  4. 4 – In my head, you need a simpler interaction during the exercise than you do when you’ve finished. Therefore, one click for a lap and two clicks to end the exercise.