Micro Interactions

---
name: micro-interactions
description: The small motion that makes an app feel built rather than generated -- hover, press, focus, toggles, loading, and state changes done as a consistent system in plain CSS. Use when UI feels static or lifeless, or when hover effects are scattered and inconsistent.
---

# Micro-Interactions

Big animations impress once. Micro-interactions are what make an app feel expensive on the hundredth use: the button that acknowledges a press, the toggle that moves like an object, the row that tells you it is clickable before you click it. This is also where scattered, per-element effects do the most damage -- ten different hover treatments read as ten different authors.

Draw every value from the motion system (`--dur-fast`, `--ease-out`); this skill is about *which* interactions get motion and what they do.

## The interaction set

**Hover** -- available on the element, not a new element appearing. Background, border, or foreground shift; at most a 1-2px lift or `scale(1.02)`. Never reveal essential information only on hover: it does not exist on touch. Guard hover styles with `@media (hover: hover)` so mobile does not get sticky hover states after a tap.

**Press** -- the most underrated one. `scale(0.97)` on `:active`, at `--dur-fast`. It costs one line and is the difference between a div and a button.

**Focus** -- designed, never default. A visible ring using the brand's accent, on `:focus-visible` so it appears for keyboard users and not on mouse click. Removing focus outlines without replacing them is an accessibility failure, not a style choice.

**Loading** -- state-appropriate. Under ~300ms show nothing (a flashed spinner is worse than a pause). Up to a few seconds, a spinner or an inline button state. Longer, and for content-shaped waits, use a skeleton that matches the real layout. A skeleton whose shape does not match what loads causes a layout jump, which is worse than a spinner.

**Success / error** -- the result must be felt, not just rendered. A brief color shift, a checkmark that draws, an error that shakes once (one cycle, 300ms, never a loop). Errors also need to be announced, not only shown -- `aria-live` on the message.

**Toggles, accordions, tabs** -- these move something that exists, so the motion is positional and continuous. `--ease-in-out`. For accordions use `grid-template-rows: 0fr → 1fr` (animatable, unlike `height: auto`) or the newer `interpolate-size: allow-keywords`.

## Workflow

1. **Inventory the interactive surface.** Every element a user can hover, press, focus, or toggle. Most apps have five or six kinds -- button, link, card, input, row, toggle -- not fifty. That list is the entire scope.
2. **Assign one treatment per kind.** All buttons behave the same. All cards behave the same. Write these as component styles or utility classes, not per-instance.
3. **Cover all four states per kind.** Rest, hover, active, focus-visible -- plus disabled where it applies. The commonly-missed ones are active and focus-visible, and they are the two that make the UI feel responsive and usable.
4. **Handle the transitional states.** Buttons that trigger async work need pressed → loading → result, with the width held stable so the layout does not jump when the label changes to a spinner.
5. **Test with the keyboard only.** Tab through the whole page. Every stop should be obvious, in a sensible order, and never trapped. If you cannot tell where focus is, the interaction design is incomplete regardless of how the hover states look.

## Rules

- Transition specific properties, never `transition: all` -- it animates things you did not intend, including layout properties, and it is a common source of unexplained jank.
- Feedback under 150ms. Anything slower stops reading as a response and starts reading as latency.
- One idea per interaction. Scale *or* shadow *or* color -- stacking three is the generated-UI signature.
- Never animate a hover state's `width`, `height`, or `padding`. Layout on hover is jank on hover.
- No looping animations on idle UI. A pulsing button is fine for exactly one primary CTA and intolerable on three.
- Disabled elements do nothing on hover and press -- an animating disabled button suggests it will work.
- Touch targets stay at least 44px regardless of visual size, and a `scale(0.97)` press must not shrink the hit area (it does not -- `transform` leaves layout alone, which is another reason to use it).