Microinteractions: Trigger–Rules–Feedback–Loops

Interactive example · MicrointeractionsTrigger → feedback

Notifications off

128Tap to like

Copy linkConfirms the action

Each microinteraction has a clear trigger, immediate visual feedback, and a calm resting state — the smallest unit of good interaction design.

The full lesson

Microinteractions are the smallest, most focused moments of interactivity — a single exchange between the user and the system. Dan Saffer’s model breaks them into four parts: Triggers, Rules, Feedback, and Loops & Modes. This framework gives you a precise vocabulary for designing and critiquing these moments, instead of treating them as decoration you add at the end of a project.

Why Microinteractions Are Worth Designing Explicitly

Most teams spend their design time on screens and flows, then sprinkle in “nice animations” just before launch. The result is an interface that feels inconsistent — some states communicate clearly, others leave users guessing.

When a form field turns red after invalid input, that is a microinteraction. When a like button animates on press, that is a microinteraction. When a toggle remembers your last setting when you return, a loop controls that.

Designing microinteractions deliberately produces three compounding benefits:

• Reduced uncertainty: users always know whether their action was received and what the system did with it.
• Error prevention: well-designed rules enforce constraints before mistakes happen, not after.
• Emotional quality: purposeful motion and sound (when appropriate) communicate care, turning functional interfaces into ones users enjoy.

Research consistently shows that perceived performance matters as much as measured performance. A 200 ms animation confirming a tap feels faster than 200 ms of silence, because the brain reads missing feedback as system latency.

Component 1: Triggers

A trigger starts the microinteraction. There are two kinds.

User-initiated triggers are explicit actions: a tap, a click, a voice command, a gesture, or a button press on a wearable. The user decides to start something.

System-initiated triggers happen without a direct user prompt: a push notification arriving, a background sync completing, a battery dropping below 20%, or an incoming call interrupting a video.

The key design question for every trigger is: is it discoverable? A feature hidden behind a long-press or swipe gesture has an affordance problem — the trigger exists, but nothing signals it to the user. Discoverable triggers use standard platform conventions (pull-to-refresh is universally understood on mobile), visible affordances (a drag handle), or progressive disclosure (a tooltip that appears after three seconds of hover).

Component 2: Rules

Rules are the logic that governs what happens once a trigger fires. Users never see rules directly — they live in the product’s behavior — but they are the most consequential design decisions you make for any interaction.

Rules answer three questions:

1. What can the user do? — constraints, affordances, and valid states. A text field that accepts only numbers enforces rules through input filtering. A drag-and-drop list that rejects files imposes a type constraint.
2. What happens next? — the sequence of system behavior. Submit a form → validate → if valid, POST to API → show success state. Each branch is a rule.
3. What is forbidden? — edge cases and guard rails. Can the user submit a half-completed form? Can they delete the last item from a list? Rules define the fence around valid behavior.

A critical modern practice is mapping all rules to an explicit state machine before writing visual specs. States like idle, loading, success, error, and disabled are not cosmetic variations — they are distinct rule sets that produce different feedback. Treating them as afterthoughts leads to missing states that confuse users and generate bug reports.

Component 3: Feedback

Feedback is everything the user perceives during and after the microinteraction: visual changes, motion, sound, and haptics. It is the only part of a microinteraction the user consciously experiences. That is why it gets disproportionate design attention — but it must serve the rules, not override them.

Visual Feedback

Visual feedback is the primary channel in almost every interface. Here are the most useful patterns:

Feedback type	Best use	Outdated habit to avoid
Color change	State shifts (active, error, success)	Low-contrast “de-emphasis” that violates WCAG 2.2 AA
Shape/size change	Press states, loading skeletons	Spinner for every async operation regardless of duration
Position change	Drag confirmation, scroll progress	Animating top/left instead of transform
Opacity change	Appear/disappear transitions	Looping decorative animation with no pause mechanism

Motion Feedback

Motion communicates causality, hierarchy, and state. The modern standard is spring-based easing rather than linear or cubic-bezier curves. Springs model how physical objects actually behave under force — they overshoot slightly and then settle — so the motion feels natural rather than mechanical.

Motion tokens encode these decisions into reusable values:

--motion-duration-fast:   120ms   /* micro-feedback: press, toggle */
--motion-duration-default: 240ms  /* state transitions */
--motion-duration-slow:   400ms   /* layout shifts, panel open/close */
--motion-easing-spring:   cubic-bezier(0.34, 1.56, 0.64, 1)
--motion-easing-standard: cubic-bezier(0.4, 0, 0.2, 1)

The single most important motion rule: animate only compositor-promoted properties. transform and opacity run on the GPU compositor thread and never trigger layout or paint. Animating width, height, top, left, or margin forces the browser into expensive layout recalculation on every frame — causing jank even on modern hardware.

The prefers-reduced-motion Contract

Animating everything without considering motion sensitivity is both a WCAG 2.2 violation and a UX failure. The prefers-reduced-motion: reduce media query is a user’s explicit signal that they want less motion — due to a vestibular disorder, epilepsy, or personal preference. Honor it:

@media (prefers-reduced-motion: reduce) {
  /* replace bouncy entrance with instant or cross-fade */
  .card-enter {
    animation: none;
    opacity: 1;
  }
}

The modern approach is not to strip all animation under reduced-motion. Instead, substitute purposeful subtle alternatives — cross-fades, instant snaps — rather than silently removing all visual feedback. Users with reduced-motion still need to know when an action succeeds.

Sound and Haptic Feedback

Sound and haptics are powerful feedback channels in mobile and wearable contexts. They carry obligations, though: they must respect system-level mute states, never play without user opt-in in web contexts, and always have a visual equivalent for users who cannot perceive them.

Component 4: Loops and Modes

Loops govern what happens over time — what the microinteraction remembers, how it changes on repetition, and whether it has a defined end.

Loops answer: does this microinteraction change after it runs once? A progress bar that fills and then resets is a loop. A like count that increments and retains the count is a persistent loop. An onboarding tooltip that only shows on the first visit is a one-shot loop.

Modes are special states that change the rules for all subsequent interactions in a context. Dark mode is the canonical example — it shifts every visual rule across the entire interface. Airplane mode is a system-level mode. An “edit mode” on a data table changes every cell from a display component to an input component.

The design hazard with modes is mode error — the user performs an action intended for one mode while actually in another. The classic example is a word processor where Caps Lock is accidentally on. You combat mode error by making the mode indicator persistent, prominent, and impossible to miss.

Putting the Framework Together: A Worked Example

Scenario: a user toggles a notification preference in a settings panel.

Component	Design decision
Trigger	User taps the toggle switch (user-initiated, platform-standard affordance)
Rules	IF toggle is OFF AND user taps THEN state = loading; POST to /preferences API; IF success THEN state = ON; IF error THEN revert state = OFF + show error
Feedback	Toggle animates from left (off) to right (on) using spring easing over 240 ms; thumb changes from gray to brand-color; aria-checked updates to “true”; on error, toggle snaps back and an inline error message appears below
Loop	State persists across sessions; if the user revisits, the toggle initializes to the last saved state retrieved from the API

This level of specification removes ambiguity between design and engineering, surfaces edge cases before build, and produces a complete, accessible interaction.

Common Failures and Their Fixes

Feedback that precedes the rule completing: animating to “success” before the API call resolves is called optimistic UI. It works well for low-risk, reversible actions (liking a post), but is inappropriate for high-stakes operations (payment confirmation). Know which operations can be optimistic and which must wait.

Missing disabled-state feedback: a submit button that does nothing when clicked — because a required field is empty — leaves users guessing. The correct rule is to show the button in a disabled state with sufficient contrast (WCAG 2.2 requires 3:1 for UI components), and surface inline field errors on blur so the user understands why submission is blocked before they even try.

Loops with no memory in error paths: if a user half-fills a form and the session expires, restoring that partial state is part of the loop design. A form that silently discards progress on timeout is a loop with a destructive termination condition the user never agreed to.

Mode indicators too subtle: a read-only mode that only differs by removing toolbar buttons will alert expert users who notice the toolbar — and confuse everyone else who tries to edit and gets no response. The rule of thumb: any mode that prevents expected actions must produce immediate, clear feedback when those actions are attempted.

Accessibility Checklist for Microinteractions

Before shipping any microinteraction, run it through these WCAG 2.2–aligned checks:

• Color is not the only feedback signal — every state change uses at least one non-color indicator (icon, label, border weight, position)
• Focus indicators survive state transitions — when a button enters a loading state, the focus ring must not disappear
• aria-live regions announce dynamic content — success and error messages injected into the DOM are announced to screen readers via aria-live="polite" (or assertive for critical errors)
• Motion respects prefers-reduced-motion — all transitions have a reduced-motion alternative
• Touch targets meet WCAG 2.2 criterion 2.5.8 — minimum 24×24 CSS pixels, target size including spacing; aim for 44×44 for primary actions
• Timeouts are disclosed and extendable — any interaction that auto-advances or times out gives users at least 20 seconds and a way to extend (WCAG 2.2, criterion 2.2.1)