Microinteractions Framework

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. Score by how many of the 8 Quick Diagnostic rows the microinteraction passes — score = round(passed / 8 × 10), then read the band:

• 9-10 = passes all 8 rows: deliberate discoverable trigger with visible states, simple predictable rules, sub-100ms feedback scaled to event significance, evolves over time, mode-free or mode-visible, learnable without help.
• 5-6 = 4-5 rows pass: it works but has a generic feel -- e.g. feedback exists but is uniform, or the trigger lacks distinct states.
• <=3 = 2 or fewer rows pass: missing feedback, invisible triggers, or hidden modes that break trust.

Always state the current score, which diagnostic rows failed, and the specific fix for each.

The Microinteraction Structure

Six areas of focus for designing world-class microinteractions. See references/case-studies.md when you want a full four-part breakdown of a real pattern -- form submission, toggle/switch, pull-to-refresh, loading states, and notifications, each from first use through edge cases.

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: A trigger's prominence and labeling set the user's expectation before they act -- a button that reads "Delete" in red signals an irreversible, high-stakes outcome, so feedback that follows feels predictable rather than surprising.

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: