Component Inventory
Date: 2026-08-16
Cataloguing what already exists before building what’s missing. It’s dull, it’s the first step of every successful design system, and its real output is the argument for funding rather than the list.
A component inventory is a systematic audit of the UI elements currently in production — every button, field, card and modal, screenshotted and grouped.
Why it comes first
Three outputs, and the list is the least valuable:
- The evidence. Thirty-seven button styles on one page is an argument no one counters. Abstract appeals to consistency lose to roadmaps; a wall of near-identical buttons doesn’t
- The scope. You cannot plan a system without knowing what it must replace
- The priority order. Frequency tells you what to build first, and it’s rarely what anyone guessed
Skipping it produces a system built on assumption — usually a beautiful component set that doesn’t cover the cases the product actually has, which then gets worked around.
Doing it
1 pick the surfaces
highest-traffic pages, plus one of
each template type. NOT everything
2 capture
screenshot every distinct element,
in every state you can reach
3 group by INTENT, not appearance
← the step that does the work
4 count occurrences per variation
5 note the differences within a group
Step 3 is where the value is. Grouping by appearance produces “blue buttons” and “grey buttons”. Grouping by intent produces:
PRIMARY ACTION 14 variations
differences: 3 heights, 4 corner
radii, 2 fonts, 5 blues, 3 paddings
DESTRUCTIVE ACTION 6 variations
differences: 4 reds, 2 with icons,
1 that isn't red at all
The second framing is the finding. Fourteen things doing one job, differing in ways nobody chose.
What the numbers usually show
distinct button styles 20–40
distinct greys 15–30
distinct font sizes 15–25
distinct spacing values 30+
form fields that differ most of them
error message patterns one per dev
Spacing is always the worst and always the biggest surprise — dozens of values where anyone would have guessed five — Spacing Systems.
Automate what you can
Manual auditing doesn’t scale past a few templates, and it goes stale immediately.
FROM THE CODEBASE
computed styles across rendered pages
→ every colour, font-size, spacing
value actually used, with counts
FROM THE DESIGN FILES
unlinked / detached components
local styles not from the library
A script that dumps every distinct computed value with a frequency count is an afternoon’s work and finds more than a week of screenshotting. It also re-runs, which turns a one-off audit into a drift metric — Design System Adoption.
The manual pass is still needed for grouping by intent, which no script can do.
Reading the result
HIGH COUNT, LOW VARIATION
15 buttons, all nearly identical
→ easy win, standardise now
HIGH COUNT, HIGH VARIATION
15 buttons, genuinely different
→ real variants exist; find the axes
LOW COUNT, HIGH VARIATION
3 date pickers, all different
→ probably three teams, no sharing.
A governance signal, not a design one
One-offs are data too. A component appearing once may be a genuine special case — or the first instance of a pattern about to spread. Note it, don’t systematise it yet.
Keeping it alive
An inventory is a snapshot, and its value decays.
Re-run the automated part on a schedule and trend the counts. Distinct colours falling from 28 to 9 is the clearest evidence a system is working, and it’s the number to show whoever funds it.
The inventory that only exists once was a project. The one that re-runs is a metric — Design System Governance.