Designing Intuitive Microinteractions

“Wait! What did you just do there?”

That’s how an STD is transferred. In this case, I had just unlocked my iPhone by sliding over a notification’s icon.

The person I was standing next to had never seen anyone unlock their phone that way. They’d had an iPhone since the very first days and had no idea you could do this.

Of course, why would they? There are no visual clues to tell you the notification icon is slide-able. If you were told when you first got your phone, you probably wouldn’t remember now, unless you used it all the time.

STD: Socially-Transmitted Detail

I found out you could unlock the phone that way because I saw someone else do it. They were standing next to me and slid the icon over, causing me to exclaim, “Wait! What did you just do there?”

We’ve given this a name: Socially-Transmitted Details (Actually, we first called it Socially-Transmitted Functionality but STD gets more of a giggle than STF.)

STDs are design interactions that users learn about from other users. There’s no instructions or clues in the interface to tell you about the interaction.

The classic socially-transmitted detail is something that’s done through drag and drop. Moving a file into an application, for example. Knowing you can drag an image into a photo editor’s icon to open it is something you probably wouldn’t discover on your own. You’d have to be told.

Calling the Magic Escalator of Acquired Knowledge

By definition, features hidden behind socially-transmitted details are not intuitive. Since users don’t know about them, they can’t use them.

Most of these features are buried in microinteractions, like the notification slide-to-unlock feature. Dan Saffer, who wrote an entire book on microinteractions says they are “contained product moments that revolve around a single use case-they have one main task.” The main task of the slide-to-unlock feature is to unlock the phone, bringing the user to that notification in that app.

For microinteractions to provide benefit, they need to be intuitive to the user. How do we know if we’re designing something intuitive? That’s where the Magic Escalator of Acquired Knowledge factors in.

A while back, we invented the Magic Escalator to help explain how intuitive design works. When we’re designing microinteractions, the escalator points we’re most interested in are the user’s current knowledge and their required target knowledge

Current knowledge is what our user knows when they approach the design. It could include previous experience with similar designs or knowledge they’ve picked up from the real world (like how a book or a car dashboard works).

Target knowledge is what our user needs to know to accomplish their objective. Whatever our design demands from the user that they didn’t already know is what makes target knowledge different from current knowledge.

To make our microinteractions intuitive to the users, we need to take advantage of their current knowledge. A design is intuitive when current and target knowledge are close together. Therefore we need to design for what our users know. Unfortunately, when we design an STD, we move away from intuitive design.

Thinking Intuitively

If you use Luke Wroblewski’s Polar app, you’ll probably want to check to see if any new polls have been added by your friends. Like many phone apps, he’s included the pull-to-refresh interaction.

Polar tries to reinforce the user’s current knowledge by offering a little hint that tells them to “Pull down to refresh…” Pulling down further rewards the user with a cute graphic (which changes each time) and changes the instructions to “Release to refresh…”. This interaction, which only lasts a second or so, makes it clear what to do, making it feel intuitive.

Polar still has the problem that users need to know to pull in the first place. If they’ve used many other apps, that will be their current knowledge. Many users might do it subconsciously. We call that finger memory since your fingers seem to do it on their own.

However, new users to the phone may not know about this yet and nobody has told them. They won’t get the benefits of the refresh microinteraction.

A Longcut for Every Shortcut (Mostly)

One solution is to think of the STD as a shortcut to the functionality. That means there must also be a complimentary longcut to get the same functions. We can drag a file onto the app’s icon to open it, but we can also open the app and use the File > Open commands to accomplish the same objective. Sliding the notification icon over to unlock the iPhone is the shortcut, while using the standard unlock slider and opening the application is the longcut.

Another approach is to bypass the shortcut altogether. United Airline’s iPhone app used to have a pull-to-refresh microinteraction for updating flight status and reservation data. In a recent design update, they changed that to use a refresh icon that’s always visible at the top of the screen.

Sensible Feedback

What does the microinteraction do? If we want it to be intuitive, it needs to do what the user expects. Those expectations also come from the user’s current knowledge.

In many phone apps, the pull-to-refresh microinteraction bounces back into place immediately. If the refreshed data updates right away, the user is happy. That’s what they expected.

But what happens if nothing changes? Does that mean the operation didn’t work? (Maybe the user thinks they haven’t pulled it down far enough?) Or is the server just slow in responding?

Some designs use an animated busy indicator (such as a spinner) to indicate the app is still retrieving data. Some don’t snap back until the server has responded, floating open to indicate data is on its way. In some cases, a text message appears to say “Checking for updates…” or something similar.

Well-designed microinteractions provide the user with sensible feedback. It feeds into their existing expectations, even if it presents it in a way they’ve never seen before. This is the basis of a mental model: cause and effect. The user’s action produced the expected outcome.

Clear Microcopy

Embedded in most microinteraction designs are words. Take an online banking app, for example. At some point, a user may need to cancel an automatic payment. Because this is a serious operation, the system needs to verify with the user that the automatic payment is about to disappear forever. That verification is another type of microinteraction-one that needs to be intuitive.

A poorly designed verification microinteraction might ask the question using the standard OK and CANCEL buttons. But what does CANCEL mean when we’re verifying a cancellation? Does CANCEL eliminate the automatic payment or does it cancel the cancellation?

What does CANCEL do in this case?

A better designed verification microinteraction could use clearer language to help the user understand their options. Buttons with improved microcopy might use full sentences like “Yes, go ahead and cancel the payment.”

Designing Intuitive Microinteractions

At the core of any interactive experience are dozens of microinteractions-the little details that make that design work. Using our understanding of building intuitive designs, we can focus our efforts on making the right choices to help our users know what to do, how to do it, and what to expect.

You Might Also Like

• The New Frontier of Designing With Data by Jared Spool And Kathleen Barrett There is a scene in The Hunt for Red October, when the actor Courtney B. Vance in the role of Seaman Jones tells the captain of his submarine that, while…
• Pleasure, Flow, and Meaning - The 3 Approaches to Designing for Delight by Jared M. Spool Jared Spool explains the Three Approaches to Delight.