Micro-interactions
Micro-interactions are contained moments of feedback — a button press, a like, a toggle flip — that communicate state changes and make an interface feel alive.
The difference between an interface that feels mechanical and one that feels alive is often in the small moments: the way a button responds to a press, the way a toggle settles into its new state, the way a message confirms it has been sent.
What micro-interactions are
A micro-interaction is a contained interaction with a single purpose: to communicate a state change. It has four components: a trigger (the user action or system condition that initiates it), a rule (what happens), feedback (how the change is communicated), and a loop (whether and how it repeats). Most UI interactions are micro-interactions — button presses, toggle flips, swipe-to-dismiss, form submission confirmation.
The function of feedback motion
Motion in micro-interactions serves communication, not decoration. A toggle that animates its transition communicates directionality — the control is moving from off to on, not simply changing colour. A button that scales slightly on press confirms that the press was registered. A heart icon that fills and bounces confirms the like action. Each animation carries information about what happened. When the same animation is applied without a communicative purpose, it is decoration — and decoration should be evaluated against the cognitive and performance cost it adds.
Design constraints
Micro-interactions should be short — typically 200–400ms. Anything longer starts to feel like it is delaying the user rather than informing them. They should be subtle — a change in state, not a performance. They should respect reduced motion preferences: provide a non-animated alternative for users who have enabled the reduced-motion setting. And they should be consistent: the same type of action — confirming something, dismissing something, toggling something — should produce the same type of feedback across the interface.
When they go wrong
Micro-interactions fail when they are more prominent than the content they support, when they introduce delay to interactions that should feel instant, or when they apply motion to every element indiscriminately — creating visual noise rather than meaningful feedback. Apply them where they serve a communicative purpose; leave them out where they do not.
The takeaway
Audit your interface for state changes that users need to understand — toggle states, submission confirmations, selection changes, error appearances. For each one, decide whether a micro-interaction would communicate the change more clearly than a static state switch. If yes, design it with a specific communicative purpose, keep it under 400ms, and ensure it degrades gracefully for users who prefer reduced motion.