Mmcp.market

microinteractions skill

by wondelai·wondelai/skills·2.3k stars·MIT

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.

A100/100content scan

Is the microinteractions skill safe?

Clean: nothing in its files matched our rules. We read 7 files in the folder on 2026-09-28.

No findings.

Install the microinteractions skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description. 

git clone --depth 1 https://github.com/wondelai/skills.git /tmp/skills
mkdir -p ~/.claude/skills
cp -r /tmp/skills/plugins/ux-design/skills/microinteractions ~/.claude/skills/microinteractions
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

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:

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

See: 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:

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 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 or the system is working, so they retap, abandon, or distrust the result. Feedback is what converts an invisible system state into a perceived response.

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:

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

See: references/feedback-patterns.md for feedback channels, timing, and preventing overload.

4. Loops and Modes

Core concept: Loops are the meta-rules over time -- does the interaction change after the 100th use, expire, adapt? Modes are forks in the rules where the same control temporarily behaves differently (edit mode vs. view mode).

Why it works: Thoughtful loops let microinteractions mature gracefully -- reducing friction for power users while staying discoverable for new ones. Modes, used sparingly, let one control serve multiple purposes without cluttering the interface.

Key insights:

  • Open loops continue until explicitly stopped (a repeating alarm); closed loops run once and end (a timer)
  • Long loops change the interaction over time: first use shows a tooltip; the 50th does not
  • Progressive reduction: strip away scaffolding as users demonstrate mastery
  • Modes are dangerous -- they violate "same action, same result"; minimize them and make the current mode highly visible (Caps Lock indicator, edit banner)

Product applications:

Ethical boundary: Loops should benefit the user, not the business -- never adapt loops to ramp up notifications or make opt-outs progressively harder.

See: references/loops-modes.md for long loops, mode errors, and progressive complexity.

5. Signature Moments

Core concept: A signature moment is a microinteraction so distinctive it becomes part of the product's identity -- the Facebook Like, slide-to-unlock, Slack's loading messages. Every product should have one or two; not every interaction should be one.

Why it works: Signature moments create emotional memory and make products feel crafted rather than assembled. They are what users demonstrate first when describing your product to others.

Key insights:

  • Put signature moments on frequent, visible actions -- not buried settings
  • Functional first, delightful second -- never sacrifice usability for novelty
  • Animation, sound, and copy are the three most common tools
  • Align with brand personality: playful brands get playful moments
  • Apply the removal test: if users would not miss it, it is decoration, not signature

Product applications:

Ethical boundary: Never block input or the next step behind a non-skippable celebration animation -- let the user tap through the confetti to proceed.

See: references/signature-moments.md for when to invest and making mundane interactions delightful.

6. Reducing and Simplifying

Core concept: The best microinteraction is barely noticed because it is so simple and fast. Reduce (fewer options, steps, decisions), then simplify what remains until it feels effortless.

Why it works: Every option, field, and decision adds cognitive load -- users do not want to configure a toggle, they want it to work. The most elegant microinteractions have zero configuration, one action, and immediate results.

Key insights:

  • If a microinteraction needs instructions, it is too complex
  • Remove options with smart defaults -- pick the best choice and commit to it
  • Collapse multi-step interactions into a single action where possible
  • Use progressive disclosure: show simple first, reveal complexity only on request
  • Keep rule count proportional to frequency of use: common actions need few rules

Product applications:

Ethical boundary: A "smart default" must serve the user, not the business -- never pre-check marketing opt-ins, paid add-ons, or data-sharing as the default choice.

Common Mistakes

Quick Diagnostic

Audit any microinteraction:

More skills from wondelai/skills

  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.

All agent skills → · MCP servers