Interaction patterns

Interaction Patterns

Concept of the skill

An interaction pattern is the chosen shape of how a user makes a decision or takes an action on a surface — tabs versus pages, dropdown versus combobox, stepper versus wizard, modal versus inline edit, command menu, disclosure, bulk selection, filtering, and the rest. The discipline is to derive that choice from the shape of the user's decision rather than from a catalogue of available components. Two questions settle most cases: what is the user actually deciding (compare, choose one, choose many, sequence, search, edit, confirm, or recover), and what is the choice set like (small, large, searchable, hierarchical, ordered, destructive, reversible, repeated)? From those the simplest pattern that keeps the needed context visible follows. A chosen pattern is then pressure-tested against its edges — selection, cancel, escape, undo, invalid action, keyboard alternatives to pointer gestures, and behavior under loading, empty, error, and permission-limited states. Pattern choice is upstream of component design and accessibility implementation: it decides which control the user faces; the component API and the ARIA wiring come afterward.

Coverage

Choose and audit interaction patterns before implementation. Covers control selection, mode switching, progressive disclosure, modals, drawers, tabs, accordions, command menus, comboboxes, steppers, wizards, inline edit, bulk selection, filters, sorting, gestures, keyboard alternatives, and pattern fit under task pressure.

The decision shapes that drive pattern choice are: compare (the user must weigh options side by side — favors visible options over hidden ones), choose one (single selection from a set — radio/segmented for small sets, dropdown/combobox for large), choose many (multi-selection — checkboxes, tag inputs, bulk-select with a contextual action bar), sequence (ordered steps — stepper for short known sequences, wizard only when ceremony is genuinely warranted), search (the set is large and the user knows what they want — combobox/command menu), edit (modify a value in place — inline edit when context must stay, modal/panel when the edit is involved), confirm (a deliberate gate before a consequential action), and recover (undo, cancel, escape, retry).

Choice-set characteristics modulate the pattern: a small closed set tolerates always-visible controls; a large set needs search; a hierarchical set needs nesting or a tree; an ordered set needs a sequence pattern; a destructive action needs a confirm or an undo window; a reversible action can skip the confirm in favor of undo; a repeated action favors keyboard-first and bulk patterns.

Hidden options (in dropdowns, accordions, overflow menus) are acceptable only when comparison is not required. Modals are justified only when the interaction genuinely needs to block the surface; otherwise a drawer, panel, or inline pattern keeps context. Every pointer-only gesture needs a keyboard or explicit-control alternative before handoff.

Philosophy of the skill

Most confusing interfaces are not missing components; they chose the wrong pattern for the decision the user has to make. A dropdown hides options that need comparison. A modal blocks context the user needs. A wizard adds ceremony to a task that only needed one form.

Choose the pattern from the user's decision shape: compare, choose one, choose many, sequence, search, edit, confirm, or recover. The component and its styling are consequences of that choice, never the starting point.

The simplest pattern that keeps the needed context visible wins. Complexity in interaction is a cost paid on every use; the burden of proof is on the more elaborate pattern, not the simpler one.

Method

1. Name the user decision or action the control must support.
2. Classify the choice set: small, large, searchable, hierarchical, ordered, destructive, reversible, or repeated.
3. Choose the simplest known pattern that keeps needed context visible.
4. Preserve alternatives for keyboard and non-pointer users before handoff to a11y.
5. Define what happens on selection, cancel, escape, undo, and invalid action.
6. Check whether the pattern works with loading, empty, error, and permission-limited states.
7. Hand off feedback-state staging to interaction-feedback and component API concerns to design-system-architecture.

Verification

• The pattern matches the user's decision type.
• Hidden options are acceptable only when comparison is not required.
• Context needed to decide is visible or intentionally preserved.
• Cancel, escape, undo, and invalid-action behavior are defined.
• Pointer-only gestures have a keyboard or explicit control alternative.
• Loading, empty, error, and disabled states fit the pattern.
• Accessibility implementation is handed off to a11y.

Do NOT Use When

Use instead	When
a11y	The task is ARIA roles, keyboard behavior, focus management, labels, or WCAG compliance.
task-analysis	The user goal, top task, or flow breakpoint is still unknown.
interaction-feedback	The pattern is chosen and the task is feedback timing, progress, optimistic UI, or state visibility.
design-system-architecture	The task is reusable component APIs, variants, slots, tokens, or governance.
component-architecture	The task is the component-library layering (primitive/composite/assembly) and headless/styled or controlled/uncontrolled API splits.
form-ux-architecture	The surface is primarily a form with validation, field grouping, and submission lifecycle concerns.