A button that responds is worth ten that don't
You can tell within the first thirty seconds of using a product whether the team cared about motion. The cursor reaches a button and either something happens — a colour change, a scale, a soft elevation — or it doesn't. If it does, you trust the product slightly more, because somebody on the other side noticed that small moment. If it doesn't, you trust it slightly less, because nobody did.
This is the entire premise of micro-interaction design: a thousand small responses to small actions, each one almost invisible on its own, all combining into a feeling of "this product is alive, and someone made it carefully". You cannot fake it with a single grand animation. You earn it with discipline across hundreds of tiny states.
What micro-interactions actually are
A micro-interaction is a contained piece of feedback that fires in response to a single user action. The category covers more than people think:
- Hover and focus states on every interactive element.
- Button press affordances — the tiny inward push when you click.
- Loading and progress indicators for actions that take longer than 150ms.
- Empty states that confirm "yes, this is empty on purpose" rather than "yes, your data has vanished".
- Form validation that fires inline rather than after submit.
- Drag previews and drop zones that signal what a drop will do before it happens.
- Page transitions that create a sense of place when navigating.
- Notification toasts that arrive politely and leave on their own.
Each of these is a moment in which the user is asking a small question — "did the system see what I just did?" — and the design either answers them or leaves them hanging.
The four principles we follow
We have an internal one-pager for motion decisions on every product. It is short on purpose.
1. Confirm every action within 100 milliseconds. Even if the action takes longer to complete, the acknowledgement must be immediate. A button click that doesn't respond visually within a tenth of a second feels broken. A spinner that appears immediately after the click feels honest, even if the underlying request takes two seconds.
2. Match the duration to the meaning. A hover state should be 150-200ms. A page transition should be 400-600ms. A celebration moment (sign-up confirmed, payment successful) can run 800-1200ms because the user has earned it. Cheap-feeling apps use one duration everywhere. Expensive-feeling apps modulate.
3. Ease, don't lerp. Linear motion is the giveaway of an animation that wasn't designed. Real-world objects start slowly, move, and slow down. Use ease-out curves for entry, ease-in for exit, and a pair of carefully chosen cubic-beziers for the few moments that need character. Our default at DIGISUBS is cubic-bezier(0.32, 0.72, 0, 1) — it is gentle on entry and crisp on settle.
4. Earn the user's attention proportionally. The bigger the motion, the rarer it should be. A page transition can be quietly cinematic; a button hover should not be. The visual budget for any one frame is finite, and motion that fires too often, too loudly, becomes noise.
Tooling we reach for
For web work we mostly reach for two libraries. GSAP for sequenced motion, complex easing, and any timeline-based animation. Framer Motion for component-level enter/exit and gesture-driven interactions. We use CSS transitions for the simplest hovers because they are cheaper to render and easier to debug than JavaScript animations.
For native mobile we lean on the platform: SwiftUI's spring physics on iOS and Material 3 motion specs on Android. Trying to ship custom physics on mobile is rarely worth the engineering cost.
For prototyping motion before code we use Principle, ProtoPie, or the timeline view in Figma. The cheapest way to get motion right is to design it before a developer writes a single line.
How to know it's working
There is a moment in every product launch where the team stops noticing the animations. That's the goal. When motion is working, it disappears — it does its job by lowering the cognitive load of the interface, not by drawing attention to itself. If users compliment your animations, they were probably too loud. If they say "this app feels great" and can't articulate why, you got it right.
Micro-interaction design is fundamentally about respect: respect for the user's attention, respect for the interface as a system, and respect for the difference between a thing that responds and a thing that doesn't. It's not the loudest part of the craft, but it might be the most consequential one.