microinteractions

# Microinteractions Framework

Design the tiny, contained product moments users touch 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 moment built around a single use case -- changing a setting, syncing data, picking a password -- so small that users rarely think about it consciously, but they feel it. 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.** Rate microinteractions 0-10 against the principles below: a 10/10 gives every interactive moment a deliberate trigger, clear rules, immediate feedback, and thoughtful loop/mode behavior. Always state the current score and the 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 initiates a microinteraction -- manual (tap, click, swipe, voice command) or system-initiated (time, location, incoming data, error state). It is the front door of every microinteraction.

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

**Key insights:**
- A trigger must communicate three things: that it exists, what it does, and what state it is in
- Match trigger prominence to action importance -- high-stakes actions need prominent triggers
- Pair invisible triggers (gestures, shake, proximity) with a visible alternative for discoverability
- Make trigger states -- default, hover, active, disabled, loading -- 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 with visible affordance | Pull past threshold triggers refresh animation |
| **System alerts** | System trigger on condition met | Low battery notification at 20% threshold |

**Ethical boundary:** Never hide critical triggers behind gestures or invisible interactions without a visible fallback.

See: [references/trigger-design.md](references/trigger-design.md) for trigger affordances, states, placement, and reducing trigger complexity.

### 2. Rules

**Core concept:** Rules define what happens once a microinteraction is triggered -- the sequence of events, constraints, processing, and ending. Users never see rules directly, but they feel when rules are wrong.

**Why it works:** Rules create the mental model users build about how the interaction works. Consistent rules that match expectations feel natural; violations -- a toggle that does not toggle, a slider that jumps in value -- destroy trust.

**Key insights:**
- Define the goal of the microinteraction first, then derive rules from it
- Match existing mental models and platform conventions
- Constrain inputs to prevent errors: limit character counts, set value ranges, enforce formats
- Handle edge cases explicitly: zero, maximum, repeated triggers, interruption

**Product applications:**

| Context | Application | Example |
|---------|-------------|---------|
| **Password strength** | Rules evaluate input in real-time | Meter updates as user types; color shifts red to green |
| **Character counter** | Rule constrains and shows remaining | Twitter/X: counter decreases, turns red at limit |
| **Undo action** | Rule sets time window for reversal | Gmail "Undo send" available for 30 seconds |

**Ethical boundary:** Keep rules transparent and predictable -- never hide rules that manipulate behavior, such as making unsubscribe harder than subscribe.

See: [references/rules-and-state.md](references/rules-and-state.md) for state management, constraints, error states, and edge cases.

### 3. Feedback

**Core concept:** Feedback communicates the rules to the user, answering "What is happening right now?" -- visually (color, animation, movement), aurally (clicks, chimes), or haptically (vibration). Show only what matters: minimal, meaningful, contextual.

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

**Key insights:**
- Feedback must be immediate -- under 100ms for direct manipulation
- Use the least noticeable feedback that still communicates, and prefer animating existing elements (the button itself, not a separate toast)
- Scale feedback to event significance: small action = small feedback, big result = big feedback
- Visual feedback is primary; audio and haptic are supplementary, never the only channel
- Progress indicators reduce perceived wait time even when actual time is unchanged

**Product applications:**

| Context | Application | Example |
|---------|-------------|---------|
| **Button press** | Visual state change on click | Button depresses, color shifts, text becomes "Saving..." |
| **Form validation** | Inline feedback as user types | Green checkmark next to valid email field |
| **Error state** | Contextual error near the source | Red border on field + "Password must be 8+ characters" |

**Ethical boundary:** Keep feedback honest -- no fake progress bars, manipulative countdowns, or deceptive completion