Apple's Design Mistake
The dissection of an iPhone detail reveals the philosophy of the world's highest market capitalization company.
Reading time: 5-10 minutes
Today’s article is about a surprising design decision that can be seen on Apple’s iPhone. From this detail, we will try to extract some wider observations that may not be obvious at first sight.
You don’t need to be a design expert to follow the analysis.
The Alarm and the Timer
On the iPhone, two different features share a screen. The Alarm feature, which rings when a specific time has arrived, and the Timer feature, which rings when a chosen length of time has passed, show the same screen when the bell rings.
In reality, those are two different screens, with small differences that will be the center of our attention today. Let’s play seven differences.
From a visual standpoint, the two screens are identical:
Feature name (huge letters, no background);
Primary button (big, orange background);
Secondary button (small, grey background).
From a functionality standpoint, the screens are slightly different:
Both have a Stop button, that turns the feature off. The phone stops ringing and won’t ring again;
The Alarm has a Snooze button, which stops the bell but sets it to ring again in a few minutes;
The Timer has a Repeat button, which also stops the bell, but starts the countdown back again.
From a hierarchy standpoint, the two screens make opposite choices:
For the Alarm, Snooze as primary, Stop as secondary
For the Timer, Stop as primary, Repeat as secondary
The Confusion Of A User
Those two screens, similar yet different, provoked the following comment from Rémi Bardoux, Chief Product Officer at Groupe Se Loger:
Yesterday, I failed the cooking of my pasta.
It was 8:21pm when I tasted them. Not al dente yet, so I wanted to add 2 more minutes of boiling. Out of habit, I pressed my "usual" snooze button (the one I use 36 times every morning)… which stopped the timer and never made it ring again!
The only notification I got was the sound of water falling on the ground, at 8:28pm. My pasta was not al dente anymore...
On one screen, the big orange button makes you repeat the alarm, on the other, you stop the alarm! Why Apple is using two opposite interfaces for the Alarm & the Timer?!
Why The Inconsistency, Apple?
The problem described seems to be a consistency issue — the function of the orange button varies from one screen to another.
Consistency is the quality of staying the same over time. In design, consistency is a big deal, because it plays a major role in helping people learn how to use something, through repetition.
By placing the Stop function at different places on each screen, Apple brought inconsistency and confusion. How could they make such a mistake?
According to you, is it because:
Apple designers just didn’t think this through?
Different designers worked on those two screens, and they didn’t agree on a consistent approach?
Behind the apparent confusion, there’s actually a strong rationale behind that choice?
I would bet on answer 3.
To explain why, I’m going to share two fundamental design principles I’ve discovered over the years: First Use Case, and Context Over Consistency — yes, I’ll refrain from using acronyms.
Two Principles To The Rescue
The First Use Case principle states the following:
A screen should be optimized for what most people want to do with it, most of the time.
In particular, this principle encourages designers to not let infrequent use cases pollute a screen with unnecessary complexity.
As for the Context Over Consistency principle, it goes like this:
The context of usage of a screen is more important than its consistency with other screens.
This principle opens the door to exceptions regarding the holy rule of consistency. If the context of a particular screen makes it absurd to be consistent with other screen, it’s OK to be inconsistent.
Now, let’s apply those principles to the Alarm and Timer screens.
For the Alarm, the First Use Case seems to be: I’m sleeping, and I want to wake up. In this context, it makes a lot of sense to make Snooze the primary button. It is the function that is the most likely to help you wake up.
For the Timer, the First Use Case seems to be: I’m cooking, and I want to check whether a dish is ready. In this context, displaying the Stop button more prominently sounds about right. Once you checked the dish, you can decide to either stop the cooking, or set a new timer.
The situation described by Rémi Bardoux is actually a rather unusual one — wanting to extend the cooking time of exactly the same amount of time he had initially set. It may happen, but it is unlikely to be what most people want to do, most of the time.
With those principles in mind, it seems like Apple made the right design decision. They optimized each screen for its most common context of usage.
Exploring Alternative Solutions
Another way to understand the quality of this design decision is to explore alternatives. What other solutions can you think of?
Let’s explore a few of them, and analyze their possible consequences.
Make the primary button be Stop in each screens. In theory, this would solve the consistency problem, and address the situation described by our friend Rémi Bardoux. In practice, it would be a perfect example of deteriorating the quality of the first use case by trying to better address a secondary use case.
Remove the Repeat button from the Timer. Would this solution be sufficient to reduce the hypothetical confusion? Hard to believe, given the visual prominence of the primary button. Plus, for the secondary use cases that you could imagine in the context of sports (like a Tabata workout), you’d lose a useful feature.
Place the two buttons at the same level. The idea here would be to remove the notion of primary/secondary buttons, and have both buttons look the same. This would allow to place the Stop feature in the same place on both screens. Smart decision, right? In fact, it would be more the absence of a decision. The lack of hierarchy would make the screen less intuitive for most people, putting on them the burden to figure out which button to press.
Create a visually different screen for the Timer. If the visual consistency of the two screens is causing the confusion, why not make the two screens totally different? While this could fix the problem, such an approach doesn’t scale. The iPhone would be a mess to learn how to use if each screen was made to look unique.
Let people choose their primary button. Apple could add the ability for users to customize these screens based on their preferences. But it wouldn’t remove the need for Apple to define the best default screen that will be presented first — and probably never touched by the vast majority of users.
Automatically change the primary button based on the user’s behavior. For example, if I always press Repeat on the Timer, then the Repeat button becomes the primary button. While this idea sounds nice, it would be hard to implement in a way that doesn’t cause more problem than it solves.
All those alternatives have interesting starting points, but trigger equally important concerns. The beauty of Apple’s design solution is that it relies on two principles (First Use Case, Context Over Consistency) and doesn’t deviate from them.
Lessons From This Analysis
To conclude this analysis, we could summarize the approach followed in the form of three questions that anyone working on a screen could ask themselves.
The question to start with is about the essence of the moment. If you could observe every person on Earth going through such a situation, what is the most frequent pattern you would see? This will be your first use case, and should inform all your design decisions.
Then, the consistency question should come in. How can you leverage what users are already familiar with, in order to help them accomplish what they want? This means distinguishing where consistency would be an asset, and where it would add confusion.
The last question should be around the secondary use cases. Are there other use cases you could address without worsening the first use case experience? The more ferociously you prioritize the main problem you choose to address, the more you expose yourself to criticism regarding the problems that you choose to not optimize for. This may be difficult for user-centered designers, trained to look for, listen to and care about people’s frustrations, which could lead them to take more into account the loud voice of a few unsatisfied users than the seamless experience of the silently satisfied majority.
As a closing remark, it’s interesting to remember that there are close to one billion active iPhones in the world. In other words, when Apple is consciously deciding to not address a secondary use case, it may frustrate millions of people. Making bold design decisions in that context requires intellectual rigor and extraordinary courage that most companies don’t possess.
What if this was the secret ingredient of Apple’s success?
Ressources To Dig Further
About the First Use Case principle:
It was coined by Tristan Charvillat and myself, while we were working at PayPal, in 2011;
We made a short video to explain the approach, in 2013;
We also gave a live conference about it in 2016, covering the topic in the second half (only available in French).
About the Context Over Consistency principle:
The first time I heard about it was through the words of Ryan Singer, in 2005;
Basecamp, the company he was working at, integrated the idea in their book Getting Real, published in 2006;
Jared Spool wrote an interesting piece about replacing the obsession for consistency with something more user-centric.
About Apple’s obsession for simplicity:
Ken Segall wrote the ultimate book on that topic, called Insanely Simple: The Obsession That Drives Apple's Success. I cannot recommend it enough.
Every two weeks, I write an article to explain how the mind works, usually through a comparison that everyone can relate to.
You can subscribe to receive those articles in your mailbox — just enter your email below.
Thank you to Rémi Bardoux for inspiring the idea of this article, to Tristan for the collaboration on the First Use Case concept, to Ryan Singer and Jason Fried for being timeless mentors, and to Ayça Sevkal-Guyot, Léa Mendes Da Silva, Marie Petit, Eliette Guyot, Nara Braga Cavalcante de Farias, Pierre Fournier, Audrey Kolski, Nicolas Duval, and Alexis Fogel, for reading early drafts and suggesting many of the alternative design solutions.