| name | micro-interactions-and-feedback |
| description | Use when designing per-control feedback for presses, toggles, inputs, selections, optimistic actions, haptics, or delight moments. Use motion-design for the product-wide timing, easing, transition, choreography, and reduced-motion system. |
| metadata | {"portable":true,"category":"08-motion-and-interaction","compatible_with":["claude-code","codex"]} |
Micro-Interactions & Feedback
Use When
- Specifying the feedback for a single control: button, toggle/switch, text input, checkbox/radio, segmented control, slider, like/save action.
- Designing a signifier animation — a small hint that makes an affordance discoverable (a nudge, a pulse, a peek).
- Adding a delight moment (success burst, achievement settle) and you need to keep it sparing and dismissible.
- Wiring optimistic feedback (apply state instantly, reconcile with the server later) and its rollback path.
- Pairing motion with haptics / sound so the channels reinforce one outcome rather than fight.
- Reviewing an interaction for the trigger → rules → feedback → loops anatomy and for the bounce / animation-fatigue slop tells.
Do Not Use When
- You need the global motion law — duration tables (100/300/500), easing-vs-spring decision, GPU-property list, or the canonical
prefers-reduced-motion strategy. That is ../motion-design/SKILL.md (this skill defers to it and never restates it).
- The work is page/route/view transitions or staggered entrances →
../motion-design (§4.3–4.4, View Transitions).
- The work is microcopy / error-message wording →
../../10-content-design-and-ux-writing/.
- The work is visual styling of the control at rest (colour, type, spacing, shape) →
../../04-web-and-ui-design/ or the token/theming group.
Required Inputs
| Input | Source | Required? | Evidence |
|---|
| Control, task, and complete state set | Product flow and component spec | yes | Reachable-state inventory |
| Motion tokens and platform channels | motion-design and platform guidance | yes | Approved timing, haptic, and reduced-motion rules |
| Server authority and failure behaviour | Engineering contract | when remote | Success, latency, rejection, and rollback cases |
- The control and its complete state set (rest, hover, focus-visible, pressed, active/checked, disabled, loading, error).
- Whether the action is local (instant, authoritative) or server-backed (needs optimistic + rollback).
- Target platforms (web / iOS / Android) and whether haptics are available and appropriate.
- The motion budget and tokens already set by
motion-design (timing scale, spring presets, easing curves).
Workflow
- Map the anatomy. For the control, write out the four layers — Trigger → Rules → Feedback → Loops & Modes — before any timing. See
references/micro-interaction-anatomy.md. If you cannot name the trigger and the rule, you are decorating, not designing feedback.
- Inherit the motion law. Pull duration/easing/spring/reduced-motion from
../motion-design/SKILL.md. Feedback sits in the 100–150 ms band (press/toggle/hover); settle/confirm uses a spring with ζ ≥ 0.7 (no visible bounce), default ζ = 1.0. Animate transform + opacity only.
- Define every state's feedback, including
focus-visible (keyboard) and disabled (no motion). Feedback must never be colour-alone — pair it with shape/icon/position/text (WCAG 1.4.1).
- Pick the feedback channel(s) — visual, haptic, sound — and make them semantic and redundant: success haptic only for success, selection haptic only for selection changes. The control must remain fully usable with haptics/sound disabled (
doctrine/references/wcag-2.2-criteria.md).
- Decide optimistic vs. confirmed. Server-backed actions apply state instantly, fire the request in the background, and roll back only on rejection with a non-spatial error signal + recovery copy. Local actions skip the round-trip.
- Signifiers, sparingly. A signifier animation may run once (or on idle/first-visit), must be interruptible, must never block input, and must obey reduced-motion. Never loop a "look-at-me" pulse on a primary control.
- Delight, even more sparingly. At most one celebratory flourish per meaningful milestone; it is additive (the action already succeeded without it), ≤ ~400 ms, never on the hot path, and fully replaced under reduced-motion.
- Write the spec as a state table + motion timeline + reduced-motion replacement + platform parity (see
examples/). Run the acceptance checklist.
Decision Rules
| Condition | Feedback design | Wrong-choice failure |
|---|
| Local authoritative action | Immediate visual state change | Artificial delay makes a reliable action feel broken |
| Reversible server-backed action | Optimistic feedback with visible rollback | Premature success silently diverges from server truth |
| Irreversible or high-risk action | Confirm before action; do not optimise success | Optimism creates harmful false confirmation |
| Haptics unavailable or inappropriate | Visual plus semantic state feedback | Haptic-only feedback excludes users and platforms |
Capability Contract
Read and search are required for component states, motion tokens, and service behaviour. Editing is allowed only when implementation is requested. Rendering or execution is required to claim timing, haptic, assistive-technology, or rollback success.
Degraded Mode
If required evidence or tooling is unavailable, use the scoped fallback below and mark the result unverified.
Without a runnable control, produce a state-and-timeline specification and mark tactile, timing, and assistive checks unverified. Without server failure semantics, do not prescribe optimistic success; use pending feedback until authority is known.
Anti-Patterns
ease-*-back / bouncy overshoot interpolators (the App Design Apprentice habit). They violate the engine's ζ ≥ 0.7 no-bounce rule and are the #1 AI animation fingerprint (doctrine/references/ai-slop-taxonomy.md). Use a spring in the no-bounce band; if you want a "pop", cap it at ζ≈0.7–0.75 (barely perceptible), never elastic.- Animation fatigue — every control pulsing, bouncing, or flourishing. Feedback that is always on is noise; reserve motion for state change and confirmation.
- Colour-only feedback (green = on, red = error with no other cue). Fails WCAG 1.4.1 and colour-blind users.
- Decorative haptics / fake loaders — buzzing on every tap, or a spinner that runs after the work is already done. Haptics must map to outcomes; loaders only appear past the ~80 ms threshold.
- Optimistic feedback with no rollback — showing success then silently diverging from server truth. Always define the rejection path.
- Looping signifiers that never stop, or delight that blocks the next action.
- Feedback that lies about latency — instant "done" checkmark while the request is still in flight with no reconciliation.
Outputs
| Artefact | Consumer | Evidence and acceptance condition |
|---|
| Per-control feedback specification | Component designers and engineers | Every reachable state has honest visual and semantic feedback |
| Optimistic/rollback contract | Frontend and service owners | Latency, success, rejection, and restoration paths are explicit |
| Accessibility and platform evidence | QA and release owner | Reduced-motion, non-colour cues, and supported haptics are verified |
- A per-control micro-interaction spec: anatomy (trigger/rules/feedback/loops), state table, motion timeline (timing + easing/spring), channel map (visual/haptic/sound), optimistic + rollback path, reduced-motion replacement table, platform parity, and an acceptance checklist.
Examples
examples/toggle-switch-feedback-spec.md — a worked notification-toggle spec: full anatomy, every state, spring settle (ζ≈0.75, no bounce), optimistic update with rollback, haptic pairing, and a considered prefers-reduced-motion replacement. Never lorem.
References
references/micro-interaction-anatomy.md — the trigger → rules → feedback → loops model, the feedback-channel decision, signifier rules, optimistic-feedback contract, and the haptic-pairing table.../motion-design/SKILL.md — the owning motion law: timing (100/300/500), easing vs spring, ζ ≥ 0.7 no-bounce, GPU-only properties, and the canonical prefers-reduced-motion strategy. This skill defers to it.doctrine/design-doctrine.md — the anti-slop charter; over-animated or bouncy feedback is a slop tell.doctrine/references/ai-slop-taxonomy.md — ease-*-back/overshoot and animation-fatigue tells to inoculate against.doctrine/references/wcag-2.2-criteria.md — accessibility floor: 2.3.3 (reduced motion), 2.3.1 (≤3 flashes/s), 1.4.1 (never colour-alone), 2.5.8 (target size), 4.1.2 (state exposed to AT).
