Microinteractions: Designing with Details
About a year ago, I bought a new car. It came with lots of fancy features and I had to read the manual front to back to decipher most of them. But of all the things it can do, one of my favorite features is arguably the most simple: the fuel gauge display.
It does exactly what you’d expect, but it also has a subtle arrow pointing to the right that reminds me which side of the car has the fuel door. My previous car didn’t have this and I would always find myself forgetting which side it was on. Now I can look right at the fuel gauge when I pull into a gas station and know which side I need to be on. Smart!
Dan Saffer calls these small design details microinteractions, which he outlines in his book of the same name. If you aren’t familiar with the term, don’t worry; I wasn’t either until I took his workshop a few weeks ago at WebVisions.
Dan defines microinteractions as “contained product moments that revolve around a single use case.” You can think of them as all the beautiful (or ugly!) little details that create an experience when using a product. And if they are done well, these details can be the signature moments that help set your website or product apart from the rest.
“Microinteractions are contained product moments that revolve around a single use case.” -Dan Saffer
According to Dan, a well-crafted microinteraction has four main parts:
- Loops & Modes
Let’s take a closer look at each one:
Triggers are what initiate a microinteraction and can be categorized as either manual triggers or system triggers. Manual triggers are exactly what you might expect; they are controls a user manipulates to start an interaction, such as a button, knob, or switch.System triggers are ones that don’t require user prompting and might be initiated by sensors, time, context, etc.
If you were heading into a meeting you might flip the switch on the side of your phone to silence it. That’s a manual trigger. If the phone knew you were heading into a meeting and asked you if you wanted to put the phone on silent, that would be considered a system trigger.
When we work with our clients, we often see opportunities where detailed thinking through microinteractions can really enhance the experience. One trigger we see a lot here is the Donate button of a website. By questioning whether this simple, manual trigger can be transformed into a system trigger, we’re able to open the door to some interesting possibilities. For example, we might enhance the button interaction to automatically suggest local projects where a user can donate based on their detected location. Another possibility could be to suggest specific project donations based on previously viewed projects.
Rules determine what happens once a trigger has been activated. In other words, the rules define what can be done (what’s allowed) and what feedback the system will give the user.
Going back to our donation example, the rules could outline what happens in scenarios like:
- when the user is logged in vs. not logged in
- if a user has already donated during the same session
- when a donation goal has yet to be met
- if a donor accidentally hits the final Donate button twice
This type of detailed thinking through an interaction helps prevent people from making errors and generally provides lots of fun opportunities to surprise and delight them.
Feedback is everything the system does to let the user know what the rules are and what the system is doing. These can be status labels, audio cues, error messages, and even animations.
For the scenario above with a donation goal, we might create a rule that says the system should provide a special feedback message when someone makes a donation that puts us over the goal. In addition to letting the user know her donation has gone through successfully, it’s important to acknowledge that she specifically helped us reach the goal. Not doing so could leave someone feeling disappointed and that’s the last thing we want someone to feel after contributing.
Modes & Loops
Modes can be thought of as forks in the rules, and Dan suggests avoiding them where possible as they can easily lead to confusion and errors. Modes are best used for infrequent actions such as changing preferences or settings. A good example of a mode is the Settings side of Apple’s OS X weather widget. A user will rarely need to change the city or other preferences. Since these settings aren’t often needed, it’s more appropriate to hide them in a settings mode than to add all the controls to the interface that shows the weather.
Loops are cycles that repeat, usually for a set duration. Loops can be used to great effect to make an interaction seem very smart. A good, simple example of loops are the “smart” timestamps in Gmail that display varying levels of detail depending on how long ago an email was sent.
Here the rules might state that a timestamp should be shown for 24 hours, then the month and day should be show if the email is from the current year.
Returning to our donation example again, we could use loops to streamline the process for a frequent donor. If we notice that someone has manually donated once a month for three consecutive months, we could ask if they’d like to set up automatic payments. If they answer “No,” we could set up another loop to ask again after six months and then maybe again after a year. We could even add another loop that shows a “Never ask me again” option after the second time. As you can see, loops allow you to add a lot of depth to an interaction and can be a great tool to utilize.
Dan’s microinteraction framework is a deceptively simple tool to help designers think through their work and collaborate. It provides a common language for concepts that deserve consideration. It’s easy to see how asking some basic questions like “What system triggers could I use here?” or “What should happen after six months?” will inevitably lead to better interactions and happier people; and ultimately, isn’t that what it’s all about?
The little details are crucial when crafting a great user experience. They require careful consideration and can take time to get right. This is one reason we often recommend a “less is more” approach to development. It’s better to do a few things really well than to do everything poorly. Without this attention to detail, I’d still be pulling up to the pump wondering which side my gas tank is on.
Further Reading & Resources
Haven’t had enough microinteractions yet? Here are some additional resources to explore:
- Microinteractions: Designing with Details by Dan Saffer
- Microinteractions Quick Reference – Great reference guide created by Dan Saffer. Print it out and put it on your wall!