microinteractions

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", or "interaction polish". Covers trigger design, state rules, feedback mechanisms, and progressive loops. For overall UI polish, see refactoring-ui. For affordance design, see design-everyday-things.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "microinteractions" with this command: npx skills add wondelai/skills/wondelai-skills-microinteractions

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:

ContextApplicationExample
Toggle controlsManual trigger with binary stateiOS Wi-Fi switch: tap to toggle, position shows state
Pull-to-refreshHidden gesture trigger with visible affordancePulling down past threshold triggers refresh animation
System alertsSystem trigger on condition metLow battery notification at 20% threshold
Search fieldsManual trigger with auto-suggest system triggerTyping initiates search; results appear as system trigger
Hover revealsManual trigger using proximityToolbar 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

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:

ContextApplicationExample
Password strengthRules evaluate input in real-timeMeter updates as user types; color shifts from red to green
Character counterRule constrains and displays remainingTwitter/X: counter decreases, turns red at limit
Volume controlRule maps input to output with constraintsSlider snaps to 5% increments; long-press mutes
Shopping cartRules manage quantity and stateCannot go below 1; shows "max 10" at limit
Undo actionRule sets time window for reversalGmail "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

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:

ContextApplicationExample
Button pressVisual state change on clickButton depresses, color shifts, text changes to "Saving..."
Form validationInline feedback as user typesGreen checkmark appears next to valid email field
File uploadProgress indicator with percentageProgress bar fills; percentage and estimated time shown
Error stateContextual error near the sourceRed border on field + message "Password must be 8+ characters"
Success confirmationBrief, non-blocking affirmationCheckmark 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

4. Loops and Modes

Core concept: Loops determine the meta-rules of a microinteraction -- what happens over time. Does the interaction change after the 100th use? Does it expire? Does it adapt? Modes are forks in the rules -- temporary states where the microinteraction behaves differently (e.g., edit mode vs. view mode).

Why it works: Products that never evolve feel stale. Products that shift behavior unpredictably feel unreliable. Thoughtful loops let microinteractions mature gracefully -- reducing friction for power users while remaining discoverable for new ones. Modes, when used sparingly, let a single 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 microinteraction over time: first use might show a tooltip; 50th use does not
  • Progressive reduction: strip away scaffolding as users demonstrate mastery
  • Modes are dangerous -- they violate the principle that the same action should produce the same result
  • If you must use modes, make the current mode extremely visible (Caps Lock indicator, edit mode banner)
  • Avoid mode errors by minimizing the number of modes and making mode transitions deliberate

Product applications:

ContextApplicationExample
Onboarding tooltipsLong loop removes hints after N usesFirst 3 sessions show "Swipe to archive"; then stop
Alarm clockOpen loop repeats daily until disabledAlarm fires every weekday at 7am until toggled off
Text editingMode: view vs. editBanner reads "Editing" with a "Done" button to exit mode
Smart defaultsLong loop learns preferencesEmail app learns you always CC your manager; suggests it
Notification frequencyLong loop adapts deliveryReduces notifications if user ignores 5 in a row

Ethical boundary: Loops should benefit the user, not the business. Do not use adaptive loops to increase notification frequency or make opt-outs progressively harder.

See: references/loops-modes.md

5. Signature Moments

Core concept: A signature moment is a microinteraction so distinctive that it becomes part of the product's identity. It transforms a functional necessity into a brand-defining detail -- the Facebook Like thumbs-up, the iPhone slide-to-unlock, Slack's loading messages. Not every microinteraction should be a signature moment, but every product should have one or two.

Why it works: Signature moments create emotional memory. They make products feel crafted rather than assembled. When users describe your product to others, signature moments are what they demonstrate first. They turn utility into personality.

Key insights:

  • Signature moments work best on frequent, visible actions -- not buried settings
  • They must be functional first, delightful second -- never sacrifice usability for novelty
  • Animation, sound, and copy are the three most common tools for creating signature moments
  • Signature moments should align with brand personality: playful brands get playful moments
  • Restraint matters -- if everything is a signature moment, nothing is
  • Test whether users would miss the detail if it were removed; if not, it is decoration, not signature

Product applications:

ContextApplicationExample
Social reactionAnimated response to engagementFacebook Like: thumbs-up animates with particles
Loading stateBranded waiting experienceSlack: rotating quotes during load
CompletionCelebratory confirmationStripe payment: animated checkmark with confetti
Empty statePersonality in absence of contentDropbox: illustrated scenes with friendly copy
Error recoveryGraceful failure with personalityGitHub 404: parallax Octocat illustration

Ethical boundary: Signature moments should never obscure important information or delay the user to show off an animation. Function always precedes delight.

See: references/signature-moments.md

6. Reducing and Simplifying

Core concept: The best microinteraction is one the user barely notices because it is so simple and fast. Reduction means doing less -- fewer options, fewer steps, fewer decisions. Simplifying means making what remains feel effortless. The goal is to distill every microinteraction to its absolute essence.

Why it works: Every option, field, and decision adds cognitive load. Users do not want to configure a toggle switch. They want the toggle to work. Reduction fights feature creep at the smallest level. 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 by choosing 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 when requested
  • Avoid "settings within settings" -- if a microinteraction has its own preferences, reconsider
  • The number of rules should be proportional to the frequency of use: common actions need few rules

Product applications:

ContextApplicationExample
Smart defaultsEliminate configurationCamera app defaults to photo mode, not settings
Inline editingRemove modal, edit in placeSpreadsheet cell: click to edit, Enter to save
Auto-detectionSystem handles instead of userCredit card type detected from first digits
Single actionOne tap replaces multi-step flowDouble-tap to like instead of open menu, select reaction
Anticipatory designPredict and pre-fillShipping form pre-fills city and state from ZIP code

Ethical boundary: Simplification should not remove user control over meaningful choices. Do not auto-opt users into features that benefit the business at the user's expense.

See: references/trigger-design.md for reducing trigger complexity.

Common Mistakes

MistakeWhy It FailsFix
No feedback on actionUsers do not know if their tap registeredAdd immediate visual state change to every interactive element
Overdesigning simple momentsComplex animations slow down frequent actionsReserve rich animation for infrequent, high-impact moments
Ignoring edge casesInteraction breaks at zero, at max, or on double-tapMap every state: empty, loading, partial, full, error, disabled
Invisible triggersUsers cannot discover functionalityPair gesture triggers with a visible alternative
Mode errorsSame action produces different results depending on hidden stateMake current mode visible; minimize number of modes
Ignoring long loopsInteraction feels the same on day 1 and day 100Use progressive reduction to streamline for returning users
Feedback overloadEvery action triggers a toast, sound, or animationUse the smallest feedback that communicates; reserve big feedback for big events
Fake progress indicatorsUsers feel deceived when they discover the bar is fakeUse honest, deterministic progress; show indeterminate spinner when unknown

Quick Diagnostic

Audit any microinteraction:

QuestionIf NoAction
Is there a clear, discoverable trigger?Users cannot initiate the interactionAdd a visible control or affordance
Does the trigger show its current state?Users cannot tell if it is on, off, or loadingAdd distinct visual states for every trigger state
Are the rules simple and predictable?Users are confused by what happenedSimplify rules; match platform conventions
Is there immediate feedback?Users question whether their action workedAdd visual response within 100ms
Does feedback match the significance of the event?Small actions feel dramatic or big actions feel trivialScale feedback to match event importance
Does the interaction evolve over time?Power users are still seeing beginner hintsAdd progressive reduction through long loops
Is the interaction free of unnecessary modes?Users perform wrong action in wrong modeRemove modes or make current mode highly visible
Could a first-time user figure it out without help?Interaction needs explanationSimplify or add a one-time hint via long loop

Reference Files

  • trigger-design.md: Manual and system triggers, trigger affordances, trigger states, invisible trigger design, placement and visibility
  • rules-and-state.md: Defining rules, state management, constraints, error states, edge cases
  • feedback-patterns.md: Visual, audio, and haptic feedback, timing, progressive disclosure, preventing overload
  • loops-modes.md: Open and closed loops, long loops, modes, mode errors, progressive complexity
  • signature-moments.md: Brand-defining microinteractions, examples, when to invest, making mundane interactions delightful
  • case-studies.md: Detailed design breakdowns of form submission, toggle/switch, pull-to-refresh, loading states, and notifications

Further Reading

This skill is based on Dan Saffer's definitive guide to designing the details that separate good products from great ones:

About the Author

Dan Saffer is a designer, author, and design leader who has led design teams at Twitter, Jawbone, and Smart Design. He is known for his work on interaction design at the detail level -- the small, contained moments that make up the bulk of user experience. Microinteractions codified a framework that design teams at companies worldwide use to audit, design, and improve the small details that make products feel polished and alive. Saffer has also authored Designing for Interaction and Designing Gestural Interfaces, and he speaks regularly at design conferences on the craft of interaction design.

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

refactoring-ui

No summary provided by upstream source.

Repository SourceNeeds Review
General

cro-methodology

No summary provided by upstream source.

Repository SourceNeeds Review
General

web-typography

No summary provided by upstream source.

Repository SourceNeeds Review