← Go Back

Interface Patterns

What are Interface Patterns?

Interface patterns are proven, reusable solutions to common user interface design problems. They give teams standard ways to handle navigation, forms, data display, and feedback so interfaces stay consistent, usable, and easier to build.

Use it when: you’re designing or building a feature and want to use a familiar, tested approach instead of inventing a new one.

Copy/paste template

  • Problem: [what the user needs to do or understand]
  • Pattern: [e.g. breadcrumbs, inline validation, data table with sort/filter]
  • Rationale: [why this pattern fits: consistency, a11y, familiarity]
  • Variations: [any allowed variants, e.g. compact vs full]
  • Accessibility: [keyboard, focus, screen reader, contrast]

Why Interface Patterns matter

  • Speed up design and development by reusing known solutions.
  • Keep the product consistent so users learn once and apply everywhere.
  • Improve accessibility when patterns are implemented with accessibility in mind.
  • Reduce decision fatigue and arguments over "how we do" common tasks.
  • Make it easier to maintain and evolve the product over time.

What a good interface pattern includes

Checklist

  • [ ] Clear purpose and when to use it (and when not to).
  • [ ] Documented behaviour (states, edge cases, keyboard and screen reader).
  • [ ] Consistent with the rest of the product and, where relevant, with design systems.
  • [ ] Accessible (keyboard, focus, labels, WCAG where applicable).
  • [ ] Implemented once in code (e.g. in a component library) and referenced from docs.

Common formats

  • Navigation patterns: breadcrumbs, tabs, sidebar, hamburger, pagination, search.
  • Form patterns: progressive disclosure, inline validation, smart defaults, error handling, multi-step.
  • Data display: tables (sort, filter, paginate), cards, lists, empty states.

Examples

Example (the realistic one)

A team needs to show "where you are" in a multi-level help section. They choose a breadcrumb pattern: text links, separated by chevrons, with the current page as text (not a link). They document it in their design system, implement one Breadcrumb component with proper ARIA and keyboard support, and reuse it across the product so behaviour and look stay consistent.

Common pitfalls

  • Pattern for pattern’s sake: using a pattern that doesn’t fit the task. → Do this instead: pick the pattern that best matches the user goal and context.
  • Inconsistent implementation: same pattern implemented differently in different places. → Do this instead: one source of truth (component + docs) and reuse it everywhere.
  • Ignoring accessibility: pattern works visually but not with keyboard or screen reader. → Do this instead: document and implement keyboard, focus, and ARIA (or semantic HTML) from the start.
  • Over-customising: so many variants the "pattern" is no longer consistent. → Do this instead: allow a small set of variants; treat new needs as a new pattern or a separate component.
  • Interface patterns vs interaction patterns: Interface patterns are broad (navigation, forms, data); interaction patterns often focus on how users act (click, drag, scroll) and the feedback they get. Overlap is common; both support consistent UX.
  • Interface patterns vs components: A pattern is the solution and its rules; a component is the coded implementation. One pattern can be one (or more) components.
  • Interface patterns vs design system: The design system includes patterns, components, tokens, and guidelines; patterns are one part of that system.

Next step

If you’re building or documenting UI, align with your design system and component library. For how users interact with elements, see interaction patterns and microinteractions. Ensure accessibility is part of every pattern.

Related Terms