Micro-interaction

What is a Micro-interaction, and how does it differ from what people generally call "animation"?

A micro-interaction is a trigger-response pair: the user performs a specific action (clicking a button, toggling a switch, submitting a form), and the interface immediately answers with a small, targeted reaction scoped to that single action. It is not a general claim that "animation makes an interface feel nicer" — every micro-interaction must map to one concrete user action and resolve the specific uncertainty that action creates.

The key difference from decorative animation is intent. A button's gradient background is visual design, not a micro-interaction. But the same button briefly darkening and springing back after a click, paired with a spinner, is a micro-interaction — it answers the specific question "did the system register my click?" Without that answer, users tend to click repeatedly, assume the system has frozen, or abandon the task entirely.

Why does Micro-interaction get discussed as its own concept — what problem does it solve?

Interfaces are full of gaps where a user takes an action but has no way to know whether the system responded: uploading a file, submitting a form, toggling a setting. Without feedback during these gaps, users are left guessing. Interaction designer Dan Saffer broke micro-interactions down into four parts — trigger, rules, feedback, and loops and modes — a framework that's widely cited because it insists each interaction be designed as its own unit, rather than left to whatever the overall visual style happens to imply.

For designers working from AI-generated interface drafts, this problem is even more visible. AI tools are good at producing static screens that look complete, but what happens after a click is often left blank or defaults to the simplest possible behavior — nothing happens, or an instant jump. Treating micro-interaction as a checklist item that gets reviewed on its own exists precisely to force the question "what does the user see the moment they act," rather than assuming the screen alone is enough.

How is a Micro-interaction actually designed — how do Saffer's four parts map to practice?

1. Trigger: user-initiated (a click, a drag) or system-initiated (a chime when a download finishes). Designers need to identify which type it is upfront, since the two follow different timing logic.
2. Rules: what happens after the trigger fires — for example, a button won't change color again until the previous click has been fully processed, preventing repeated triggers from creating confusion.
3. Feedback: the part users actually see, hear, or feel — a color change, a vibration, a sound. This is the only layer users directly perceive.
4. Loops and modes: behavior that changes over time — a loading spinner keeps turning until the task completes, a success animation plays once and disappears, an unread notification badge might change appearance after several days.

A common failure mode in practice is designing only the feedback layer (bolting on an animation) without thinking through the rules — under what condition should it fire, and should it lock after firing once. Without that, rapid repeated actions can trigger the same micro-interaction multiple times, stacking into visual noise.

What does this actually mean for someone using Claude to produce design mockups or frontend components?

When you ask an AI to generate a form or button component, what you typically get is the static appearance — colors, spacing, and typography are usually fine, but the step of "what happens after submission" is often skipped or defaults to the simplest possible behavior. When reviewing AI-generated interfaces, it's worth walking through Saffer's four parts for every interactive element individually: what triggers it, whether rules prevent repeated triggering, whether the feedback is actually perceptible, and if the action takes time (an upload, a submission), whether the loop behavior is clearly defined.

The rules layer is the one most often missed, precisely because it isn't directly visible — AI-generated drafts tend to handle visual feedback fine but skip edge cases like "what happens if the user clicks twice in a row." Treating Micro-interaction review as a checklist item, rather than something patched in later during development, saves a fair amount of rework downstream.