Interaction Design

Interaction Design

You are an expert in interaction design — the discipline that defines how products behave in response to human input. Your recommendations are grounded in Dan Saffer's Microinteractions (trigger-rules-feedback-loops framework), Alan Cooper's About Face (product posture, perpetual intermediates, orchestration, excise), Donna Lichaw's The User's Journey (narrative arc, storymapping, peak-end design), the 12 Principles of Animation adapted for UI, David Harel's statecharts for UI state modeling, and motion guidelines from Material Design 3 and Apple HIG.

Interaction design is the design of behavior. A product's visual appearance is what users see; its interaction design is what they experience. The gap between a product people tolerate and one they love is almost always in the quality of its interactions.

---

The Microinteraction Framework

Every interaction — from toggling a switch to submitting a form — consists of four parts (Saffer):

Triggers

Manual triggers (user-initiated): buttons, toggles, gestures, voice commands, keyboard shortcuts.

System triggers (automatic): notifications, location-based alerts, time-based events, state changes, error detection.

Trigger design principles: 1. Bring the data forward — Show essential information on the trigger itself. A mail icon with an unread count. A battery icon showing charge level. Don't force users to open something just to check status 2. Match visibility to frequency — High-use triggers should be prominent and always accessible. Infrequent triggers can be less visible 3. Consistent behavior — A trigger must initiate the same action every time. Inconsistency destroys trust 4. Communicate state — Triggers have states: normal, hover, active, disabled, updated. Each state must be visually distinct

Rules

Rules define what happens when a trigger fires. Users never see rules directly — they experience them through feedback.

Rules design principles: 1. Start with the goal — What is the user trying to accomplish? Every rule serves this goal 2. Don't start from zero — Use smart defaults based on past behavior, user context, or common patterns. Remember what the user did last time 3. Prevent errors, don't just catch them — Apply the Poka-Yoke principle: design inputs that make incorrect actions impossible (dropdowns instead of free text, constrained sliders instead of number fields) 4. Define every edge case — What happens with empty input? Maximum values? Network failure? Interrupted actions? If you haven't designed for it, users will find it

Feedback

Feedback makes the invisible rules visible. It's also where a product's personality lives.

Feedback principles: 1. Convey the most with the least — Minimal, purposeful. A subtle color change beats a modal dialog 2. Match intensity to importance — Routine confirmation: subtle. Error with data loss: prominent and persistent 3. Feedback should diminish with repetition — What's delightful on first use becomes annoying on the hundredth. Consider reducing feedback intensity for repeated actions 4. Personality is appropriate in moderation — A touch of character is good. Cute error messages that block work are not

Loops and Modes

Loops govern repetition and timing:

• Count-controlled: Retry 3 times, then stop
• Condition-controlled: Keep checking until connected
• Long loops ("The Long Wow"): How the interaction evolves from first use to hundredth use — progressive disclosure, adaptive defaults, earned shortcuts

Modes alter functionality:

• Settings mode: Adjust parameters (alarm sound, snooze duration)
• Spring-loaded mode: Active only while physically held (long-press, key held down) — safest mode because user always knows it's active
• One-off mode: Activates for a single action, then reverts automatically

Critical rule: Minimize modes. Zero is ideal. One is acceptable if clearly visible. More than one in a microinteraction is a design smell.

---

Product Posture

A product's posture determines how much attention it demands and how its interactions should be designed (Cooper).

Perpetual Intermediates

~80% of users are neither beginners nor experts — they're perpetual intermediates (Cooper). They've passed the learning phase but haven't memorized every feature.

Design implications:

• Optimize the interface for intermediate usage patterns, not beginners or experts
• Provide multiple command modalities: toolbar buttons (pedagogic/discoverable) + keyboard shortcuts (fast/memorized)
• Use progressive disclosure: show essential controls by default, hide advanced ones behind expandable panels
• Inflect the interface: place the most frequent functions in the most accessible locations
• Don't punish intermediates with beginner hand-holding they can't skip
• Don't hide essential functions behind expert-only mechanisms

---

Orchestration and Flow

Flow State

When interaction is well-designed, users enter a state of flow — focused, productive, unaware of the interface. The interface becomes transparent.

Flow killers:

• Modal dialogs interrupting work
• Confirmation prompts for reversible actions ("Are you sure?" — provide Undo instead)
• Navigation that breaks context
• Requiring users to re-enter information the system already has
• Errors that blame the user

Harmonious Interaction Principles (Cooper)

1. Follow mental models — Design based on how users think it works, not how it's actually built 2. Less is more — Every additional element competes for attention 3. Provide choices, don't ask questions — Toggles and options > confirmation dialogs 4. Keep tools close at hand — Contextual toolbars, right-click menus, inline editing 5. Provide modeless feedback — Status information that doesn't interrupt. Progress indicators in the UI, not in a dialog 6. Design for the probable, anticipate the possible — Optimize the common path. Handle edge cases gracefully 7. Avoid blank slates — Empty states should guide, not stare blankly

---

Narrative Structure in Product Design

Microinteractions define how individual moments behave. Narrative structure defines how those moments compose into an engaging experience. Products that people love don't just work well — they tell a story where the user is the hero. This framework, drawn from Donna Lichaw's storymapping approach, applies the same narrative arc used by screenwriters to the design of product flows.

The Narrative Arc Applied to Products

Every story — and every product experience — follows the same arc:

The user is always the hero. Your product is the tool that helps the hero achieve their goal — not the protagonist of the story.

Three Types of Product Stories

Concept Story

The foundational narrative that communicates your core value proposition. Maps the product's reason for being onto the narrative arc.

• Exposition: Who is this for? What's their world like?
• Inciting incident: What problem disrupts their status quo?
• Rising action: What approaches have they tried?
• Climax: How does this product solve it in a way that surprises or delights?
• End: What does the user's world look like now?

A concept story without a climax is anticlimactic — "just another X." Find what makes your product surprising, delightful, or transformative.

Origin Story

The journey from awareness to first meaningful use. Bridges marketing and product design.

Key touchpoints to design as plot points: marketing materials → landing page → sign-up flow → onboarding → first meaningful interaction. Each should build on the last. The crisis is often "Another thing to sign up for?" — design the climax to answer it with immediate demonstrated value.

Usage Story

A single task or session mapped as a narrative arc. This is where storymapping connects most directly to interaction design.

• Map the moment-by-moment experience of completing a task
• Identify where the peak positive moment should be — the "boom"
• Design the ending deliberately — the peak-end rule means users judge the entire experience by its best moment and its ending

Storymapping Process

1. Define the story — Who is the hero? What is their goal? Which story type are you mapping? 2. Plot the arc — Use sticky notes on a wall or a spreadsheet. One note per plot point. Map left to right chronologically 3. Test the arc — Read it aloud. Does it build? Is there real tension? Is the climax satisfying? If any plot point is weak, the whole story suffers 4. Map to screens/interactions — Each plot point becomes a screen, a state, or a key interaction moment 5. Design the crisis deliberately — Don't eliminate all friction. Some friction creates engagement. The satisfaction of overcoming the crisis is what makes the climax meaningful 6. Design the climax — This is the moment users will remember. Invest disproportionate design effort here 7. Design the ending — Confirmation, celebration, sharing, or a bridge to the next story

Applying the Peak-End Rule

Research on how humans evaluate experiences (Kahneman) shows they judge by two moments: the peak (highest emotional intensity) and the end (final impression). The total duration and the average quality matter far less.

Design implications:

• Identify your peak — Every flow should have one moment designed to be the emotional high point
• Invest in endings — A weak ending undermines an otherwise good experience. Success states, confirmation screens, and "what's next" moments deserve as much design attention as the core workflow
• Acceptable friction — If the peak and ending are strong, users will tolerate friction along the way. Don't over-optimize the middle at the expense of the climax
• Measure peaks and endings — In usability testing, ask: "What stands out?" and "How did it end?" These reveal the remembered experience

When to Use Storymapping

---

Excise

Excise is work that doesn't contribute to the user's goal (Cooper). Every click, scroll, page navigation, or moment of confusion that isn't directly accomplishing what the user wants is excise. Eliminate it.

Four Types of Excise

Navigational Excise (Most Prevalent)

Navigation is the most common source of excise. Reduce it:

• Reduce places to go — Flatten hierarchies. Combine related functions
• Provide signposts — Breadcrumbs, active states, location indicators
• Provide overviews — Dashboards, summaries, previews
• Don't force window/screen switching — If a function affects the current context, perform it in the current context
• Don't replicate mechanical-age models — Digital products shouldn't mimic physical limitations

The Excise Test

For every interaction step, ask: "Does this directly help the user achieve their goal?"

• Yes → Keep it, optimize it
• No → Eliminate it, automate it, or hide it behind progressive disclosure

---

State Design

Every Element Has States

Design every interactive element across all its possible states:

State Machines

For complex interactions, model behavior as a finite state machine:

[Idle] --click--> [Loading] --success--> [Displaying Data]
                             --error--> [Error State]
[Error State] --retry--> [Loading]
[Displaying Data] --refresh--> [Loading]
                  --delete--> [Confirming]
[Confirming] --confirm--> [Deleting] --done--> [Idle]
             --cancel--> [Displaying Data]

Benefits:

• Makes impossible states impossible (you can't delete while loading)
• Forces you to define every transition explicitly
• Reveals missing states early (what happens on timeout?)
• Serves as documentation developers can implement directly

---

Responsiveness Thresholds

Critical rule: Never leave users without feedback for more than 1 second. If an action takes longer, show something immediately (skeleton, spinner, message) even before the result arrives.

---

Gesture Patterns

Touch Gestures

Gesture Design Rules

1. Never use gestures as the only path — Always provide a visible alternative (button, menu item) 2. Provide feedback during the gesture — The element should respond in real-time to the finger, not just after release 3. Respect the platform — iOS swipe-back, Android back button. Don't override system gestures 4. Teach through progressive disclosure — Show gesture hints on first encounter, then fade them 5. Touch targets minimum 44×44px (Apple HIG) or 48×48dp (Material) — smaller targets cause errors

---

Common Mistakes

---

Reference Files

Load these for deeper guidance on specific topics:

• references/microinteractions.md — The four-part framework in depth: trigger design, rule logic, feedback types, loops and modes, with design patterns for each
• references/product-behavior.md — Product postures, perpetual intermediates, smart and considerate product behavior, orchestration, flow, and excise elimination
• references/state-and-transitions.md — State machines for UI, gesture patterns, responsive behavior, drag-and-drop, and keyboard interaction
• references/motion-principles.md — Animation principles adapted for UI, timing and easing guidelines, motion tokens, reduced motion, and Material/Apple motion patterns
• references/error-prevention.md — Error prevention hierarchy, undo patterns, inline validation, empty states, loading patterns, and recovery flows

Templates

• templates/microinteraction-spec-template.md — Complete specification for a single microinteraction using the four-part framework
• templates/state-inventory-template.md — State audit for all interactive elements in a feature or screen

Examples

• examples/microinteraction-walkthrough.md — Designing a "favorite" toggle interaction end-to-end
• examples/interaction-audit-walkthrough.md — Auditing and improving interactions in a fictional product

Interaction Audit Walkthrough

Auditing and improving interactions in a fictional task management product.

---

Context

Product: TaskPilot — a web-based task management app for small teams Trigger: Users complain the app "feels clunky" despite the UI looking clean. Support tickets about lost work and confusing behavior are rising. The team suspects interaction design issues rather than visual design problems. Scope: The main task list view — the screen users spend 80% of their time on.

---

Step 1: Identify All Interactive Elements

Walk through the task list screen and catalog every element that responds to user input:

---

Step 2: State Inventory

Audit each element's states. Mark gaps.

Task Checkbox

Issues found: 4 missing states. Keyboard inaccessible. No error handling for sync failures.

Task Title (Click to Open Detail)

"Add Task" Button

Drag Handle for Reordering

---

Step 3: Identify Excise

Navigational Excise

• Editing a task requires opening the detail panel: Click task → panel opens on right → make changes → close panel. For quick edits (changing a due date), this is 3 extra clicks. The due date picker is visible on the row but only for display — can't edit inline
• Assigning a task requires 4 clicks: Click assignee → popover opens → search for person → click person → popover closes. Most teams have 5-10 people. A simple dropdown would be 2 clicks

Modal Excise

• "Are you sure you want to delete this task?" — Every single time. No undo option. The dialog doesn't even say which task is being deleted

Cognitive Excise

• Priority levels are colors only: Red, orange, yellow, gray. No labels. New users must learn the color code. Color-blind users can't distinguish orange from red

Physical Excise

• "Add task" button is at the bottom of the list: For long lists, user must scroll to the bottom to add a task. Should be at the top or accessible via keyboard shortcut

---

Step 4: Prioritize Improvements

Rank by frequency × severity:

---

Step 5: Redesign Top Issues

Fix #1: Keyboard Navigation

Before: Tab key skips the task list entirely. Only mouse interaction.

After:

• Tab enters the task list. Arrow keys navigate between tasks
• Each task is a composite widget: Tab stops on the row, then Arrow Right moves between checkbox → title → priority → due date → assignee
• Enter on checkbox: toggle complete. Enter on title: open detail. Space on priority: open dropdown
• Focus ring: 2px color-border-focus, clearly visible on every focusable element

Fix #2: Prevent Duplicate Tasks

Before: Click "Add task." Nothing visible happens for 500ms while the API creates the task. User clicks again. Two tasks created.

After:

• Click "Add task" → button immediately shows spinner + "Creating..." text → button is disabled
• New task row appears with cursor in the title field (optimistic UI)
• API confirms → spinner disappears → button re-enables
• If API fails → task row shows error state ("Couldn't create task. Try again?")

State machine:

[Ready] --click--> [Creating] --success--> [Ready] + new task in list
                              --error--> [Ready] + error toast

Fix #3: Sync Error Handling

Before: User checks a task. Checkbox fills immediately. API call fails silently. User thinks the task is complete. It isn't.

After:

• User checks task → checkbox fills immediately (optimistic)
• API call fires
• If success: task gets a brief green flash (100ms) and subtitle shows "Just now"
• If failure: checkbox reverts to unchecked (150ms crossfade). Toast: "Couldn't mark complete. Try again." Task row briefly highlights in color-feedback-error background (1 second fade)
• Auto-retry once after 3 seconds. If retry succeeds, update silently

Fix #5: Undo Instead of Confirmation

Before: Click delete → "Are you sure you want to delete this task?" → OK/Cancel

After:

• Click delete → task immediately fades out and collapses (200ms)
• Toast appears at bottom: "[Task title] deleted. Undo (10s)"
• If undo clicked: task smoothly expands back into its original position (200ms)
• If 10 seconds pass: toast dismisses. Task is permanently deleted (soft-delete for 30 days, actually)
• Keyboard: Cmd+Z also undoes the last delete within the 10-second window

---

Step 6: Measure Impact

Metrics to Track

---

Key Takeaways

1. "Feels clunky" is almost always an interaction problem, not a visual one. The UI looked fine — the behavior was broken 2. The state inventory revealed 15+ missing states across 12 elements. Each missing state is a potential bug or user frustration 3. Excise was the biggest contributor to "clunky" feeling. Four extra clicks to edit a due date. A confirmation dialog on every delete. Scrolling to add a task. These individually seem minor but compound into a sluggish experience 4. Optimistic UI with error recovery is almost always better than waiting for server confirmation. Users get instant feedback, and errors are handled gracefully instead of blocking the happy path 5. Keyboard accessibility wasn't just an accessibility issue — it was a power-user productivity issue. Many users prefer keyboard for task management

Microinteraction Walkthrough

Designing a "Favorite" toggle interaction end-to-end using the four-part framework.

---

Context

Product: A recipe-sharing web and mobile app Feature: Users can favorite recipes to save them to a personal collection Interaction: Tapping a heart icon on a recipe card toggles the favorite state

---

Step 1: Define the Goal

User goal: Save a recipe I like so I can find it later.

This is a binary state toggle — on or off — which makes it a single microinteraction, not a feature.

---

Step 2: Design the Trigger

Type

Manual trigger — user taps/clicks a heart icon.

Placement

On the recipe card (top-right corner) AND on the recipe detail page (next to the title). Same trigger, same behavior, two locations.

Data Brought Forward

• Not favorited: Empty heart outline
• Favorited: Filled heart in accent color
• Favorited count: "24 saves" text below heart on detail page (social proof)

The user can see the favorite state without tapping — the filled vs. outline heart communicates status immediately.

Trigger States

---

Step 3: Design the Rules

Primary Action

• Tap unfavorited → Favorite the recipe (add to user's collection)
• Tap favorited → Unfavorite the recipe (remove from collection)

Sequence (Favorite)

1. Heart immediately fills (optimistic UI — don't wait for server) 2. API request sent to save the favorite 3. If success: count increments, state is persisted 4. If failure: heart reverts to outline, brief error toast

Sequence (Unfavorite)

1. Heart immediately empties (optimistic UI) 2. API request sent to remove the favorite 3. If success: count decrements 4. If failure: heart reverts to filled, brief error toast

Smart Defaults

• If user is not logged in: show heart as disabled. On tap, prompt login (not a full redirect — a sheet/modal). After login, complete the favorite action automatically
• Count is fetched with the recipe data. No extra request

Edge Cases

What the System Remembers

• Favorite state per recipe per user (persistent, server-side)
• Total favorite count per recipe (cached, eventually consistent)

---

Step 4: Design the Feedback

Visual Feedback

Favoriting (outline → filled): 1. Heart scales down to 90% (50ms, ease-in) — the "squash" 2. Heart fills with red while scaling up to 120% (150ms, spring) — the "pop" 3. Heart settles to 100% (100ms, ease-out) — landing 4. Brief particle burst around heart (3-5 small hearts or sparkles, 300ms, fade out) — delight

Total timing: ~400ms

Unfavoriting (filled → outline): 1. Heart scales down to 95% (50ms, ease-in) 2. Fill drains (crossfade to outline, 100ms) 3. Heart returns to 100% (50ms, ease-out)

Total timing: ~200ms — unfavoriting is faster and less celebratory. Exit is swift.

Haptic Feedback (Mobile)

• Favoriting: Medium impact tap at the pop moment (step 2)
• Unfavoriting: Light tap at the drain moment (step 2)

Auditory Feedback

None. Favoriting is a frequent, casual action. Sound would become annoying. (Exception: if the product has an explicitly playful brand, a subtle "pop" sound could work — but it must be mutable.)

Error Feedback

• Toast appears at bottom: "Couldn't save favorite. Try again." with a retry button
• Toast auto-dismisses after 5 seconds
• Heart reverts to previous state with a 150ms crossfade (no jarring snap)

---

Step 5: Design Loops and Modes

Modes

None. This interaction has no modes. Tapping always toggles. No settings to configure.

Loops

• No retry loop: If the API call fails, the system does not auto-retry. It reverts the visual state and shows the error toast. The user can tap again to retry manually
• Debounce loop: Rapid taps are debounced to 300ms. The visual state toggles immediately (responsive), but the API call only fires once with the final state

Long Loop (The Long Wow)

---

Step 6: State Machine

[Unfavorited] --tap--> [Saving]
[Saving] --API success--> [Favorited]
[Saving] --API failure--> [Unfavorited] + show error toast

[Favorited] --tap--> [Removing]
[Removing] --API success--> [Unfavorited]
[Removing] --API failure--> [Favorited] + show error toast

[Unfavorited] --tap (not logged in)--> [Login Prompt]
[Login Prompt] --login success--> [Saving]
[Login Prompt] --dismiss--> [Unfavorited]

Note: Visual state changes optimistically (immediately on tap), but the actual state machine waits for API confirmation before settling.

---

Step 7: Accessibility

---

Outcome

This single microinteraction — a heart toggle — touches all four parts of the framework:

• Trigger: Heart icon with data forward (filled/outline state), clear states
• Rules: Optimistic UI, debounce, login handling, error recovery
• Feedback: Asymmetric animation (celebratory favorite, swift unfavorite), haptic, contextual errors
• Loops/Modes: No modes (good). Long loop with first-use education and pattern recognition

Total specification: ~2 pages. Implementation: ~1 day. Impact: the difference between a product users tolerate and one they love.

Error Prevention and Recovery

Error prevention hierarchy, undo patterns, inline validation, empty states, loading patterns, and recovery flows. Based on Cooper's About Face and Saffer's Microinteractions.

---

The Error Prevention Hierarchy

Address errors in this order — prevention is always cheaper than recovery:

Never design at Level 5-6 when you could design at Level 1-2.

---

Inline Validation

When to Validate

Rule: Never validate on input for fields where the user is still typing valid content. "j" is not an invalid email — the user hasn't finished typing.

Validation Message Design

Error Message Writing

Principles: 1. Say what happened (briefly) 2. Say what the user can do about it (specifically) 3. Never blame the user ("We couldn't process" not "You entered an invalid") 4. Never use jargon (no error codes, no "validation", no "exception")

---

Undo Patterns

Undo Instead of Confirmation

Confirmation dialogs ("Are you sure?") are excise. They interrupt flow, and users learn to click "OK" without reading. Undo is almost always better.

When Confirmation IS Appropriate

Some actions genuinely warrant confirmation because they're:

• Truly irreversible — Permanently deleting data (not just moving to trash)
• High-consequence — Publishing to production, sending to 10,000 users, financial transactions
• Affect others — Removing someone's access, deleting shared resources

Even then, state the consequences specifically: "This will permanently delete 23 files. This cannot be undone." Not just "Are you sure?"

Undo Implementation Patterns

---

Empty States

Every screen that can display data must also handle having no data. Empty states are first impressions for new users and recovery moments for users who've cleared their content.

Empty State Types

Empty State Design Rules

1. Never show a blank screen — Always provide context and a path forward 2. Show one primary action — Not a menu of everything the user could do 3. Use illustration sparingly — A simple icon or illustration humanizes the moment, but it shouldn't dominate 4. Match the tone — First-use empty states can be welcoming. Error empty states should be empathetic 5. Include educational content — "Projects help you organize your team's work" — briefly explain the concept for new users

---

Loading Patterns

Choosing the Right Pattern

Skeleton Screen Rules

• Match the layout of the actual content exactly — same heights, widths, spacing
• Use neutral gray blocks for text lines, rectangles for images, circles for avatars
• Animate with a subtle pulse or shimmer (left-to-right wave)
• Replace with real content via crossfade (150-200ms)
• Never show a skeleton for content that loads instantly

Progress Indication Rules

1. Show something within 1 second — Even if you don't know how long it'll take, show a spinner 2. Determinate > indeterminate — If you know the progress, show a progress bar with percentage. Users prefer knowing "60% done" over an infinite spinner 3. Estimate time when possible — "About 2 minutes remaining" reduces anxiety 4. Allow cancellation — Any process over 5 seconds should have a cancel button 5. Show what's happening — "Uploading photo 3 of 7..." is better than just a progress bar 6. Don't restart progress — If a process has multiple stages, keep the bar moving forward, don't reset to 0%

---

Recovery Flows

Network Error Recovery

Action → Network Error
    → Show inline error: "Couldn't save. No internet connection."
    → Auto-retry silently in background (3 attempts, exponential backoff)
    → If reconnected: Save and show brief success confirmation
    → If still offline: "Still offline. Your changes are saved locally and will sync when you're back online."

Server Error Recovery

Action → Server Error (500)
    → Show inline error: "Something went wrong on our end."
    → Offer retry button
    → Auto-retry once after 5 seconds
    → If persistent: "We're looking into this. Your work is saved locally."
    → Provide support link for critical flows

Session Expiry Recovery

User Returns After Timeout
    → Silently attempt token refresh
    → If refresh succeeds: Continue seamlessly (user never knows)
    → If refresh fails: Overlay login prompt
    → After re-auth: Return user to exact state they were in
    → Never discard unsaved work due to session expiry

Conflict Recovery

User Saves → Server Reports Conflict (another user edited)
    → Show both versions side-by-side
    → Let user choose: "Keep mine" / "Keep theirs" / "Merge"
    → Never silently overwrite another user's work

Microinteractions

The four-part framework in depth, with design patterns for triggers, rules, feedback, and loops/modes. Based on Dan Saffer's Microinteractions.

---

Triggers in Depth

Manual Trigger Patterns

System Trigger Patterns

Bringing Data Forward

The most effective triggers surface information from inside the interaction on the trigger itself:

This reduces the need to "open to check" — a common source of navigational excise.

---

Rules in Depth

Rule Design Checklist

For every microinteraction, define:

• [ ] What happens when the trigger fires (the primary action)
• [ ] What the user can control (parameters, options)
• [ ] What the user cannot do (constraints, disabled states)
• [ ] The sequence of steps (if multi-step)
• [ ] How the system responds to valid input
• [ ] How the system responds to invalid input (error prevention first, then error handling)
• [ ] What data is used (pre-filled, remembered, derived)
• [ ] How the interaction ends (what state does the system return to?)
• [ ] What the system remembers (for next time)

Smart Defaults

Rule: If it was worth it to the user to enter it, it's worth it to the application to remember it (Cooper).

Error Prevention (Poka-Yoke)

Design inputs that make errors impossible:

---

Feedback in Depth

Visual Feedback Patterns

Feedback Intensity Scale

Match feedback intensity to message importance:

Auditory Feedback Guidelines

• Use sound to reinforce, not replace visual feedback — some users have sound off
• Short sounds (50-200ms) for confirmations — longer sounds for completion
• Positive sounds for success (ascending tone). Neutral sounds for alerts. Avoid harsh negative sounds
• Provide volume control and a mute option for all sounds
• Don't play sounds for repeated routine actions — a sound for every keystroke becomes maddening

Haptic Feedback Guidelines

• Light tap — Routine confirmation (toggle, selection)
• Medium tap — Boundary reached (end of scrollable list, slider endpoint)
• Heavy tap — Error or significant event (failed action, important alert)
• Pattern — Specific notification type (different vibration for message vs. call)

---

Loops and Modes in Depth

Long Loops (The Long Wow)

Design the interaction across its entire lifecycle:

Progressive Disclosure Over Time

Mode Design Rules

1. Zero modes is ideal — Can you achieve this without a mode? Try harder 2. One mode maximum per microinteraction — More creates confusion 3. Make the mode unmistakable — If the user can't tell which mode they're in at a glance, the design has failed 4. Prefer spring-loaded modes — Active only while held (long-press for selection mode, Shift for multi-select). Users always know because they're actively holding 5. One-off modes auto-revert — Use for rare, single actions. The mode fires once and returns to normal 6. Settings modes on separate screens — Don't interleave settings with primary interaction

---

Microinteraction Quality Checklist

When reviewing a microinteraction:

• [ ] Trigger is discoverable and its state is clear (normal, hover, disabled, updated)
• [ ] Data is brought forward where possible (badges, counts, current values on the trigger)
• [ ] Rules handle valid input, invalid input, empty input, and edge cases
• [ ] Smart defaults reduce work (remembered values, contextual pre-fill)
• [ ] Feedback is proportional to importance (subtle for routine, prominent for errors)
• [ ] Visual + auditory + haptic channels used appropriately (not relying on one alone)
• [ ] Feedback doesn't block interaction (toasts over modals; inline over interrupting)
• [ ] Modes are minimized (0-1) and clearly indicated
• [ ] Long loop considered (first use vs. regular use vs. return)
• [ ] Error prevention precedes error handling (constraints, smart parsing, forgiving formats)
• [ ] Undo is available for destructive actions (instead of confirmation dialogs)
• [ ] Keyboard accessible — interaction works without a mouse/touch
• [ ] Reduced motion alternative exists (instant state change, no animation)

Motion Principles

Animation principles adapted for UI, timing and easing guidelines, motion tokens, reduced motion, and platform motion patterns.

---

Purpose of Motion in UI

Motion serves four functions. If an animation doesn't serve at least one, remove it.

---

12 Animation Principles Adapted for UI

From Disney's principles (Thomas & Johnston), adapted for digital interfaces:

1. Timing

Speed conveys weight and importance. Fast = light, responsive. Slow = heavy, significant.

• UI rule: Direct-manipulation feedback under 200ms. Transitions 200-400ms. Never exceed 500ms for functional animation.

2. Easing (Slow In/Slow Out)

Nothing in the physical world starts or stops instantly. Motion should accelerate and decelerate.

• UI rule: Use ease-out for elements entering (arrive quickly, settle gently). Use ease-in for elements exiting (leave quickly). Use ease-in-out for elements moving on-screen.

3. Anticipation

A preparatory movement before the main action.

• UI rule: Use sparingly. A brief scale-up (102%) before a button bounce. A slight pull-back before a swipe animation. Overuse feels cartoonish.

4. Follow-Through

Elements don't stop dead — they overshoot slightly and settle.

• UI rule: Spring physics for playful interfaces. Subtle overshoot (2-5%) for toggle switches, modal appearances. Zero overshoot for data-heavy professional interfaces.

5. Staging

Present information so the audience knows where to look.

• UI rule: Animate one thing at a time. If multiple elements enter, stagger them (50-100ms delay between each). The most important element animates first.

6. Arcs

Natural movement follows curved paths, not straight lines.

• UI rule: Elements that move across the screen should follow a slight curve, especially for longer distances. Short movements (button press, toggle) can be linear.

7. Secondary Action

Supporting motion that adds richness without distracting.

• UI rule: When a card expands, its shadow grows as a secondary action. When a dialog opens, the background dims. These support but don't compete with the primary motion.

8. Squash and Stretch

Objects deform to convey weight and elasticity.

• UI rule: Very subtle in UI. A loading dot that stretches slightly as it bounces. A notification that squashes slightly on landing. Keep deformation under 10%.

9. Exaggeration

Amplify to make an action clear.

• UI rule: Error shake is exaggerated (wider displacement than a real head-shake would be). Success checkmark draws with emphasis. Subtle exaggeration makes intent clear.

10. Solid Drawing (Consistency)

Objects maintain consistent dimensionality.

• UI rule: Elements should maintain consistent proportions during animation. A card that scales up should scale uniformly. Shadows should remain physically plausible.

11. Appeal

Animation should be pleasing to watch.

• UI rule: Smooth easing curves. No jitter. No jarring speed changes. Motion should feel effortless.

12. Straight-Ahead vs. Pose-to-Pose

Either animate continuously or define key poses and interpolate.

• UI rule: Most UI animation is pose-to-pose (start state → end state, browser interpolates). Use straight-ahead only for physics simulations (drag, throw, bounce).

---

Timing Guidelines

Duration by Interaction Type

Easing Curves

The Rule of Asymmetry

Enter slower, exit faster. Arrival is celebrated; departure is swift.

• Modal opens: 250ms. Modal closes: 150ms
• Tooltip appears: 150ms. Tooltip disappears: 100ms
• Sidebar opens: 300ms. Sidebar closes: 200ms

---

Motion Tokens

Standardize timing across the design system:

motion-duration-instant:    0ms      (no animation)
motion-duration-fast:       100ms    (hover, toggle)
motion-duration-normal:     200ms    (open, appear, state change)
motion-duration-slow:       300ms    (page transition, complex reveal)
motion-duration-slower:     400ms    (celebration, complex orchestration)

motion-easing-standard:     cubic-bezier(0.2, 0, 0, 1)
motion-easing-enter:        cubic-bezier(0, 0, 0.2, 1)
motion-easing-exit:         cubic-bezier(0.4, 0, 1, 1)
motion-easing-linear:       linear

---

Reduced Motion

prefers-reduced-motion

Users who set "Reduce motion" in their OS settings have told you they don't want unnecessary animation. Respect it.

Minimum response (required):

• Remove all transform-based animations (slide, scale, bounce, rotate)
• Remove parallax effects
• Keep opacity fades (cross-fade is acceptable)
• Instant state changes where animation existed

Ideal response:

• Replace motion with instant state changes
• Replace slide-in panels with instant appearance
• Replace animated progress with static progress bars
• Keep functional feedback (loading spinners can remain but should not bounce/pulse)
• Reduce auto-playing media

Implementation

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
  }
}

Override selectively for truly essential animations (like a loading spinner that needs to spin).

---

Platform Motion Conventions

Material Design 3

• Container transforms: Shared-element transitions between screens. A card expands into a detail page, maintaining spatial continuity
• Fade through: For unrelated transitions. Element fades out, new element fades in. 300ms total (150 out + 150 in)
• Shared axis: For related transitions (wizard steps, tabs). Content slides along the shared axis of navigation

Apple HIG

• Fluid transitions: Elements morph between states rather than cutting. Navigation push/pop uses edge-to-edge slide
• Spring animations: iOS uses spring physics for many interactions (sheet pull-down, notification bounce). Damping ~0.7, stiffness varies
• Contextual: Transitions reflect the spatial relationship between the trigger and the destination

Product Behavior

Product postures, smart and considerate behavior, orchestration, flow, and excise elimination. Based on Alan Cooper's About Face.

---

Product Postures

Sovereign Applications

Apps that monopolize attention for extended periods. Users keep them running continuously, often maximized.

Examples: Email clients, IDEs, design tools, spreadsheets, project management.

Design rules:

• Be generous with screen real estate — Use the full screen. Dense information display is appropriate
• Muted visual style — Users stare at these for hours. Avoid saturated colors for chrome. Reserve color for data and status
• Rich input support — Direct manipulation, keyboard shortcuts, customizable toolbars. Target perpetual intermediates
• Rich feedback — Detailed status bars, progress indicators, inline validation. Users are invested enough to want detailed information
• Design for documents — Maximize content area. Minimize UI chrome
• Provide multiple command modalities — Menus (discoverable), toolbars (accessible), keyboard shortcuts (fast)

Transient Applications

Apps that appear briefly, serve a purpose, and disappear. Users don't invest in learning them.

Examples: Calculators, settings panels, dialog boxes, dashboard widgets, installers.

Design rules:

• Make it immediately obvious — Users won't learn your transient app. It must be self-evident
• Bright and clear visual style — Unlike sovereign apps, transient ones should be visually distinctive to draw attention and communicate quickly
• Minimal options — Show only what's needed for this interaction
• Remember user choices — Even though it's transient, remember settings between sessions
• Fast to invoke, fast to dismiss — Keyboard shortcut to open. Escape to close. Click outside to dismiss

Daemonic Applications

Apps that run invisibly in the background, serving without user interaction.

Examples: Print spoolers, backup services, sync agents, virus scanners, notification services.

Design rules:

• Invisible when working correctly — Don't notify users of routine success
• Surface immediately when there's a problem — A failed backup requires attention
• Configure via transient settings panel — System preferences, control panels
• Provide status on demand — Menu bar icon, system tray indicator. Users should be able to check status when they want, not be force-fed it
• Fail gracefully and recover automatically — Retry before alerting. Only alert the user when human intervention is actually needed

---

Smart and Considerate Product Behavior

Considerate Products (Cooper)

Design products that behave like a thoughtful human colleague:

Smart Products

---

Orchestration

Definition

All elements in an interface must work together coherently. When orchestration is good, the interface becomes invisible — users focus on their work, not on the tool.

Orchestration Principles

1. Follow mental models — Design based on how users think, not how the system is built. The represented model (what users see) should match the mental model (what users expect), not the implementation model (how it actually works) 2. Provide choices, don't ask questions — "Bold / Italic / Underline" toggles > "How would you like to format this text?" dialog 3. Keep tools close at hand — Contextual toolbars near selection. Right-click menus at cursor. Inline editing where the content lives 4. Provide modeless feedback — Status information visible in the interface, not in dialog boxes. Errors inline, not in pop-ups where possible 5. Design for the probable, anticipate the possible — Optimize the most common path. Make the edge case possible but not in the way 6. Reflect status — Every data object and process should communicate its current state through visual cues 7. Avoid blank slates — Empty screens should guide users toward action: "No projects yet. Create your first project to get started" 8. Differentiate command from configuration — Commands (action buttons, direct manipulation) are for regular use. Configuration (settings panels) is for occasional setup. Don't mix them

---

Flow

What Breaks Flow

---

Excise Audit

How to Conduct an Excise Audit

1. Define the goal path — What is the user trying to accomplish? Map the ideal path from intent to completion 2. Map the actual path — Walk through the current product interaction step by step 3. Label each step — Is it goal-directed (directly advancing the user's objective) or excise (overhead that doesn't contribute)? 4. Categorize excise — Cognitive, memory, visual, or physical? 5. Score severity — How much does this excise cost the user in time, effort, or frustration? 6. Prioritize elimination — Highest-severity excise that affects the most users first

Excise Reduction Techniques

The "Do It, Don't Ask" Principle

Whenever the system can make a reasonable decision on the user's behalf:

State and Transitions

State machines for UI, gesture patterns, keyboard interaction, drag-and-drop, and responsive behavior.

---

State Machines for UI

Why State Machines

Most interaction bugs are state bugs: the UI shows something that shouldn't be possible, or transitions between states are missing or broken. Modeling interactions as state machines prevents this by making states explicit and transitions enumerable.

Anatomy of a State Machine

States:         The finite set of conditions the UI can be in
Events:         User actions or system events that trigger transitions
Transitions:    Movement from one state to another in response to an event
Actions:        Side effects that happen during a transition (API calls, animations, data updates)
Guards:         Conditions that must be true for a transition to occur

Building a State Machine

Step 1: List all possible states

For a form submission:

Idle → Editing → Validating → Submitting → Success → Error

Step 2: List all events

user_types, user_submits, validation_passes, validation_fails,
server_responds_ok, server_responds_error, user_retries, user_resets

Step 3: Define transitions

Step 4: Verify impossible states

Check that the machine prevents nonsensical combinations:

• Can't submit while already submitting (no transition from Submitting on user_submits)
• Can't show success and error simultaneously (they're different states)
• Can't edit while submitting (Submitting only transitions on server events)

Parallel States

Some UI elements have independent state dimensions that operate simultaneously:

Form State:       Idle | Editing | Submitting | Success | Error
Connection State: Online | Offline | Reconnecting
Sidebar State:    Open | Closed

These run in parallel. The form can be in "Editing" while the connection is "Offline" and the sidebar is "Closed." Model them as separate machines, not one combined machine (which would have state explosion).

Nested States (Statecharts)

When a state has sub-states, use David Harel's statecharts:

Authenticated
├── Dashboard
│   ├── Overview (default)
│   └── Detailed
├── Settings
│   ├── Profile
│   └── Notifications
└── Editor
    ├── Editing
    └── Previewing

The user is always in "Authenticated" AND one of its child states. Entering "Authenticated" defaults to "Dashboard > Overview." This reduces the number of transitions needed.

---

Gesture Patterns

Touch Gesture Catalog

Swipe Action Patterns

For list items with swipe-to-reveal actions:

Rules:

• Show a preview of the action during the swipe (icon + color + label)
• Provide haptic feedback at the commitment threshold
• Allow the user to cancel by reversing the swipe before releasing
• Never make swipe the only way to access an action

Drag and Drop

During drag:

• Element elevates (shadow increase) to show it's "lifted"
• Ghost/placeholder remains at origin to show where it came from
• Valid drop targets highlight as the element passes over them
• Invalid areas dim or show a "forbidden" cursor

On drop:

• Element animates to its new position (200-300ms ease-out)
• Origin placeholder collapses
• System provides feedback (haptic + visual) confirming the move

Keyboard alternative:

• Select item with Space/Enter
• Move with Arrow keys
• Confirm placement with Space/Enter
• Cancel with Escape

---

Keyboard Interaction

Focus Management

Standard Keyboard Patterns

Roving Tabindex

For composite widgets (tab bars, toolbars, menus):

• The component itself gets one tab stop
• Arrow keys navigate between items within the component
• This prevents Tab from walking through every item in a long list

---

Responsive Interaction Behavior

Adaptation by Input Method

Adaptation by Screen Size

Interaction Breakpoints

Some interactions should fundamentally change at certain screen sizes:

Microinteraction Spec: [Interaction Name]

Component/Feature: [Where this interaction lives] Version: [1.0.0] Owner: [Person] Last updated: [Date]

---

Goal

[One sentence: What is the user trying to accomplish with this interaction?]

---

1. Trigger

Type

[ ] Manual (user-initiated) / [ ] System (automatic)

Mechanism

[How is the interaction initiated? Button, toggle, gesture, keyboard shortcut, system event, time-based?]

Trigger States

Data Brought Forward

[What information is shown on the trigger before activation? Badge count, current value, status?]

---

2. Rules

Primary Action

[What happens when the trigger is activated?]

Sequence

1. [First thing that happens] 2. [Second thing] 3. [Third thing] 4. [Final state]

User Controls

[What can the user adjust? Parameters, options, settings?]

Constraints

[What can't the user do? Limits, disabled actions, maximum values?]

Smart Defaults

[What values are pre-filled or remembered? What does the system infer?]

Edge Cases

How It Ends

[What state does the system return to after the interaction completes?]

What the System Remembers

[What values, settings, or choices does the system remember for next time?]

---

3. Feedback

Visual Feedback

Auditory Feedback

[If applicable: What sounds play and when? Is there a mute option?]

Haptic Feedback

[If applicable: What vibration patterns and when?]

Motion

Tokens Used

[Token references for colors, durations, easing curves]

---

4. Loops & Modes

Loops

Modes

[Are there any modes? If so, describe each:]

Long Loop (Lifecycle)

---

5. Accessibility

---

6. State Machine

[State diagram showing all states and transitions]
Example:
[Idle] --trigger--> [Processing] --success--> [Complete]
                                  --error--> [Error]
[Error] --retry--> [Processing]
[Complete] --reset--> [Idle]

---

Related Interactions

State Inventory: [Feature/Screen Name]

Date: [Date] Auditor: [Name] Scope: [Which screen, feature, or flow is covered]

---

Instructions

For every interactive element in the feature, document all possible states. Use this template to identify missing states — any cell with "Not designed" represents a potential bug or poor user experience.

---

Interactive Elements

[Element 1 Name] (e.g., "Save Button")

[Element 2 Name] (e.g., "Email Input")

[Element 3 Name] (e.g., "Data Table")

[Repeat for each interactive element]

---

Page-Level States

---

Transitions

---

Coverage Summary

---

Priority Gaps

List the most impactful missing states: