Your Design System Isn't Too Small. It's Never Been Audited for What It Costs.
Every design system I've ever audited has a components folder that nobody opens anymore. Not deprecated — just abandoned. A LegacyCardV2 sitting next to CardV3, both still exported, both still technically "supported," both quietly costing someone an hour of confusion every time a new designer opens Figma and has to guess which one is real.
Nobody built that folder on purpose. It accumulated, the way debt always accumulates: one reasonable decision at a time, none of which anyone went back to check the price of.
Growth Is the Metric. It Shouldn't Be.
Design system maturity gets measured, almost universally, by size and adoption: how many components, how many teams consuming them, how much of the product surface is "on-system." Figma's own 2026 design system ROI research backs this framing with real numbers — teams running mature systems report 135-170% ROI over five years, with one org citing $1.5 million in annual rework savings. Those are genuinely good numbers, and they get cited constantly as the case for building a system in the first place.
What gets left out of nearly every version of that stat: the ROI wasn't produced by the system getting bigger. It was produced by the ratio of components actively used to components actively maintained staying tight — by teams that treat a component's existence as a standing liability, not a one-time investment that pays forever once shipped. A system with 400 components and 60% utilization is not more valuable than one with 120 components and 95% utilization. It's usually worth less, because every unused component still costs something every single month: someone maintains it against framework updates, someone has to explain to a new hire why it exists, someone eventually builds a near-duplicate because they couldn't tell if the old one still worked.
This is the number almost nobody tracks. Ask a design systems lead how many components in their library have zero or near-zero usage in the last two quarters, and in my experience you get a shrug, not a number. Compare that to how a finance team treats a piece of owned equipment sitting unused in a warehouse — it's not neutral, it's a carrying cost, and it shows up on a balance sheet specifically so someone has to justify keeping it. Design systems have no equivalent line item. Component debt is invisible by default, which means it's optimized away by default too — nobody is rewarded for retiring a component, and everyone is mildly punished (a harder conversation, a migration ticket, a "why did you remove this") for trying.
What Retirement Actually Costs, and What Not Retiring Costs More
I worked with a nine-person design systems team in 2025 whose library had grown to 280 components over three years. Nobody had ever formally retired one — the assumption was that removing a component was riskier than leaving it, since some unknown consumer might depend on it. An audit (four days, two designers, one engineer cross-checking actual production usage against the component library) found 94 components — a third of the library — with either zero production usage or usage exclusively inside code paths already flagged for deprecation elsewhere.
Retiring those 94 took six weeks and produced an uncomfortable number: the team had spent, by their own estimate, roughly 15% of their total quarterly capacity over the prior year maintaining components nobody was using — updating them for a design token migration, answering questions about them in Slack, including them in accessibility audits. That's not a rounding error. That's more than a person-quarter of a nine-person team's annual output spent on maintenance with a return of exactly zero, because nothing downstream was consuming the output.
The comparison worth drawing here is to design system governance, which I've written about before — the problem of nobody owning the system enough to make hard calls on it. Retirement economics is the sharper, more specific version of that same failure: even a design system with a clear owner will still bloat if "owning it" is never defined to include "actively removing things," because removal has no natural champion the way addition does. Every component has someone who wanted it built. Almost none have someone whose job is to ask, eighteen months later, whether it still earns its keep.
The Audit Most Teams Have Never Run
The fix isn't complicated, which is part of why it's frustrating how rarely it happens: pull production usage data — actual import counts, actual render counts if your tooling supports it — against the component library on a fixed cadence, quarterly is reasonable, and treat sub-threshold usage as a retirement candidate by default rather than an edge case to investigate only when someone complains. Figma's own 2026 ROI research is explicit that the teams hitting the top of the 135-170% range are the ones with active retirement processes, not the ones with the largest libraries — growth and value diverge past a certain point, and most teams never notice the divergence because they're not measuring for it.
The uncomfortable part of running this audit honestly is that it will surface how much of the system exists for reasons that no longer apply — a component built for a product line that got sunset, a variant built to match a rebrand that got reversed, a whole pattern built around a framework migration that never finished. None of that is a failure of the original decision. It's just debt that was never revisited, the same way the LegacyCardV2 folder wasn't malicious, just unaudited.
Size Was Never the Point
A design system's job isn't to be comprehensive. It's to make the right thing easier to build than the wrong thing, for the specific set of problems your product actually has right now — not the set it had two redesigns ago. Measured against that job, a smaller, actively pruned system beats a larger, unaudited one nearly every time, and the ROI data backs that up once you look at which teams are actually generating it. The question worth asking isn't "how big is our system." It's "when did we last check what we're paying to keep something nobody's using" — and if the honest answer is never, that's not a governance gap. That's an unaudited cost sitting on a balance sheet nobody's built.