I love my iPhone, and I think that Apple really knows how to connect with consumers. They impress me with the way they often anticipate my needs, and with the high level of intuition that characterizes many of their interfaces. So, on the rare occasion that I come across a design flaw in an Apple product, I see it as a good learning opportunity because if Apple fell prey to it, it’s likely I will too.
I mostly use my iPhone for texting and phone calls. Emails next, then apps. I very rarely play games, watch videos, or listen to music. A little googling told me that many people report that they also use their iPhones for communications first, entertainment second.
Even more important than my usage habits is my behavior. I actually answer most incoming calls. To do this, I “slide to answer” by running my thumb from left to right. This unlocks the iPhone and answers the call. This is my mental model for "taking a call", honed over years of iPhone use.
When I am done, the “slide to answer” strip has been replaced by a red “End” strip that I tap to end the call. Simple.
If I’m using the iPhone for something else when the call comes in I’ll see a red “Decline” button at bottom left and a green “Answer” button at bottom right. Also simple. There's no need to "slide to answer" because the phone is unlocked.
So what's the problem? Like I mentioned, I also use my phone for texting and email. When I'm done, I don't lock the phone, I simply put the phone in my pocket because I know it will eventually lock itself. If a call comes in before the phone locks however, I run afoul of a fatal design flaw in which the interface not only fails to support me, it actually accomplishes the opposite of my goal.
In this case, I have left the mental model of "using an active, unlocked phone" behind and have switched to a "locked phone on standby in my pocket" model. When the phone rings, I employ my default “take a call” mental model and I "slide to answer" (and unlock) from left to right. But because the phone is still unlocked, the “answer call” UI has a red “decline” button where my thumb begins its “slide to answer" and I lose the incoming call.
In other words, I have an existing mental model that is very strong and very effective for the most common use case, which (for me) is answering a call on a locked iPhone. The problem is that I cannot easily interrupt this model when I realize it is the wrong response because it consists of a series of actions that have blended into one single routine. So even though when answering a call on an unlocked iPhone I sometimes have time to notice that the "Decline" button is visible rather than the "slide to open" affordance, it's too late. I click the "Decline" button when what I really wanted to do was take the call. Now I'm in recovery mode and I'm mad at Apple because they did not follow through with the mental model that they asked me to create in the first place.
Apple's Human Interface Guidelines is a classic, and is followed by many designers. The Apple standard for action buttons is to place the primary action to the right of the secondary, which is the opposite of Windows. In most cases, it makes sense to follow the standard. In this case, it could be argued that a departure from the standard is justified. For me, this was the most important lesson of the experience; let the use case drive the interaction, not the standards.
Apple designers, if you are reading this, please reverse the order of the buttons to support the most common use case, answering a call. I will use the "hush" button to decline calls. There may be an even better design solution out there, but for now this will support me just fine.
Apple designers, if you are reading this, please reverse the order of the buttons to support the most common use case, answering a call. I will use the "hush" button to decline calls. There may be an even better design solution out there, but for now this will support me just fine.
