UX design inside a button

How Apple reduced a product’s friction in the least expected interface: the earphones.

Imagine you’re an Apple UX designer on the verge of releasing an iPod Shuffle without controls on the device. Now, using a single input—the click from the earphone’s microphone— issue the next commands: play, pause, next, fast forward, back and rewind. The Siri toggle will be added when the iPhone 4s comes out.

The solution you must come up with, should be elegant and as frictionless as possible.

The first thing you as an interface designer have to decide, is to wether your system will differentiate between either number of clicks in a time range, or the duration of clicks.

As you see, this gets old quick, and the next and fast forward actions bear no more resemblance to each other more than the play/pause and siri toggle.

Ok, lets try the duration of clicks:

We face the same problem, also, this time we’d have to define a base time lapse (e.g. 1 second). Then we run into the problem that people won’t know exactly how much one second lasts in every situation in which the device is involved like running, working or resting.

Great, this works, similarly there’s now a relationship between next and fast forward; play/pause and the siri toggle and the back and rewind toggle. Best of all, this is not time dependent, there’s no defined time lapse in which the actions have to be executed to be considered long or short clicks, so there’s no need to have a defined base time lapse.

Furthermore, we can use the long press on the fast forward and rewind toggles to indicate how much time must those actions take. But now your intern is asking you:

Why don’t we use this notation? It still keeps the same relationships as before and it uses less clicks, and less is better right?

Not quite.

It may use less clicks, but complexity actually rises when using this scheme. Remember that what we’re trying to avoid here is friction, and placing a long press as an identifier takes longer time, confuses the user on what a long click is and would be ambiguous on wether it should trigger the rewind or fast forward toggles.

This graph illustrates how complexity rises as a function of the number of clicks, their duration and position in time. The same way in which every language, the most popular words are the easiest to write and pronounce. Note how the most frequently used action —the play/pause toggle— is the less complex one. Let’s compare it to the intern’s proposal:

As you can see, it rises the friction since the very beggining, the already-discussed issues with a leading long click arise and our already established identifier+duration scheme breaks.

Congratulation fellow engineer, you’ve now created Apple’s “morse code” as intuitive as possible, while maintaining the cleanliness on a one-dimensional input (the mic button) and creating a logical relationship between functions that make the track go forward and backwards. This is what frictionless philosophy is all about.