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