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:

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

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 obscure important information or delay the user to show off an animation -- function precedes delight.

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: Do not auto-opt users into business-serving features or remove control over meaningful choices.

Common Mistakes

Quick Diagnostic

Audit any microinteraction:

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 with details:

• *"Microinteractions: Designing with Details"* by Dan Saffer

About the Author

Dan Saffer is a designer and design leader who has led teams at Twitter, Jawbone, and Smart Design. His book Microinteractions codified the framework design teams worldwide use to audit, design, and improve the small details that make products feel polished and alive. He also wrote Designing for Interaction and Designing Gestural Interfaces.

---

Credits & Attribution

This skill is based on the excellent work by [wondelai](https://github.com/wondelai).

Original repository: https://github.com/wondelai/skills

Copyright (c) wondelai - Microinteractions framework adaptation of Dan Saffer's Microinteractions: Designing with Details (MIT License)

Special thanks to wondelai for their generous open-source contributions, which helped shape this skill collection. Adapted by webconsulting.at for this skill collection

Microinteraction Case Studies

Detailed design breakdowns of common UI patterns, analyzed through the four-part microinteraction structure: Trigger, Rules, Feedback, and Loops & Modes. Each case study documents the interaction from first use through edge cases, providing a practical blueprint for implementation.

Table of Contents

1. Case Study 1: Form Submission 2. Case Study 2: Toggle / Switch 3. Case Study 3: Pull-to-Refresh 4. Case Study 4: Loading States 5. Case Study 5: Notifications (Toast / Snackbar) 6. Cross-Cutting Patterns

---

Case Study 1: Form Submission

A form submission microinteraction covers the moment from when the user taps "Submit" to when they receive confirmation of success or details of failure. It is one of the highest-stakes microinteractions because users have invested time and data.

The Four Parts

Trigger:

• Manual trigger: "Submit" button (primary action, full-width or prominent)
• Keyboard trigger: Enter key in last field (convention, not always expected)
• System trigger: Auto-save draft after 30 seconds of inactivity (background)

Rules: 1. On trigger, validate all required fields client-side before sending to server 2. If validation fails, prevent submission and highlight first invalid field 3. If validation passes, disable submit button and show loading state 4. Send data to server 5. On server success (200), show success feedback and redirect or reset form 6. On server error (4xx/5xx), show error message and preserve all input 7. On network timeout (>15 seconds), show retry option with preserved input

Feedback:

Loops & Modes:

• Auto-save loop: draft saved to local storage every 30 seconds (open loop)
• Long loop: after 3+ submissions, hide optional tooltips and field hints
• No modes (single-purpose interaction)

Edge Cases

Implementation Notes

---

Case Study 2: Toggle / Switch

A toggle is a binary microinteraction: on or off. Despite its apparent simplicity, a well-designed toggle requires careful attention to state communication, animation timing, and accessibility.

The Four Parts

Trigger:

• Manual trigger: tap/click anywhere on the toggle (track or thumb)
• Keyboard trigger: Space bar when toggle is focused
• Drag trigger: drag thumb from one position to the other
• System trigger: external state change (admin disables feature remotely)

Rules: 1. On trigger, immediately start transition animation 2. If action requires server confirmation, send request in background 3. Toggling on may trigger additional UI (reveal settings, enable features) 4. Toggling off may trigger confirmation dialog for destructive changes 5. If server rejects the change, revert toggle to previous state with error message 6. Rapid toggling (clicking multiple times fast) should debounce: only the final state is sent

Feedback:

Loops & Modes:

• No traditional loop (single action)
• Long loop: if toggle controls a feature with settings, first 3 toggles might show a tooltip explaining the feature
• No modes

Animation Specification

Accessibility

Edge Cases

---

Case Study 3: Pull-to-Refresh

Pull-to-refresh is a gesture-triggered microinteraction invented by Loren Brichter for Tweetie (acquired by Twitter). It transforms a natural gesture (pulling down on a list) into a data refresh. It is one of the most widely adopted microinteraction patterns in mobile design.

The Four Parts

Trigger:

• Manual trigger: pull down on a scrollable list past a threshold (~60pt)
• The trigger is invisible -- no button exists; the gesture is the trigger
• System fallback: auto-refresh on app foreground after X minutes (system trigger)

Rules: 1. User must be scrolled to the top of the list for pull to activate 2. Pulling down below threshold shows visual hint but does not trigger refresh 3. Pulling past threshold (typically 60-80pt) "locks" the refresh 4. Releasing after passing threshold triggers the refresh request 5. Releasing before threshold snaps back with no refresh 6. While refreshing, spinner remains visible at top; list is still scrollable 7. On data received, new content animates into list; spinner dismisses 8. On failure, spinner dismisses; error message appears briefly 9. Minimum spinner display: 500ms (prevents flash for fast connections)

Feedback:

Loops & Modes:

• Auto-refresh loop: if user has not pulled-to-refresh in 5+ minutes and returns to app, auto-refresh fires (system trigger)
• Long loop: for first 3 uses on a new device, show a subtle "Pull down to refresh" hint text
• Rate limiting rule: ignore pull-to-refresh if last refresh was < 5 seconds ago
• No modes

Discoverability Strategy

Pull-to-refresh has zero visible affordance -- it relies entirely on platform convention. For apps where users might not know the gesture:

Platform-Specific Implementations

---

Case Study 4: Loading States

Loading is not a single microinteraction but a family of patterns for communicating "the system is working." The design challenge is keeping users informed and engaged during a period they cannot control.

Loading Pattern Selection

Skeleton Screen Design

Trigger: System trigger -- content request initiated.

Rules: 1. Show skeleton immediately on navigation (within 100ms) 2. Skeleton shapes must match the final layout precisely 3. Use subtle pulse animation on skeleton shapes (opacity 0.3 to 0.6, 1.5s loop) 4. Load content progressively: text first, then images 5. Crossfade from skeleton to real content (200ms) 6. Never show skeleton for content already in cache

Skeleton Visual Specification:

Progress Bar Design

Trigger: System trigger -- long operation begins.

Rules: 1. Appear within 200ms of operation start 2. Progress must be real (based on actual progress, not fake animation) 3. Never go backward (if real progress reverses, pause at current point) 4. Final 5% should be server confirmation, not client processing 5. On completion, bar fills to 100%, brief pause, then success state

Feedback:

Loading State Accessibility

---

Case Study 5: Notifications (Toast / Snackbar)

Notifications are transient microinteractions that communicate system events without requiring full user attention. They appear, convey a message, and disappear -- but the design details determine whether they are helpful or infuriating.

The Four Parts

Trigger:

• System trigger: action completes (save, send, delete)
• System trigger: external event occurs (new message, status change)
• System trigger: error detected (network loss, permission denied)
• Manual trigger: user action with reversible outcome (delete triggers "Undo" toast)

Rules: 1. Appear in a consistent position (bottom-center for mobile, bottom-left or top-right for desktop) 2. Stack if multiple appear simultaneously (limit to 3 visible; queue additional) 3. Auto-dismiss after 5-8 seconds for informational; persist for errors until acknowledged 4. Slide in with animation (300ms); slide out on dismiss (200ms) 5. Must not cover critical UI elements (primary actions, navigation) 6. If toast contains an action ("Undo"), the action must be available for the entire display duration 7. Dismissable via swipe (mobile) or close button (desktop)

Feedback:

Loops & Modes:

• Stacking loop: if user triggers 5 actions rapidly, queue toasts; show max 3 at once
• Long loop: if same notification appears 3+ times in a session, batch: "3 items saved"
• Consolidation: "3 files uploaded" instead of three separate "File uploaded" toasts
• No modes

Toast Layout Specification

┌────────────────────────────────────────────────┐
│  [Icon]  Message text here          [Action] [X]│
│          Secondary text (optional)              │
└────────────────────────────────────────────────┘

Animation Specification

Accessibility

Edge Cases

---

Cross-Cutting Patterns

Patterns That Apply Across All Case Studies

Feedback Patterns for Microinteractions

Feedback is how a microinteraction communicates its rules to the user. It answers the most fundamental question in any interaction: "What just happened?" Without feedback, users operate in the dark -- unsure if their action registered, if the system is working, or if the result was what they intended. Feedback bridges the Gulf of Evaluation by making the invisible visible.

The Feedback Hierarchy

Not all feedback is equal. The type, intensity, and duration of feedback should match the significance of the event.

The Minimum Feedback Rule

Use the least amount of feedback that still communicates the message. A hover state does not need a sound effect. A successful save does not need a modal dialog. A button press does not need a full-screen animation. Escalate feedback only when the event demands it.

---

Visual Feedback

Visual feedback is the primary feedback channel for nearly every microinteraction. It is silent, non-intrusive, and universally accessible (when designed with sufficient contrast).

Color Changes

Animations

Animation Principles for Microinteractions

1. Purpose over decoration. Every animation should communicate something: state change, direction, connection, or confirmation. If you cannot articulate what the animation communicates, remove it.

2. Interruptible. If the user acts before an animation completes, the animation should yield to the new action. Never make users wait for an animation to finish.

3. Consistent timing. Use a small set of durations (100ms, 200ms, 300ms, 500ms) and apply them consistently by category. Do not use random durations.

4. Physics-based easing. Use ease-out for elements entering (decelerating arrival), ease-in for elements leaving (accelerating departure), and ease-in-out for elements that stay but change state.

Progress Indicators

Progress Indicator Selection Guide

---

Audio Feedback

Audio feedback provides confirmation through sound. It is powerful when visual attention is elsewhere, but it is easily annoying and must be used sparingly.

When Audio Feedback Is Appropriate

Audio Feedback Design Rules

1. Short. Sounds should be 50-200ms for confirmations, up to 1 second for completions. Never longer.

2. Quiet. Default volume should be unobtrusive. Users should be able to disable all sounds.

3. Distinct. Success and error sounds must be obviously different -- do not rely on subtle pitch changes.

4. Non-verbal. Avoid spoken words in feedback sounds (they do not scale across languages and are slow). Pure tones or abstract sounds work best.

5. Consistent. Use the same sound for the same type of event across the entire product. Success always sounds the same.

Audio Feedback Patterns

---

Haptic Feedback

Haptic feedback uses vibration or force feedback to communicate through touch. It is available on mobile devices and some game controllers, laptops, and wearables.

Haptic Feedback Patterns

Haptic Design Rules

1. Pair with visual. Haptic feedback should always accompany visual feedback, never replace it. Some devices have haptics disabled, and users with motor impairments may not feel vibrations.

2. Match intensity to significance. Light tap for toggles. Medium for confirmations. Heavy for warnings. Never heavy for routine actions.

3. Use sparingly. Constant vibration is annoying and drains battery. Reserve haptics for moments where tactile confirmation adds genuine value.

4. Respect system settings. Always check if the user has disabled haptic feedback at the system level. Never override this preference.

---

Feedback Timing

When feedback occurs is as important as what feedback occurs. The human perception system has specific thresholds that determine whether feedback feels instant, delayed, or broken.

Perception Thresholds

Optimistic UI Pattern

Show the result immediately and correct later if the action fails. This makes the interface feel instant even when the server takes time.

When to use optimistic UI:

• Action is very likely to succeed (> 99%)
• Reverting is possible and not confusing
• The action is low-stakes (not a payment or deletion)

When NOT to use optimistic UI:

• Action has a significant failure rate
• Action is irreversible
• Reverting would be confusing (e.g., message appears then disappears)

---

Progressive Disclosure in Feedback

Not all feedback needs to appear at once. Progressive disclosure reveals information in layers, starting with the most important.

Feedback Layering

Progressive Error Disclosure

---

Preventing Feedback Overload

Too much feedback is as bad as too little. When every action triggers a toast notification, animation, and sound, users become desensitized and miss the feedback that actually matters.

Signs of Feedback Overload

Feedback Reduction Strategies

1. Consolidate. Instead of four separate toast messages for four file uploads, show one: "4 files uploaded successfully."

2. Delay and batch. Accumulate minor events and present them as a summary: "While you were away: 3 likes, 2 comments, 1 share."

3. Tier by priority. Define three tiers of feedback intensity and assign every event type to a tier:

4. Respect context. Reduce feedback when:

• User is performing rapid sequential actions (bulk editing)
• System is in background/minimized
• User has indicated preference for fewer notifications

---

Feedback Accessibility

Feedback must work for all users, including those who cannot see animations, hear sounds, or feel vibrations.

Accessibility Requirements

Accessibility Feedback Checklist

• [ ] Can every state change be perceived without color alone (shape, text, or icon accompanies color)?
• [ ] Are error messages announced to screen readers via aria-live="assertive"?
• [ ] Are success messages announced via aria-live="polite"?
• [ ] Do animations respect prefers-reduced-motion media query?
• [ ] Is all audio feedback accompanied by a visual equivalent?
• [ ] Can keyboard users perceive which element has focus?
• [ ] Do loading states have an accessible label ("Loading...", role="status")?
• [ ] Are progress bars accessible (role="progressbar", aria-valuenow, aria-valuemin, aria-valuemax)?

---

Feedback Design Checklist

• [ ] Does every interactive element provide immediate visual feedback on activation?
• [ ] Is feedback proportional to event significance (small action = small feedback)?
• [ ] For operations > 300ms, is there a loading indicator?
• [ ] For operations > 10 seconds, is there a progress bar?
• [ ] Do error messages explain what happened and how to fix it?
• [ ] Is success feedback brief and non-blocking (does not require dismissal)?
• [ ] Are animations under 500ms and interruptible?
• [ ] Is audio feedback optional and disabled by default (except essential alerts)?
• [ ] Does haptic feedback match system settings?
• [ ] Are all feedback channels accessible (visual + ARIA + reduced-motion support)?

Loops and Modes in Microinteractions

Loops and modes are the long-term behavior of microinteractions. While triggers, rules, and feedback handle the moment-to-moment experience, loops and modes determine how an interaction evolves over time and how it adapts to different contexts. They are the mechanism for making microinteractions feel alive -- growing with the user, adapting to behavior, and avoiding stagnation.

Understanding Loops

A loop is a cycle that a microinteraction goes through repeatedly. The key question is: what happens when the microinteraction is triggered again? Does it behave the same way? Does it adapt? Does it expire?

Open Loops vs. Closed Loops

Designing Open Loops

Open loops run continuously and need careful management to avoid becoming annoying or resource-wasteful.

Design considerations:

Designing Closed Loops

Closed loops have a natural endpoint. The design challenge is communicating progress and handling completion.

Design considerations:

---

Long Loops: Behavior Over Time

Long loops are the most powerful -- and most neglected -- aspect of microinteraction design. A long loop asks: how should this microinteraction behave differently the 100th time compared to the first time?

Progressive Reduction

Progressive reduction means removing scaffolding as users demonstrate mastery. The microinteraction starts helpful and becomes streamlined.

Implementation strategies:

Adaptive Long Loops

Adaptive loops change the microinteraction based on accumulated user behavior patterns.

Long Loop Design Principles

1. Never degrade core functionality. Progressive reduction should remove scaffolding, not features. The base action must always work.

2. Provide a way back. If a tooltip was hidden after 10 uses, provide a "?" icon or help menu to resurface it.

3. Track per-feature, not globally. A user who is expert at one feature may be a beginner at another. Track usage at the microinteraction level.

4. Avoid the uncanny valley. If the system adapts based on behavior, the changes should either be invisible (smart defaults) or transparent (explicit recommendations). Half-visible adaptation feels creepy.

5. Test the 100th use. Most designers test the first use. Few test the 100th. Run the complete interaction 100 times and evaluate: does it still feel right? Is there unnecessary friction for an expert?

---

Understanding Modes

A mode is a temporary state where the same trigger produces a different result. In edit mode, clicking a paragraph selects it for editing. In view mode, clicking the same paragraph does nothing (or follows a link). Modes are powerful but dangerous.

Why Modes Are Dangerous

When Modes Are Justified

Despite their dangers, modes are sometimes the right design choice:

Mode Design Guidelines

1. Make the current mode unmistakably visible.

2. Make mode transitions deliberate. Entering and exiting a mode should require a conscious action (button click, keyboard shortcut), not happen accidentally (hover, proximity).

3. Minimize the number of modes. Every mode doubles the testing surface. Two modes mean 2x testing. Five modes mean 5x.

4. Provide mode escape. Users must always have a clear, obvious way to exit a mode. The escape route should be visible at all times while in the mode.

---

Avoiding Mode Errors

Mode errors occur when users perform the correct action in the wrong mode. They are one of the most frustrating user experiences because users did the right thing -- the system responded wrong.

Prevention Strategies

Spring-Loaded Modes

Spring-loaded modes (also called quasi-modes) are temporary: they exist only while the user holds a trigger. When the trigger is released, the mode exits automatically. This eliminates mode amnesia because the user is physically reminded of the mode through the held action.

---

Loop and Mode Combinations

Loops and modes can interact. A mode might change the loop behavior, or a loop might trigger a mode transition.

Common Combinations

---

Real-World Loop and Mode Examples

Alarm Clock

Text Editor (Google Docs)

Smart Thermostat (Nest)

Notification System

---

Loop and Mode Checklist

Loops

• [ ] Is this an open or closed loop? Is that the right choice?
• [ ] For open loops: can users stop or adjust the loop?
• [ ] For closed loops: is progress shown? What happens at completion?
• [ ] Have you designed the long loop (behavior at 1st, 10th, 100th use)?
• [ ] Does the interaction use progressive reduction for experienced users?
• [ ] Can users resurface removed scaffolding if they need help?
• [ ] Is loop frequency appropriate for user need and system resources?

Modes

• [ ] Is a mode necessary, or can you avoid it entirely?
• [ ] Is the current mode visible at all times?
• [ ] Is mode entry deliberate (not accidental)?
• [ ] Is there an obvious, always-visible escape from every mode?
• [ ] Have you tested for mode errors (right action, wrong mode)?
• [ ] Could you use a spring-loaded mode instead of a toggle mode?
• [ ] Is the total number of modes three or fewer?

Rules and State in Microinteractions

Rules are the invisible engine of a microinteraction. Once a trigger fires, rules determine what happens: what changes, in what order, with what constraints, and when the interaction ends. Users never see rules directly -- they experience their effects through feedback. But when rules are poorly designed, users feel it immediately: the toggle that does not remember its position, the slider that jumps to unexpected values, the form that erases their input on error.

What Rules Define

Every microinteraction's rules answer these questions:

---

Defining Rules: The Goal-First Method

Start with the goal, not the interface. What is the user trying to accomplish? Derive every rule from that goal.

Process

1. State the goal in one sentence: "The user wants to set their alarm time." 2. Identify the minimum inputs: Time (hour, minute), AM/PM, days of week. 3. Define the simplest path: Tap time, scroll to desired hour/minute, toggle AM/PM, select days, confirm. 4. Add constraints: Cannot set alarm in the past (today). Maximum 20 alarms. Minimum interval between alarms: 1 minute. 5. Handle failures: If alarm cannot be set (permission denied), show error with action to fix it. 6. Define the end state: Alarm is set, confirmation shown, alarm appears in list.

Rule Complexity vs. Frequency

---

State Management Within Microinteractions

Every microinteraction has state -- the current condition of the interaction at any given moment. Managing state well means users always know where they are, what happened, and what they can do next.

Core States of a Microinteraction

State Transition Map

Map every possible transition between states to ensure no combination is overlooked:

                    ┌─────────┐
          trigger   │  IDLE   │  reset
         ┌─────────→│         │←──────────┐
         │          └────┬────┘           │
         │               │ trigger        │
         │               ▼                │
         │         ┌──────────┐           │
         │         │  ACTIVE  │───────────┤
         │         │          │   cancel   │
         │         └────┬─────┘           │
         │           ┌──┴──┐              │
         │           │     │              │
         │       success  fail            │
         │           │     │              │
         │           ▼     ▼              │
         │     ┌────────┐ ┌───────┐       │
         │     │SUCCESS │ │ ERROR │       │
         │     │        │ │       │──retry─┘
         │     └───┬────┘ └───────┘
         │         │ timeout/dismiss
         └─────────┘

State Persistence

---

Constraints and Limitations

Constraints are rules that prevent errors by limiting what users can do. Well-designed constraints feel natural -- users do not notice them because the wrong action was never possible.

Types of Constraints in Microinteractions

Implementing Constraints Gracefully

Prevent rather than punish. The best constraint is one users never encounter because the wrong action was impossible:

Communicating Constraints

---

Error States

Error states are what happens when rules are violated or when the system fails. Error handling is where most microinteractions fall apart -- and where thoughtful design has the most impact on user trust.

Error State Principles

1. Preserve the user's work. Never erase input on error. If a form fails validation, keep everything the user typed.

2. Explain in human language. Not "Error 422: Unprocessable Entity" but "That email address looks incomplete. Did you forget the domain (e.g., @gmail.com)?"

3. Point to the problem. Show the error next to the field that caused it, not in a banner at the top of the page.

4. Offer a path forward. Every error message should suggest a fix or offer an alternative.

5. Time it right. Validate on blur (when the user leaves the field) for format errors; validate on submit for cross-field errors.

Error State Taxonomy

Error Recovery Patterns

---

Edge Cases

Edge cases are the boundary conditions where microinteractions often break. Designing for edge cases means asking "What happens when...?" for every unusual situation.

Essential Edge Cases to Design For

Edge Case Testing Methodology

1. Boundary values: Test at 0, 1, max-1, max, and max+1 for any numeric input. 2. Empty/full: Test with no data and with maximum data. 3. Speed: Test with instant response, 3-second delay, and 30-second delay. 4. Interruption: Test what happens when the user closes the browser, loses connection, or switches apps mid-action. 5. Repetition: Test triggering the same action 10 times rapidly. 6. Platform variety: Test on the slowest supported device and smallest supported screen.

---

What NOT to Allow

Deciding what NOT to allow is as important as deciding what to allow. Good rules prevent harmful, confusing, or destructive actions.

Actions to Prevent

The "Nothing Should Happen" Cases

Some trigger activations should produce no result -- and that is a deliberate rule:

---

State Design Checklist

• [ ] Have you defined every possible state (idle, active, success, error, disabled, partial)?
• [ ] Can users always tell which state the interaction is in?
• [ ] Have you mapped every state transition?
• [ ] Have you defined what is NOT allowed?
• [ ] Do constraints prevent errors instead of punishing them?
• [ ] Are error messages human-readable, specific, and actionable?
• [ ] Is user input preserved on error?
• [ ] Have you tested all edge cases (empty, max, rapid, offline, interrupted)?
• [ ] Is state persistence appropriate (ephemeral vs. session vs. permanent)?
• [ ] Can screen reader users perceive state changes?

Signature Moments in Microinteractions

A signature moment is a microinteraction so distinctive, so perfectly crafted, that it becomes inseparable from the product's identity. When someone describes Slack to a friend, they might mention the loading messages. When they think of the iPhone, they think of slide-to-unlock. When they use Stripe, they remember the animated checkmark on payment success. These are not features -- they are feelings, encoded in tiny interactive moments.

What Makes a Moment "Signature"

Not every polished microinteraction is a signature moment. Signature moments have specific characteristics that elevate them beyond mere polish.

Signature Moment Criteria

The Signature Moment Spectrum

---

Iconic Signature Moments: Detailed Analysis

Facebook Like (Reactions)

iPhone Slide-to-Unlock (Original)

Slack Loading Messages

Stripe Payment Success

GitHub 404 Page

---

Where to Create Signature Moments

Not every microinteraction can or should be a signature moment. Focus signature investment on the right locations.

High-Opportunity Locations

Low-Opportunity Locations (Avoid Signature Investment)

---

Creating Your Own Signature Moments

The Signature Moment Design Process

Step 1: Identify candidate moments

Map every microinteraction in your product and score each on two axes:

Step 2: Match to brand personality

Define your brand's personality in three adjectives and filter every signature moment decision through them.

Step 3: Choose the medium

Step 4: Prototype and test

---

Making Mundane Interactions Delightful

You do not need a grand gesture to create delight. Small touches on mundane interactions can accumulate into a product that just "feels right."

Delight Techniques for Everyday Microinteractions

Delight vs. Distraction Checklist

Before adding delight, verify it is not distraction:

• [ ] Does this add friction to the interaction? (If yes, reconsider)
• [ ] Will this become annoying after 100 uses? (If yes, tone it down)
• [ ] Does this delay the user from completing their task? (If yes, remove it)
• [ ] Does this work on slow devices and connections? (If no, make it progressive)
• [ ] Does this respect user accessibility settings? (If no, fix it)
• [ ] Could a user with no cultural context understand it? (If no, simplify it)

---

When to Invest in Signature Moments

Signature moments cost design and engineering time. Not every product stage justifies the investment.

Investment Timing

The "Would They Miss It" Test

The ultimate test of a signature moment: remove it and see if users notice and complain. If they do, it is truly signature. If they do not, it was decoration.

---

Signature Moment Pitfalls

---

Signature Moment Audit

Evaluate your product's signature moments:

• [ ] Can you identify 1-3 moments that define your product's personality?
• [ ] Do these moments occur on frequent, high-visibility interactions?
• [ ] Are they functional first, delightful second?
• [ ] Do they match your brand personality?
• [ ] Have you tested them at 1st, 10th, and 100th use?
• [ ] Do they work for all users (including those with accessibility needs)?
• [ ] Would users notice and complain if you removed them?
• [ ] Are you maintaining and refreshing them over time?

Trigger Design for Microinteractions

A trigger is what initiates a microinteraction. It is the entry point -- the doorknob, the button, the notification badge. Triggers come in two fundamental types: manual triggers that users consciously activate, and system triggers that fire automatically when conditions are met. Every microinteraction begins with one of these, and the quality of the trigger determines whether users can discover, understand, and initiate the interaction at all.

Manual Triggers

Manual triggers require a deliberate user action. They live inside UI controls -- buttons, switches, icons, form fields, gestures, voice commands. The user must perceive the trigger, understand what it does, and act on it.

Types of Manual Triggers

Manual Trigger Design Principles

1. Affordance clarity: The trigger must look like what it does. A toggle should look slideable. A button should look pressable. A drag handle should look grabbable.

2. Action labeling: Whenever possible, label the trigger with a verb that describes the outcome: "Save," "Send," "Delete." Avoid vague labels like "Submit," "OK," or "Continue."

3. Size and touch targets: Touch triggers must be at least 44x44 points (Apple HIG) or 48x48dp (Material Design). Desktop triggers should be at least 24x24 pixels with generous click padding.

4. Placement convention: Triggers should appear where users expect them based on platform conventions:

5. Discoverability hierarchy:

---

System Triggers

System triggers fire automatically when predefined conditions are met. The user does not initiate them -- the system detects a change in state and responds.

Types of System Triggers

System Trigger Design Principles

1. Relevance over frequency: A system trigger should fire only when the information is genuinely useful at that moment. Every unnecessary notification erodes trust and trains users to ignore triggers.

2. Threshold calibration: Set thresholds that balance urgency with usefulness:

3. Escalation: Important system triggers should escalate if ignored:

Passive indicator → Active notification → Blocking alert
(badge count)      (banner/toast)         (modal dialog)

4. Silencing rules: Users must be able to silence system triggers. Provide:

• Global mute (Do Not Disturb)
• Per-category control (mute marketing, keep security)
• Scheduled quiet hours

---

Trigger States

Every manual trigger exists in multiple states. Users must be able to distinguish each state at a glance.

The Five Essential Trigger States

Additional States for Complex Triggers

State Transition Timing

---

Designing Invisible Triggers

Some triggers have no visible control -- they rely on gestures, sensor input, or spatial awareness. These are powerful but dangerous because they have zero discoverability.

When Invisible Triggers Are Appropriate

Making Invisible Triggers Learnable

1. One-time coaching: Show a brief animation or tooltip on first use demonstrating the gesture.

2. Partial reveal: Show just enough to hint at the interaction. For swipe-to-delete, show the edge of the red "Delete" background peeking out slightly.

3. Contextual hint: When the user appears stuck (long pause, repeated taps), show a tooltip: "Try swiping left to delete."

4. Progressive discovery: Let users stumble onto the trigger through natural exploration, then reinforce it. Pull-to-refresh was initially invisible but became a platform convention through consistent implementation.

Invisible Trigger Checklist

• [ ] Is there a visible alternative for the same action?
• [ ] Is the gesture a platform convention (not a custom invention)?
• [ ] Do you provide coaching for first-time users?
• [ ] Does the trigger work reliably (no accidental fires)?
• [ ] Can users undo the result if they trigger it accidentally?

---

Trigger Placement and Visibility

Where a trigger lives on screen determines whether users find it. Placement follows predictable patterns based on reading order, platform convention, and visual hierarchy.

Visibility Priority Framework

Fitts's Law Application

Fitts's Law states that the time to reach a target is proportional to the distance and inversely proportional to the target size. Practical implications:

• Corners and edges are easy targets on desktop (cursor stops at screen edge). Place primary actions near edges.
• Bottom of screen is easy to reach on mobile (thumb zone). Place primary actions in the bottom third.
• Larger triggers are faster to hit. Primary actions should be physically larger than secondary ones.
• Distance matters. Group related triggers together to reduce travel between sequential actions.

Trigger Grouping Patterns

---

Trigger Audit Checklist

Use this checklist to evaluate triggers across an interface.

Discoverability

• [ ] Can a first-time user find the trigger within 5 seconds?
• [ ] Is the trigger labeled with a clear verb (not "Submit" or "OK")?
• [ ] Does the trigger look interactive (distinct from static elements)?
• [ ] Is the trigger large enough for its input method (touch: 44pt+, mouse: 24px+)?

State Communication

• [ ] Can users distinguish default, hover, active, disabled, and loading states?
• [ ] Does the disabled state explain why it is disabled (tooltip or nearby text)?
• [ ] Does the loading state indicate progress or at least activity?
• [ ] Is the success/error state visible for long enough to register?

Placement

• [ ] Is the trigger where platform conventions suggest?
• [ ] Is the primary action more visually prominent than secondary actions?
• [ ] Are related triggers grouped together?
• [ ] Is the trigger reachable with one hand on mobile (bottom two-thirds of screen)?

Edge Cases

• [ ] What happens on double-tap/double-click? (Prevent duplicate submissions)
• [ ] What happens if the trigger is activated during loading? (Disable or queue)
• [ ] What happens on very slow connections? (Show loading state immediately)
• [ ] What if the user activates the trigger and navigates away? (Handle gracefully)