Go Back

Interaction Patterns

What are Interaction Patterns?

Interaction patterns are standard, reusable ways users interact with digital products: how they navigate, give input, get feedback, and complete tasks. They make behaviour predictable so users can transfer what they’ve learned from other products.

Use it when: you’re defining how a control or flow should behave and want consistency and familiarity (e.g. buttons, forms, loading states, modals).

Copy/paste template

  • User goal: [what the user is trying to do]
  • Pattern: [e.g. primary button, inline validation, loading spinner]
  • Trigger: [what the user does: click, type, scroll]
  • Feedback: [what they see/hear: state change, message, animation]
  • Accessibility: [keyboard, focus, screen reader, reduced motion]

Why Interaction Patterns matter

  • Make interfaces feel familiar and predictable, which reduces errors and support.
  • Speed up design and development by reusing established behaviours.
  • Support accessibility when patterns are implemented with keyboard, focus, and screen reader in mind.
  • Reduce cognitive load: users don’t have to learn new behaviour for every screen.
  • Align design and development around a shared vocabulary.

What a good interaction pattern includes

Checklist

  • [ ] Clear trigger and feedback: user action leads to a visible (or announced) result.
  • [ ] Consistent with the rest of the product and with platform conventions where appropriate.
  • [ ] Keyboard and focus work correctly; focus is managed in modals and flows.
  • [ ] Screen reader support (labels, live regions, ARIA when needed).
  • [ ] No reliance on colour alone; consider reduced motion where relevant.

Common formats

  • Input patterns: buttons, links, form fields, dropdowns, toggles, sliders, date/time pickers.
  • Feedback patterns: loading states, success/error messages, tooltips, progress indicators, empty states.
  • Navigation patterns: tabs, breadcrumbs, pagination, infinite scroll, back/forward.

Examples

Example (the realistic one)

A team adds a "Save draft" action. They use the same secondary button pattern used elsewhere: outline style, clear label, placed next to the primary "Publish" button. On click, they show a brief success message (toast) and keep the user on the page. Keyboard: both buttons are focusable and activatable with Enter/Space. Screen reader: button names and success message are announced. The behaviour matches other save actions in the product.

Common pitfalls

  • Hidden or inconsistent behaviour: same action behaves differently in different places. → Do this instead: use one pattern per type of action and document it; implement via shared components.
  • No or poor feedback: user isn’t sure if their action worked. → Do this instead: every meaningful action gets clear feedback (state change, message, or microinteraction).
  • Accessibility afterthought: pattern works with mouse but not keyboard or screen reader. → Do this instead: design and build keyboard and screen reader behaviour from the start; use ARIA roles where native HTML isn’t enough.
  • Overly custom: inventing new behaviour when a standard pattern would do. → Do this instead: prefer familiar patterns unless you have a strong, user-validated reason to diverge.
  • Interaction patterns vs interface patterns: Interaction patterns focus on behaviour (trigger, feedback, flow); interface patterns focus on layout and structure (e.g. forms, tables). They overlap; many patterns cover both.
  • Interaction patterns vs microinteractions: Microinteractions are small, contained moments (e.g. button hover, like animation); interaction patterns are the broader conventions (e.g. "how buttons work").
  • Interaction patterns vs motion design: Motion design is the use of animation and transition; interaction patterns define when and how feedback happens, which may include motion.

Next step

If you’re defining how controls behave, document patterns in your design system and implement them in your component library. For small feedback moments, see microinteractions and motion design. Always include accessibility in the pattern.