In design system work, what is an interface inventory, and why run one before building shared components?
answer
- look before you build
- catalogue what actually ships
- grouped by category, then counted
- variants make inconsistency visible
- evidence for scope and support
basics
~20 sAn interface inventory is a systematic catalogue of the colors, type styles, spacing, icons and components a product actually uses, grouped and counted. It exposes duplication and inconsistency, grounds the system's scope in evidence, and helps win stakeholder support.
solid answer
~50 sAn interface inventory walks through a product — its screens and its code — and records every instance of each UI element: colors, type styles, spacing values, icons, and components such as buttons, form fields and tables, grouped by category with counts. For a university course-registration portal it might reveal seven slightly different primary buttons and four different search-field designs. Running one before building does three things: it shows what the system actually needs to cover, so scope comes from evidence rather than guesses; it makes the cost of inconsistency visible, which helps win support from stakeholders who see many versions of the same button side by side; and it sets a baseline to measure progress against later. It is a snapshot of the current state, not a design proposal — deciding what to consolidate comes afterwards.
go deeper
Recall what an interface inventory catalogues — colors, type, spacing, icons, components and states actually in use — and that it groups and counts them.
Explain why it comes before building: scope from evidence, a visible cost of inconsistency, shared vocabulary and a baseline for measuring progress later.
Show how you would run one across web and native mobile with the owning teams, and how you keep it a record of the current state rather than a premature design decision.
Treat the inventory as an argument as much as a record: it is often the evidence that secures funding and cross-team support for building a system at all.
## What an interface inventory is An **interface inventory** is a structured catalogue of the user-interface elements a product really uses, gathered before a **design system** — the shared foundations, components and guidance that product teams consume — is built or expanded. The team walks through the product and its code, captures every instance of each element, groups the instances by category, and counts the variants. The key word is *really*. An inventory records what ships to users today, not what a style guide says should exist or what the latest design file shows. ## What it records Typical categories, adjusted to the product: - **Colors** — text, background, border and status colors, with where each is used. - **Typography** — font families, sizes, weights and line heights, grouped into the styles actually in use. - **Spacing** — margins, gaps and padding values. - **Icons** — every glyph, its size and style, and duplicates drawn differently. - **Components** — buttons, form fields, selects, tables, cards, navigation, messages, and their visible variants. - **Patterns and states** — empty, loading and error states, and how recurring tasks such as search or filtering are presented. For each category, the useful output is a **grouped collection with counts**: nine button styles, thirty-one grays, five spinner designs. ## Why run it before building 1. **Scope from evidence.** The inventory shows which elements are used everywhere and which appear once, so the system covers real needs rather than a guessed list. 2. **Visible cost of inconsistency.** Putting many near-identical versions of the same element side by side makes the problem obvious to stakeholders who never read code, which helps fund and support the work. 3. **Shared vocabulary.** Naming and grouping elements together gives designers and engineers a common language before the system defines its own. 4. **A baseline.** Later, the same counts show whether inconsistency is shrinking. 5. **Early defect discovery.** Colors that fail contrast, icons without text alternatives, or components that behave differently on web and native mobile surface while cataloguing. ## What it is not | Activity | Question it answers | Relationship to the inventory | |---|---|---| | Interface inventory | What UI does the product use today? | This practice | | User research | What do users need and how do they behave? | A separate discipline; the inventory studies the interface, not the people | | Token and component design | What should the shared values and components be? | Comes after, using the inventory as input | | Ongoing drift detection | Is shipped UI diverging from the system? | A later, continuous practice once the system exists | ## Example: a university course-registration portal A team inventories a portal where students search the course catalog, view sections, build a timetable and register. Working through web and mobile screens, they capture seven primary-button styles across search, the registration cart and the advisor pages; four search-field designs; three ways of showing that a section is full; and an icon set where the calendar glyph exists in two drawings. They group each category on a shared board with counts, note which variants appear on high-traffic screens, and flag a light-gray help text that looks too faint to read. Nothing is decided yet — the inventory's job is to make the current state undeniable and give the next decisions something concrete to stand on.
- Who should take part in an interface inventory, and why not only the design system team?Designers, engineers and, ideally, product owners from the teams whose UI is being catalogued. Doing it together builds a shared vocabulary, surfaces why variants exist, and turns the findings into a collective problem rather than an outside critique, which makes later adoption of the system easier.
- Is an interface inventory a one-time exercise?The first inventory is a snapshot taken before building, but repeating it later shows whether inconsistency is actually shrinking. Continuous detection of design-to-code drift once the system exists is a separate practice; the inventory's lasting value is the baseline it sets and the evidence it gives early decisions.
saying these in an interview costs you the question
- An interface inventory is the same thing as a user research study.
- Only components matter; colors, type and spacing can be skipped.
- Design files alone show what the product really ships.
- The inventory itself should decide the final set of components.
- Counting variants is pointless; a list of component types is enough.