Complete the lesson quiz and earn 250 XP.
Before you can build a design system, you must understand the current reality of your product. Pioneered by Brad Frost, an Interface Inventory is a comprehensive visual audit that catalogs every distinct design pattern currently living in production.
Teams review live apps and take screenshots of every variation of:
The inventory is then arranged onto a giant digital whiteboard (Figma or FigJam) to reveal the true extent of UI debt across the organization.
When design leads tell executives 'Our product looks inconsistent', executives often shrug it off as minor aesthetic nitpicking.
However, when you conduct an interface inventory and present hard quantitative data, leadership acts immediately:
Framing UI inconsistency as technical debt, maintenance overhead, and conversion risk transforms the design system from an optional aesthetic project into a critical business priority.
During an interface inventory, teams uncover two distinct categories of discrepancies:
An interface inventory should never be conducted in secret by a design team working in isolation. If designers show up and say 'Here is everything wrong with your code', engineers will become defensive.
The Consolidation Workshop Format:
Shared decision-making builds organizational ownership from day one.
Once canonical components exist, how do you replace thousands of legacy buttons and forms across a giant codebase?
The 'Big Bang' Fallacy: Attempting to rewrite the entire application in one giant PR always fails. It introduces hundreds of merge conflicts, delays feature releases, and causes production outages.
The Strangler Fig Pattern (Incremental Migration):
Consolidating components is only half the battle. How do you prevent developers from immediately introducing new UI debt by typing color: #0052cc next week?
High-performing teams automate discipline using ESLint and Stylelint rules:
#3B82F6) or raw pixel margin (margin: 17px), prompting the developer with an auto-fix to the corresponding design token.<button> or <select>), requiring squads to import <Button> and <Select> from @system/react.UI debt does not originate in code; it originates in design files. When a designer creates a mockup with detached component layers, custom hex values, or random 13px paddings, engineers assume those specs are intentional and write custom code.
Modern design teams use Figma Design Linters:
How do you know if your migration is actually succeeding? You must measure System Adoption Coverage continuously.
Leading teams use automated scanning scripts (such as GitHub Primer's component telemetry or custom Babel AST scanners):
$$\text{Adoption Coverage} = \frac{\text{Imports from } @system/components}{\text{Total Component Instances in Codebase}} \times 100$$
Publishing an internal monthly dashboard showing adoption progress keeps squads motivated and transparent.
Imagine you are hired as the Head of Design Systems for an enterprise travel booking company with 12 legacy web applications. Your initial inventory reveals:
The 4-Step Action Plan:
color-bg-surface, color-text-muted).@system/button imports.