An audit of every UI pattern, component, and interaction currently in use across a product — typically conducted as a precursor to building or consolidating a design system. A pattern inventory reveals inconsistencies, redundancies, and proliferating variations that should be resolved before they are codified.
Common contexts
- Screenshotting every button variant across a legacy product before scoping a design system migration
- Cataloguing all modal dialog implementations in a codebase to find which three can be merged into one component
- Mapping every date-picker interaction across a multi-product suite to decide on a single unified pattern
Use when
Conduct a pattern inventory before starting any design system initiative or major redesign — particularly when the product has grown organically across multiple teams and you need evidence to justify consolidation investment to stakeholders.
Avoid when
Don't run a full pattern inventory for a greenfield product that has fewer than ten live screens — the overhead of cataloguing will exceed the value, and you're better served designing consistent patterns from scratch.
The number of button variants in a product is a direct proxy for how long the organisation has gone without a shared design language — screenshot them all before any stakeholder meeting where you need to argue the case for a design system.
Real-world examples
- Before building Shopify's first design system, their team performed a pattern inventory of all UI components across 12 admin pages, finding 47 distinct button styles — a number that justified the system investment.
- The UK Government Digital Service conducted a pattern inventory across 400 agency websites before building GOV.UK, finding 200+ inconsistent form patterns that were consolidated into 12 reusable components.
- Nielsen Norman Group recommends starting design system projects with a pattern inventory because it creates concrete evidence of inconsistency that persuades stakeholders to fund standardisation efforts.