| name | Interaction Design |
| description | Design meaningful interactions, microinteractions, animations, state machines, gesture patterns, error prevention, and product behavior. Specify how products respond to user input across all states and contexts using established interaction design principles. |
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):
| Part | Definition | Key Question |
|---|
| Trigger | What initiates the interaction | How does the user (or system) start this? |
| Rules | The hidden logic that governs behavior | What happens, in what sequence, with what constraints? |
| Feedback | How the system communicates what's happening | What does the user see, hear, or feel? |
| Loops & Modes | How the interaction changes over time | Does this repeat? Expire? Adapt? |
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:
- 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
- Match visibility to frequency — High-use triggers should be prominent and always accessible. Infrequent triggers can be less visible
- Consistent behavior — A trigger must initiate the same action every time. Inconsistency destroys trust
- 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:
- Start with the goal — What is the user trying to accomplish? Every rule serves this goal
- Don't start from zero — Use smart defaults based on past behavior, user context, or common patterns. Remember what the user did last time
- 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)
- 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.
| Type | Best For | Guidelines |
|---|
| Visual | Most interactions | Near the trigger. Brief. Respect visual hierarchy. Don't compete with content |
| Auditory | Confirmations, alerts, background processes | Sparingly. Short. Avoid negative sounds — use positive ones. Always mutable |
| Haptic | Mobile/wearable confirmations, boundaries | Simple patterns. Confirm actions. Signal errors. Limited vocabulary |
Feedback principles:
- Convey the most with the least — Minimal, purposeful. A subtle color change beats a modal dialog
- Match intensity to importance — Routine confirmation: subtle. Error with data loss: prominent and persistent
- Feedback should diminish with repetition — What's delightful on first use becomes annoying on the hundredth. Consider reducing feedback intensity for repeated actions
- 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).
| Posture | User Attention | Duration | Design Response |
|---|
| Sovereign | Full, focused attention | Hours | Rich controls, keyboard shortcuts, dense information, muted visual style. Target perpetual intermediates |
| Transient | Brief, task-focused | Seconds to minutes | Obvious UI, bright and clear, minimal options, remember user choices |
| Daemonic | None (background) | Continuous | Invisible when working. Surface only when there's a problem. Configure via a transient settings panel |
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)
- Follow mental models — Design based on how users think it works, not how it's actually built
- Less is more — Every additional element competes for attention
- Provide choices, don't ask questions — Toggles and options > confirmation dialogs
- Keep tools close at hand — Contextual toolbars, right-click menus, inline editing
- Provide modeless feedback — Status information that doesn't interrupt. Progress indicators in the UI, not in a dialog
- Design for the probable, anticipate the possible — Optimize the common path. Handle edge cases gracefully
- 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:
| Plot Point | In Story | In Product | Design Question |
|---|
| Exposition | Introduces the world and characters | User arrives and orients | Is it immediately clear what this is and what I can do? |
| Inciting incident | Something disrupts the status quo | User encounters their task/goal | Does the product acknowledge the user's problem or need? |
| Rising action | Character takes steps, tension builds | User works through the flow | Does each step feel like progress? Does engagement build? |
| Crisis | Greatest obstacle, highest tension | User hits friction, doubt, or complexity | Is this friction intentional? Can the user overcome it? |
| Climax | Turning point, peak emotion | The payoff — the "aha!" or accomplishment | Is there a peak positive moment the user will remember? |
| Falling action | Things wind down | Confirmation, sharing, next steps | Does the product celebrate success and suggest what's next? |
| End | The new normal | User leaves with an impression | Is the ending designed deliberately? |
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
| Story Type | What It Maps | Scale | Key Question |
|---|
| Concept story | The big picture — what this product is and why it matters | Product-level | "What is the story of this product?" |
| Origin story | How someone becomes a user for the first time | Acquisition + onboarding | "What's the story of a user's first experience?" |
| Usage story | How someone uses the product for a specific task | Single session or flow | "What's the story of using this feature?" |
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
- Define the story — Who is the hero? What is their goal? Which story type are you mapping?
- Plot the arc — Use sticky notes on a wall or a spreadsheet. One note per plot point. Map left to right chronologically
- 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
- Map to screens/interactions — Each plot point becomes a screen, a state, or a key interaction moment
- 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
- Design the climax — This is the moment users will remember. Invest disproportionate design effort here
- 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
| Situation | Story Type to Map |
|---|
| Designing a new product or major feature | Concept story first, then origin story |
| Improving onboarding or activation | Origin story |
| Designing or improving a specific flow | Usage story |
| Diagnosing why users aren't engaged | All three — find which story is broken |
| Pitching a product vision to stakeholders | Concept story as the narrative backbone |
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
| Type | Definition | Examples |
|---|
| Cognitive | Comprehending product behavior, decoding layouts | Unclear labels, ambiguous icons, complex jargon |
| Memory | Remembering commands, locations, passwords, settings | Forgetting where a setting lives, re-entering the same data |
| Visual | Figuring out where to look, finding items, decoding hierarchy | Cluttered screens, poor contrast, undifferentiated lists |
| Physical | Unnecessary clicks, mouse travel, mode switching | Deep navigation, distant controls, repeated scrolling |
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 | When | Required Visual Change |
|---|
| Default | Resting, ready | Base appearance |
| Hover | Cursor over (desktop) | Subtle highlight, cursor change |
| Focus | Keyboard navigation | Visible focus ring (2px, 3:1 contrast) |
| Active/Pressed | Being activated | Depressed appearance, scale reduction |
| Disabled | Not currently available | Reduced opacity (40%), no pointer events |
| Loading | Awaiting data/response | Skeleton or spinner replacing content |
| Empty | No data to display | Illustration + guidance + action |
| Error | Something went wrong | Error color + message + recovery path |
| Success | Action completed | Confirmation + next step |
| Selected | Chosen in a multi-select | Accent border or background |
| Expanded/Collapsed | Toggle content visibility | Arrow/chevron rotation + content reveal |
| Dragging | Being repositioned | Elevated shadow, ghost at origin |
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
| Duration | User Perception | Design Response |
|---|
| 0-100ms | Instantaneous | No feedback needed beyond the state change |
| 100ms-1s | Responsive, slight delay | Show the result. Skeleton or subtle indicator if near 1s |
| 1-10s | Noticeable wait | Progress indicator. Explain what's happening. Allow cancellation |
| 10s+ | Losing attention | Persistent progress with estimate. Background the task. Notify on completion |
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 | Action | When to Use |
|---|
| Tap | Select, activate | Primary action on any touchable element |
| Long press | Secondary action, context menu | Less discoverable — always provide an alternative path |
| Swipe | Navigate, dismiss, reveal actions | Natural for lists, cards, pages. Show affordance on first use |
| Pinch/Spread | Zoom in/out | Maps, images, documents. Bidirectional |
| Drag | Reorder, move, resize | Show drop targets. Provide haptic feedback at thresholds |
| Pull down | Refresh | Lists and feeds. Show progress animation |
Gesture Design Rules
- Never use gestures as the only path — Always provide a visible alternative (button, menu item)
- Provide feedback during the gesture — The element should respond in real-time to the finger, not just after release
- Respect the platform — iOS swipe-back, Android back button. Don't override system gestures
- Teach through progressive disclosure — Show gesture hints on first encounter, then fade them
- Touch targets minimum 44×44px (Apple HIG) or 48×48dp (Material) — smaller targets cause errors
Common Mistakes
| Mistake | Why It Fails | Instead |
|---|
| Designing only the happy path | Real users encounter errors, empty states, slow connections, edge cases | Design every state for every element |
| Confirming every action with a dialog | Interrupts flow, teaches users to click "OK" without reading | Provide Undo instead of asking permission |
| Identical feedback for different outcomes | User can't tell if their action succeeded, failed, or is still processing | Differentiate success, error, and loading feedback clearly |
| Gestures without visible alternatives | Users who don't discover the gesture are stuck | Always pair gestures with a visible control |
| Animations that block interaction | Users wait for an animation to finish before they can act | Keep animations under 300ms for direct interactions. Never block input |
| Ignoring keyboard users | Keyboard navigation is broken or invisible | Design focus order, visible focus states, and keyboard shortcuts |
| Complex modes without clear indicators | Users don't know which mode they're in and get unexpected behavior | Minimize modes. If unavoidable, make the current mode impossible to miss |
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 eachreferences/product-behavior.md — Product postures, perpetual intermediates, smart and considerate product behavior, orchestration, flow, and excise eliminationreferences/state-and-transitions.md — State machines for UI, gesture patterns, responsive behavior, drag-and-drop, and keyboard interactionreferences/motion-principles.md — Animation principles adapted for UI, timing and easing guidelines, motion tokens, reduced motion, and Material/Apple motion patternsreferences/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 frameworktemplates/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-endexamples/interaction-audit-walkthrough.md — Auditing and improving interactions in a fictional product
