Choosing an Interaction Pattern

The right interaction pattern is almost always a decision, not an invention. The hard part isn't building a modal or a drawer; it's knowing which one the task wants. Pick by the shape of the task: does the user need to keep their current context, how long is the interaction, how often will they do it, and does it block other work. Get that right and the pattern is obvious. Get it wrong and no amount of polish saves it.

This doc is the decision layer over the patterns documented elsewhere. The mechanics of each pattern live in their owner docs (dialogs, navigation, notifications, forms); this is where you decide which to reach for, plus full treatment of the few patterns the corpus didn't yet cover (wizard, accordion). The cardinal sin is mixing incompatible patterns into a Frankenstein that no mental model fits (see Avoid Franken-Patterns below).

The Pattern Decision Table

Pick the lightest pattern that fits the task's shape. Each row links to the doc that specifies it in full.

The rule: start at the lightest pattern that preserves the most context, and escalate only when the task genuinely needs it. Most "we need a modal" instincts are really "this could be inline."

Wizard & Stepper

A wizard breaks a linear process into ordered, dependent steps with visible progress. It's the right pattern when the task is genuinely sequential and too long for one screen, and the wrong one the moment it isn't.

Use a wizard when:

• The process is linear with more than three steps that depend on each other (each step's input shapes the next).
• Showing everything at once would overwhelm, and the order genuinely matters.

Don't use a wizard when:

• There are three or fewer steps, or the steps are independent. That's a single form, possibly with progressive disclosure (see forms.md — Multi-Step Forms, Progressive Disclosure). A wizard around a two-field task is ceremony.

Rules for a good wizard:

• Show progress. A stepper or progress bar tells the user where they are and how much remains. This is the Goal-Gradient Effect at work: visible proximity to the finish pulls users through (see cognitive-laws.md — Goal-Gradient Effect).
• Allow going back without losing entered data, and persist state between steps so a refresh or a back-press doesn't wipe progress.
• One coherent decision per step. If a step has a dozen unrelated fields, the wizard isn't actually chunking anything.
• Let the user see the path. Number the steps and, where possible, allow jumping to a completed step to review or edit.

// Stepper communicates position and progress (Goal-Gradient)
// Name goes on the <nav>, not the <ol>: list roles can't be named directly
<nav aria-label="Checkout progress">
  <ol>
    <li aria-current="step">1. Shipping</li>
    <li>2. Payment</li>
    <li>3. Review</li>
  </ol>
</nav>

Accordion

An accordion collapses sections so the user expands only what they need. It trades overview for focus, which is the right trade for some content and exactly wrong for others.

Use an accordion when:

• Content is hierarchical and consulted occasionally: an FAQ, settings groups, supplementary detail the user dips into one section at a time.
• The collapsed overview (just the headings) is itself useful as a map.

Don't use an accordion when:

• The user needs to compare content across sections. Hiding everything but one panel makes comparison impossible; show it all, or use a layout built for comparison (see ui/polish.md — Think Outside the Box, Tables).
• The content is short enough to just show. An accordion around two sentences adds a click for nothing.

Mechanics:

• Animate the expand/collapse so the height change reads as motion, not a jump (see ui/animation-and-motion.md — Accordion / Collapse).
• Decide single-open vs multi-open deliberately: single-open keeps focus, multi-open allows the user to keep several sections in view.
• The header is a real <button> with aria-expanded, so it's keyboard-operable and announced correctly.

Inline Edit

Inline editing lets the user change a value in place, toggling a display into an editable field, without a separate form or page. It's the lowest-friction way to edit a single thing.

Use inline edit when:

• The user is changing one field (a title, a status, a price) and a whole form would be overkill (see forms.md — Inline Editing).
• Keeping the surrounding context visible matters, which it usually does for a small edit.

Don't use inline edit when:

• The change spans many related fields, has complex validation, or is a multi-step commitment. That's a form, and forcing it inline makes it cramped and error-prone.

Make the edit affordance discoverable (the value looks editable on hover/focus), confirm on Enter or blur, allow Escape to cancel, and give clear feedback that the change saved (an optimistic update with rollback on failure feels instant, see interactions.md — Optimistic Updates).

Navigation Pattern by App Type

The top-level navigation shape follows the app's size and structure. This is a decision summary; the mechanics live in navigation.md — Primary Navigation Patterns.

• Sidebar for complex apps with more than ~5 sections or nested structure.
• Top bar alone for simple apps and landing/marketing surfaces with few destinations.
• Bottom tabs for mobile apps with 3 to 5 peer sections (thumb reach).
• Breadcrumbs for genuinely hierarchical structures more than two levels deep (see navigation.md — Breadcrumbs).
• Global search once the content set is large enough (roughly 50+ items) that browsing alone stops scaling (see search.md).

These combine: a complex app might have a sidebar, breadcrumbs, and global search at once. They conflict only when two patterns claim the same top-level "where am I" role.

Avoid Franken-Patterns

A franken-pattern is what you get from stitching incompatible patterns together: a wizard inside tabs inside an accordion, a modal that opens a drawer that opens another modal. Each pattern carries its own mental model, and combining clashing ones leaves the user with no model that fits.

• Don't nest blocking patterns (see dialogs.md — Stacking: one modal at a time).
• Don't combine patterns that fight over the same job (tabs and a wizard both claiming to sequence the same content).
• Check the design system before inventing a pattern. The pattern you need almost certainly already exists, and reusing it gives you Jakob's Law for free (see cognitive-laws.md — Jakob's Law). If it genuinely doesn't exist, adding it must be justified, not reflexive.

When a screen feels confusing despite clean visuals, count the patterns. More than two interaction models competing on one surface is usually the cause.

Checklist

Choosing

• Lightest pattern that preserves the most context, escalating only when needed
• Pattern chosen by task shape (context, length, frequency, blocking), not habit
• Modal reserved for confirmations / short focused forms; drawer for detail-in-context

Sequential & editable

• Wizard only for > 3 dependent steps; ≤ 3 or independent → simple form
• Wizard shows progress, allows back, persists state, one decision per step
• Accordion only when sections aren't compared; headers are real buttons with aria-expanded
• Inline edit for single fields; full forms get a form

Navigation & coherence

• Top-level nav matches app type (sidebar / top bar / bottom tabs / breadcrumbs / search)
• No franken-patterns (clashing or nested incompatible patterns)
• Design system checked before any new pattern is invented