The short version: A microinteraction is a trigger plus feedback for one small task. Good ones respond within 0.1 second, explain what changed, respect reduced-motion settings, and animate only transform and opacity. If a microinteraction does not confirm, prevent an error or show status, remove it.
Last updated: 21 October 2026.
A microinteraction is the smallest unit of interface behaviour: one trigger, one piece of feedback, one job. The heart that fills when you like a post, the toggle that slides to "on", the field that turns red when a card number is short. They matter because they answer the question every user asks after every action, which is "did that work?"
This guide covers how to design them so they help rather than decorate, with the timing numbers, accessibility rules and performance constraints we apply in product work.
What exactly is a microinteraction?
Nielsen Norman Group defines microinteractions as trigger-feedback pairs, where the trigger is either a user action or a change in system state and the feedback is a small, contextual response to it (NN/g, October 2018). The same article credits Dan Saffer's 2014 book Microinteractions with defining the concept.
The practical test is scope. A video player is a feature. The volume slider inside it, with its live percentage and mute state, is a microinteraction. If you can describe it in one sentence starting with "when the user..." or "when the system...", it is probably one.
What jobs should a microinteraction do?
NN/g lists three: communicate system status, help prevent errors, and carry the brand. In our experience the first two justify almost every microinteraction worth building, and the third is a bonus that only works once the first two are solid.
| Job | Example | What goes wrong without it |
|---|---|---|
| Confirm an action | "Saved" tick after an autosave | Users press save again, or leave unsure |
| Show status | Upload progress on a file row | Users cancel a working upload |
| Prevent errors | Password rules ticking off as you type | Users submit, fail, and retype |
| Reveal affordance | A card lifting slightly on hover | Users do not realise it is clickable |
| Carry brand | A custom pull-to-refresh animation | Nothing breaks, so build it last |
If a proposed animation does none of these, it is decoration. Decoration has a cost in build time, performance and motion sensitivity, so it should earn its place in review like any other feature.
How fast should feedback be?
Jakob Nielsen's response-time limits, first published in his 1993 book Usability Engineering and still cited today, give the budget (NN/g):
- 0.1 second is the limit for a response to feel instantaneous.
- 1 second is the limit for the user's flow of thought to stay uninterrupted.
- 10 seconds is the limit for keeping attention on the task.
The 0.1 second figure is the one microinteractions live or die by. A button that changes its pressed state 300 ms after a tap feels broken, even if the network request behind it is quick. So render the visual acknowledgement immediately, on the client, and let the slower work catch up.
On the web this budget is now measured. Google's Interaction to Next Paint metric treats 200 ms or less at the 75th percentile as good responsiveness (web.dev). A heavy click handler that blocks the main thread before painting the pressed state hurts both the user and the metric.
Spinner, skeleton or progress bar?
Loading feedback is the most common microinteraction and the one most often wrong. NN/g's guidance on progress indicators says looped spinners suit waits of 2 to 10 seconds, and that for anything under 1 second a looped animation is distracting, because users cannot follow what flashed on screen (NN/g, October 2014). For full-page loads, skeleton screens reduce perceived waiting and also belong to waits under 10 seconds; past that, use a progress bar (NN/g, Skeleton Screens 101).
A rule we use in builds: delay the spinner. Start a timer when the request starts, and only show the indicator if the request is still running after a few hundred milliseconds. Fast responses then show no flicker at all, and slow ones still get feedback.
How do you design one, step by step?
Saffer's model breaks every microinteraction into trigger, rules, feedback, and loops and modes. Turned into a checklist for a design review:
- Trigger. What starts it? A tap, a keystroke, a timer, a server event? Is the trigger visible, and is it reachable by keyboard and screen reader?
- Rules. What happens, in plain words? Write the states down: idle, pressed, loading, success, error, disabled.
- Feedback. What does the user see, hear or feel for each state? Every state needs a visual, and none should rely on colour alone.
- Loops and modes. What happens the second time, or the hundredth? A celebration that delights once is irritating on the twentieth order.
The error state is the one teams skip. Design it first. A "Saved" tick is easy; a save that fails while offline, and how the control recovers, is where users judge the product.
How do you make microinteractions accessible?
Motion is a real accessibility issue. WCAG 2.2 success criterion 2.3.3 (level AAA) asks that motion animation triggered by interaction can be disabled unless it is essential, because people can get sick from motion effects (W3C). Even if you only target level AA, honouring the user's setting is cheap.
On the web, the prefers-reduced-motion media query reports whether the user has asked the operating system to minimise non-essential motion (MDN). Apple's Human Interface Guidelines ask apps to respond to the Reduce Motion setting by reducing automatic and repetitive animation, including zooming, scaling and peripheral motion (Apple HIG, Accessibility).
Reduced motion does not mean no feedback. Swap a sliding transition for a quick fade or an instant state change, and keep the tick, the colour change and the text.
Two more rules. First, a status change that appears visually must also reach assistive technology. WCAG 4.1.3 requires status messages to be programmatically exposed so screen readers announce them without moving focus (W3C); a live region with "Saved" or "3 results" does this. Second, never rely on colour alone for success and error. Pair it with an icon or words.
How do you keep animations fast?
Animate transform and opacity, and avoid properties that trigger layout or paint. That is web.dev's standing advice for high-performance CSS animation (web.dev, animations guide). Animating width, height, top or margin forces the browser to recalculate layout every frame, which drops frames on mid-range phones even when it looks fine on a developer laptop.
On native platforms the same thinking applies. Use the system's animation APIs and components, which Apple notes already adjust their motion for accessibility settings and input methods (Apple HIG, Motion).
When do haptics help?
Haptics are a microinteraction channel on phones, and they are easy to overuse. Apple's guidance is to use system haptic patterns according to their documented meanings, and to tie each haptic to a clear cause and effect, because a haptic that does not reinforce one feels confusing and gratuitous (Apple HIG, Playing haptics). In practice we reserve haptics for confirmations users cannot see well: a successful payment, a snap into place during drag, or a destructive action that just completed.
Where should you start on an existing product?
Do not add animation first. Audit what is already there:
- List every action that changes data and check it has pressed, loading, success and error states.
- Measure how long each takes to acknowledge visually. Anything over 0.1 second is a bug.
- Turn on reduced motion in your OS and walk the main flows.
- Run the main flows with a screen reader and listen for silent status changes.
- Only then decide which moments deserve brand-level polish.
Microinteractions are where design and engineering meet in the smallest possible space, so they go wrong when either side works alone. Our product UX design team designs them as part of the state model rather than as a final coat of paint, and our mobile app developers build them on the platform's own motion and haptic APIs. For the visual side of the same work, see our guide to dark mode UI best practices.
