Designing Microinteractions
This article is based on a podcast with Jared Spool and Dan Saffer. Listen to the podcast or read the full transcript.
Jared: What are microinteractions?
Dan: Microinteractions are the small pieces of functionality that exist around or sometimes in place of larger features. An example is turning off the ringer on your phone. Nobody is buying your phone because you can turn the ringer off, but it’s still this little important piece of functionality that if it’s not there can cause a lot of problems.
Jared: It’s an interesting thing, that ringer-off button.
Dan: Right. It’s another little piece of functionality. It has what I call invisible triggers. It’s something that you may never discover, ever. How do you make that a little more discoverable or at least learnable? How do you latch onto something like that? How did you find that out, just by trial and error or was it something that you read online. Did someone mention, “Oh, you could do this.”
Jared: I don’t know. I think a lot of these are what I’ve been calling, “Socially transmitted functionality.” You find out, it’s drag and drop. You find out about it. You’re sitting there and you’re watching somebody.
Dan: Socially transmitted is a funny way to put it, but yes.
Jared: I remember having one of these Casio watches that had 16 different functions. It had a built in thermometer and barometer, all these crazy things but it only had four buttons. You had to know the right magic sequence of buttons. Of course, none of the buttons were labeled.
It was really overloaded, in terms of its functionality. I’m going to guess that a lot of microinteractions live in the land of overloaded functionality.
Dan: I think that’s probably true.
Jared: Microinteractions aren’t limited purely to just buttons, right? It’s gestures and mouse movements and it’s even things that the device does on its own.
Dan: There are two ways that any kind of microinteraction gets triggered. One is a manual way where you are pushing a button, clicking on something, waving or a voice command, or any of those physical ways that you’re doing things. The other way is a more system-initiated trigger, where a certain set of conditions are met. When I get near my Nest thermostat, it has a proximity sensor. It turns on and shows me what the temperature is.
It’s these really great little moments like, “I didn’t have to go search through settings to go find that. It intuited what I really needed at that moment. That set of conditions happened, and it popped up the microinteraction that I could use right there. I really love it.
Jared: In this day and age, anybody who’s doing any sort of app, whether it’s desktop or mobile or even just building some content-related stuff, there are microinteractions involved in that.
There are microinteractions involved in every product. The question is whether you’re actually going to spend the time and care to make them the best that they can be. In my opinion, you’re only as good as your worst microinteraction. There’s a lot of things that are completely undifferentiated, but if you have some really nice microinteractions around it, that makes all the difference in the world. An obvious example is your operating system. Most operating systems are doing the exact same things. How all those things work is all about people focusing on the microinteractions inside the operating system and that really differentiates one from the other.
Jared: It feels to me like this is one of those things where our design processes aren’t very good at making sure we’ve got our bases covered. It doesn’t seem like we have a good way of making sure that we are tracking all the microinteractions and, more importantly, that we are not putting in clumsy, awful microinteractions and not realizing it.
Dan: Right. When I started thinking about all the standard microinteractions there are I thought, “Oh my god! These are the things that we ignore until the very last minute.
We forget about what’s dismissively called “product hygiene.” People just expect it to be there. But maybe there’s something better that I can do with it. What is it that could make that more interesting, more valuable to the people who are using it? These are the things that can be so easily overlooked and often are.
Dan: Any situation where you may encounter some kind of error is almost always some kind of microinteraction, and you try figuring out ways to prevent that from happening. I talk a lot in my book about preventing human error or preventing ways for your system to be abused either accidentally or on purpose by users. I think those are important moments. When things get messed up it’s great time for your product to show a little bit of personality.
Error messages and the like are great ways to convey, “Hey. We are human. Something bad happened. Let’s figure out how to fix this together, and let’s be reasonable about this.” I think that errors in particular are really great places for microinteractions.
Jared: In the workshop that you’re giving at UI18, you’ll be going through the framework on helping people understand how to hone in on this stuff. Really make sure that their applications and their designs have the right microinteractions.
Dan: Basically the workshop is divided up into four main chunks. The first thing we do is talk about the triggers, which we touched on here. How do you design manual and system triggers? Trying to figure out what the user behavior is that could cause triggers to happen.
Then we go into the rules where we figure out: What are the rules of the system? Have you played this microinteraction? What are ways that we can make the rules so that errors don’t happen, or so that things are more streamlined and more efficient?
Then we talk about feedback. We get deep into everything from visual feedback and some animation, even some talk about writing microcopy. How do we write microcopy in a way that is really polished and really speaks human, so that humans can actually respond to it.
The last bit is all about that kind of loops and modes, which make up the meta part of microinteractions. Finally, at the end of the day, we put everything together and design a couple of simple sample ones. This is done to make sure that everything that you have learned the entire day is all put together so that when you leave, you can immediately go back to your desk and think about the model, and really just dig down and start polishing the microinteractions wherever you find them. Doing this helps make your product something that is really interesting and that people love, and not just tolerate.
Enroll in Our Four-Week Live Course on Outcome-Driven UX Metrics.
Establish your team’s 2025 UX metrics and goals by investing just 4 hours a week in our new Outcome-Driven UX Metrics course, featuring 8 hours of pre-recorded lectures and 8 hours of live coaching sessions with Jared.
You’ll learn to set inspiring UX goals, boost your team’s strategic impact, and receive personalized coaching, all while gaining access to a community of 51,000+ UX leaders.