Micro-interactions & Feedback Loops

The plain-language idea

A micro-interaction is one small, deliberate, contained interaction — a button's press state, a checkbox's check animation, a "like" button's little burst — as opposed to a whole flow or page transition. The useful way to design one isn't to jump straight to "what should it look like," it's to work through four parts in order:

• Trigger — what starts the interaction (a click, a value crossing a threshold, a timer).
• Rules — what's allowed to happen (can the action be undone? repeated? does it depend on some state, like whether the item's already liked?).
• Feedback — what the user perceives happening (the actual visual/audio/haptic response — this is the part that gets all the design attention, but it's only one of four).
• Loop/mode — does this repeat, and does it change based on how many times it's happened (does liking something twice unlike it? does a repeated action escalate or change?).

Skipping straight to feedback design without the other three is how a genuinely well-animated interaction still ends up feeling wrong — a burst animation with no rule for "what if I tap it five times fast" or "what does the un-liked state actually look like" is unfinished, no matter how good the animation itself is.

See it in a real thing: one like button, four parts

A like button's four parts, made explicit:

• Trigger — a tap or click on the icon.
• Rules — toggles between liked/unliked; can't be triggered while a prior tap's request is still in flight (prevents a rapid double-tap from firing two conflicting requests); disabled or no-ops if the user isn't authenticated.
• Feedback — the icon fills, a small particle burst plays, a haptic tick fires on supported devices, the count increments.
• Loop — a second tap reverses all of it (icon empties, count decrements) rather than being a no-op or an error; there's no fifth state hiding at "tap 3."

Every part except feedback is invisible in a screenshot — which is exactly why a design review that only looks at "does the animation look good" can approve something that's actually incomplete. The rules and loop only surface when someone actually taps it several times in a row, fast, while offline, or while logged out.

What people usually miss

Watch out

• Feedback is the most visible part and the least likely to be the actual problem. A micro-interaction that "feels broken" more often has an undefined rule (what happens on rapid re-trigger, what happens in a disallowed state) than a bad animation.
• A trigger without a clear rule for repetition is a real, common bug source. A double-submit on a form button, or a like button that can fire two conflicting requests from a fast double-tap, is a missing rule, not a missing animation.
• Not every state change deserves a micro-interaction. A micro-interaction earns its place by communicating a meaningful state change a user cares about (liked/unliked, saved/unsaved) — decorating every state change equally dilutes the ones that matter, the same failure mode the motion lesson names for animation generally.
• The loop question is often skipped entirely. Designing only the "first tap" state and assuming the "undo" state is just the reverse animation misses real cases — an "undo" that isn't a clean mirror of the original action (a differently-worded confirmation, a different icon state) reads as a bug even when each individual state was designed carefully.

Why this matters in interviews

"Design a like button" sounds like a warm-up prompt, but naming trigger/rules/feedback/loop as a structure — and specifically asking about rapid re-tap behavior and the unauthenticated case — is what separates a candidate who's animated a button before from one who's actually shipped an interaction that survives real usage.