Microinteractions

Review

One reason I love product management is the contrast it demands: strategic expansiveness alongside sweating tiny details. Saffer's book operates entirely in the detail half. What he adds is vocabulary. The anatomy of a microinteraction (trigger, rules, feedback, loops and modes) is a clean model for decisions practitioners often make by feel, and once you have it, you start noticing where teams design feedback without having thought clearly about the trigger, or write rules nobody can articulate. I reach for this book when a team needs shared language for interaction design. It earns its place as reference material rather than a one-time read.

Key Takeaways

The parts worth keeping

• A microinteraction is a contained product moment that revolves around a single use case: small functionality that does one thing.
• The overall experience of a product relies heavily on microinteractions (the 'look and feel'). In a competitive market, when features reach parity, it is the experience that drives adoption and brand loyalty.

Details aren't just the details, they are the design.

Charles Eames

The anatomy of a microinteraction

Triggers

• A trigger can be user-initiated or system-initiated. Many microinteractions begin with understanding user need: what the user wants to accomplish.
• System triggers fire on conditions: errors, location, incoming data, internal data, other microinteractions, other people. Most triggers today are not human-initiated.

Principles of triggers

1. Make the trigger recognizable as a trigger in context. Make it engaging.
2. Have the trigger initiate the same action every time.
3. Bring data forward: the trigger can reflect data contained inside the microinteraction. What is the most important thing to show?
4. If it looks like a button, it must work like a button. Never break or fake the visual affordance.
5. The more frequently a microinteraction is used, the more visible its trigger should be.
6. Add a label only if it provides information the trigger itself cannot.

Controls

The kind of control should reflect how much control you want to give the user.

• Minimize choice: provide smart defaults and limit the number of options.
• Controls are coupled with visual affordances (what users expect can be done).
• The best microinteractions have just enough interface, and no more.

States of controls

• Default: idle, no activity
• Active: something is working in the background (downloading, syncing)
• Hover: can show tooltip-style descriptions or relevant data
• Rollover: signals the cursor is in the right place to engage
• On click/tap: what happens when a trigger is activated (expand, disappear, change)
• Toggle: indicates the current setting

Rules

• Rules determine what happens once a microinteraction has been triggered. They are invisible to the user.
• If you cannot easily write out or diagram the rules, users will find the mental model difficult.
• Unless the interaction is radically new, users arrive with expectations. Violating those is only justified when you offer something of significantly higher value.
• Design for the goal, not the steps. The best goals are understandable and achievable.
• Rules must account for constraints: available input/output methods, data, cost, and business requirements.
• Conservation of complexity: every activity has an inherent complexity floor. You cannot simplify past it.
• Any object a user can interact with has at least three states: invitation (default), activated, updated.

Things which are different in order simply to be different are seldom better, but that which is made to be better is almost always different.

Dieter Rams

Feedback

• Feedback illuminates rules. When you push a button, two things should be communicated: the button was pushed, and what happened as a result.
• Feedback should be driven by need. What does the user need to know?
• Less is more. The more channels you use, the more intrusive the result.
• Feedback is the place to inject personality into a product.
• Foghorn test: is this action important enough that users would want to be aware of it when they cannot see the screen?

Feedback should occur:

• Immediately after a manual trigger
• When a system trigger changes state significantly
• When a user reaches the edge of a rule
• When the system cannot execute a command
• To show progress on critical processes

What feedback communicates to the user:

• Something has happened
• You did something
• A process has started, is ongoing, or has ended
• You cannot do that

Animations should be fast, smooth, natural, simple, and purposeful. Use them to: maintain context during view changes, explain what just happened, show relationships between objects, focus attention, and improve perceived performance.

Haptics have three main uses: enhance a physical action, alert when audio is unavailable or undesirable, and create artificial texture or friction on surfaces.

Feedback rules to define: contextual changes (does it adapt, say, at night?), duration (how long does it last, and what dismisses it?), intensity (how bright, fast, or loud?), repetition (does it repeat, and how often?).

Loops and modes

Modes are parts of an application where behavior differs from the default. A mode is a fork in the rules. Use them very sparingly. The best reason for a mode is an infrequent action that would otherwise clutter the UI (a settings mode, for example).

Loops are cycles that repeat for a set duration. Four types:

• Count-controlled: repeats a set number of times (FOR)
• Condition-controlled: repeats while a condition is true (WHILE)
• Collection-controlled: runs through a set then stops
• Infinite: runs until an error or shutdown

• Open loops do not respond to feedback; they execute and end.
• Closed loops have a feedback mechanism built in and are self-adjusting.
• Progressive reduction: as users grow familiar with a product, the interface can simplify. Labels can disappear; the product trusts the user.

Fixing a dull microinteraction

• Should this be a signature moment?
• Am I starting from zero? What do I already know about the user or context?
• What is the most important piece of data inside this microinteraction? Can I bring it forward?
• Would a custom control be appropriate?
• Am I preventing human errors?
• Am I using what is overlooked?
• Can I create an invisible trigger for advanced users?
• Are the text and icons human?
• Can I add animation to reduce static feel?
• Can I add additional channels of feedback?
• What happens when the user returns the second time?