microinteractions

What this skill does

# Microinteractions Framework

A systematic approach to designing the tiny, contained product moments that users interact with every day -- toggles, password fields, loading indicators, pull-to-refresh, like buttons. Based on Dan Saffer's four-part structure (Trigger, Rules, Feedback, Loops & Modes), this framework turns invisible details into the polish that separates forgettable products from beloved ones.

## Core Principle

**The difference between a product you tolerate and a product you love is almost always in the microinteractions.** A microinteraction is a contained product moment built around a single use case: changing a setting, syncing data, setting an alarm, picking a password. They are so small that users rarely think about them consciously -- but they feel them. Every microinteraction follows the same four-part structure: a Trigger initiates it, Rules determine what happens, Feedback shows what is happening, and Loops & Modes define its long-term behavior.

## Scoring

**Goal: 10/10.** When reviewing or creating microinteractions, rate them 0-10 based on adherence to the principles below. A 10/10 means every interactive moment has a deliberate trigger, clear rules, immediate feedback, and thoughtful loop/mode behavior. Lower scores indicate gaps to address. Always provide the current score and specific improvements needed to reach 10/10.

## The Microinteraction Structure

Six areas of focus for designing world-class microinteractions:

### 1. Triggers

**Core concept:** The trigger is what initiates a microinteraction. It can be manual (user-initiated -- a tap, click, swipe, voice command) or system-initiated (a condition is met -- time, location, incoming data, error state). The trigger is the front door of every microinteraction.

**Why it works:** Without a clear trigger, users cannot discover or initiate the interaction. Without a system trigger, the product cannot respond to changing conditions. Well-designed triggers make functionality discoverable and set accurate expectations for what will happen next.

**Key insights:**
- Manual triggers live inside existing UI controls: buttons, switches, icons, form fields, gestures
- System triggers fire automatically when conditions are met: time elapsed, threshold reached, data received
- A trigger must communicate three things: that it exists, what it does, and what state it is in
- Trigger affordance should match the importance of the action -- high-stakes actions need prominent triggers
- Invisible triggers (gestures, shake, proximity) must be paired with a visible alternative for discoverability
- Trigger states -- default, hover, active, disabled, loading -- must be visually distinct

**Product applications:**

| Context | Application | Example |
|---------|-------------|---------|
| **Toggle controls** | Manual trigger with binary state | iOS Wi-Fi switch: tap to toggle, position shows state |
| **Pull-to-refresh** | Hidden gesture trigger with visible affordance | Pulling down past threshold triggers refresh animation |
| **System alerts** | System trigger on condition met | Low battery notification at 20% threshold |
| **Search fields** | Manual trigger with auto-suggest system trigger | Typing initiates search; results appear as system trigger |
| **Hover reveals** | Manual trigger using proximity | Toolbar actions appear on card hover |

**Ethical boundary:** Never hide critical triggers behind gestures or invisible interactions without a visible fallback. Users should always be able to discover essential functionality.

See: [references/trigger-design.md](references/trigger-design.md)

### 2. Rules

**Core concept:** Rules determine what happens once a microinteraction is triggered. They define the sequence of events, the constraints on what can and cannot happen, the algorithm that processes input, and when the microinteraction ends. Rules are the invisible logic -- users never see them directly, but they feel when rules are wrong.

**Why it works:** Rules create the mental model users build about how the interaction works. When rules are consistent and match expectations, the interaction feels natural. When rules violate expectations -- a toggle that does not toggle, a slider that jumps in value -- users lose trust.

**Key insights:**
- Define the goal of the microinteraction first, then derive rules from it
- Rules should feel natural -- match existing mental models and platform conventions
- Constrain inputs to prevent errors: limit character counts, set value ranges, enforce formats
- Handle edge cases explicitly: what happens at zero, at maximum, on repeated triggers, on interruption
- Simple rules produce complex-feeling interactions; complex rules produce confusing interactions
- The best rules are invisible -- users do not think about them, they just work

**Product applications:**

| Context | Application | Example |
|---------|-------------|---------|
| **Password strength** | Rules evaluate input in real-time | Meter updates as user types; color shifts from red to green |
| **Character counter** | Rule constrains and displays remaining | Twitter/X: counter decreases, turns red at limit |
| **Volume control** | Rule maps input to output with constraints | Slider snaps to 5% increments; long-press mutes |
| **Shopping cart** | Rules manage quantity and state | Cannot go below 1; shows "max 10" at limit |
| **Undo action** | Rule sets time window for reversal | Gmail "Undo send" available for 30 seconds |

**Ethical boundary:** Rules should be transparent and predictable. Do not create hidden rules that manipulate user behavior, such as making unsubscribe require more steps than subscribe.

See: [references/rules-and-state.md](references/rules-and-state.md)

### 3. Feedback

**Core concept:** Feedback communicates the rules of the microinteraction to the user. It answers: "What is happening right now?" Feedback can be visual (color, animation, movement), auditory (clicks, chimes), or haptic (vibrations). The key constraint is showing only what matters -- minimal, meaningful, contextual.

**Why it works:** Without feedback, users cannot tell if their action registered, if the system is working, or if the operation succeeded. Feedback closes the Gulf of Evaluation. Too little feedback creates anxiety; too much creates noise. The right feedback at the right time makes interactions feel responsive, trustworthy, and alive.

**Key insights:**
- Feedback must be immediate -- under 100ms for direct manipulation
- Use the least noticeable feedback that still communicates: a subtle color change before a modal dialog
- Feedback should map to the significance of the event: small action = small feedback, big result = big feedback
- Visual feedback is primary; audio and haptic are supplementary and should never be the only channel
- Progress indicators reduce perceived wait time even when actual time stays the same
- Feedback should use existing elements when possible -- animate the button, not a separate notification

**Product applications:**

| Context | Application | Example |
|---------|-------------|---------|
| **Button press** | Visual state change on click | Button depresses, color shifts, text changes to "Saving..." |
| **Form validation** | Inline feedback as user types | Green checkmark appears next to valid email field |
| **File upload** | Progress indicator with percentage | Progress bar fills; percentage and estimated time shown |
| **Error state** | Contextual error near the source | Red border on field + message "Password must be 8+ characters" |
| **Success confirmation** | Brief, non-blocking affirmation | Checkmark animation replaces submit button for 1.5 seconds |

**Ethical boundary:** Feedback should be honest. Do not use fake progress bars, manipulative countdown timers, or deceptive completion percentages to create false urgency.

See: [references/feedback-patterns.md](references/feedback-patterns.md)

### 4. Loops and Modes

**Core concept:** Loops de