MicrointeractionsCAUTION

Wondel.ai Agent Skills — Business, Marketing, UX & Coding Frameworks from Bestselling Books. 50 skills + 12 guided journeys for Claude Code, Codex, Cursor & other agentskills.io agents.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: microinteractions
description: 'Design the small details -- triggers, rules, feedback, loops and modes -- that separate good products from great ones. Use when the user mentions "microinteraction", "button feedback", "loading state", "toggle design", "animation detail", "state transitions", "input feedback", "the interface feels dead", "make the UI feel responsive", or "add polish to interactions". Also trigger when designing form-validation responses, progress indicators, confirmation dialogs, or any element where the user expects immediate feedback. Covers trigger design, state rules, feedback mechanisms, and progressive loops. For overall UI polish, see refactoring-ui. For affordance design, see design-everyday-things.'
license: MIT
metadata:
  author: wondelai
  version: "1.4.1"
---

# 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](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:**

| 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 h

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (5)

.agents/skills/37signals-way

.agents/skills/architecture-optimization

.agents/skills/blue-ocean-strategy

.agents/skills/clean-architecture

.agents/skills/clean-code

Gates applied: no_behavioural_pass.