Design Systems: The Cost Nobody Budgets
Survey data on contribution rates, parallel systems and measurement, three signals that a system costs more than it saves, and why vendor return figures should be read carefully.
Date
Category
Writer
There is a number in the zeroheight Design Systems Report 2025 that should stop anyone about to sign off on a design system budget. The report surveyed 294 people between September and November 2024. Among organisations with more than 1,000 employees, the typical design system has one to five contributors, which the report puts at roughly one per cent of the workforce.
One per cent. That is the group carrying the component library, the token pipeline, the documentation, the migration guides, the accessibility review, the Figma library hygiene, the release notes and the support queue for everyone else. The system is sold internally as leverage. The staffing says something closer to a tax collected from a very small number of people.
I want to lay out the economics honestly, because the published material is unusually good and almost nobody reads it. Four surveys and a handful of practitioner essays give us most of what we need.
What the surveys actually found
Sparkbox has run a design systems survey for several years. The 2022 edition had 219 responses, 183 of them from maintainers and 37 from people who only consume a system. The top five challenges maintainers reported were technical debt (43 per cent), design and code parity (37 per cent), adoption (36 per cent), staffing (35 per cent) and governance (33 per cent).
Look at that list again. Not one of those is a design problem. Every one is an operating cost.
The 2021 survey, with 376 responses, is blunter still. Fifty-three per cent of respondents said their design system itself creates debt. Fifty-four per cent said users of the system rarely or never contribute back. Only 29 per cent had a well-defined contribution process. Thirty-one per cent tracked any metrics at all, which means roughly two thirds of the systems in that sample could not have told you whether they were working.
The figure I find hardest to argue with is this one: 39 per cent of respondents said their organisation was already running more than one design system, and 35 per cent said they were considering starting another. The single most cited reason for starting a new one was difficulty with adoption and cross-team silos.
That is the fork, appearing in survey data. A system that fails to get adopted does not get retired. It gets duplicated.
The zeroheight 2025 report tells the same story from the resourcing side. Seventy-nine per cent of respondents had a dedicated design system team, but only 55 per cent described that team as fully resourced. Sixty-three per cent named lack of resources and staffing as their top challenge, ahead of consistency (52 per cent) and prioritising updates (50 per cent). Forty-one per cent cited insufficient budget. The report states plainly that "resources are more constrained than they've ever been".
The costs, and the phase they appear in
The reason design system budgets are wrong is not that people underestimate the build. They usually get the build roughly right. The error is that almost every real cost arrives after the build, in a phase nobody has a line item for.
Phase | Cost that appears | Usually budgeted |
|---|---|---|
Audit and inception | Inventory of existing patterns, stakeholder alignment, naming arguments | Yes |
First build | Component construction, Figma library, initial documentation | Yes |
First adoption | Per-team onboarding, pairing, answering the same question fifteen times | Rarely |
Steady state | Support queue, triage, bug fixes, dependency upgrades, release notes | Rarely |
Contribution | Reviewing outside work to a standard the core team can live with | Almost never |
Versioning | Deprecation policy, codemods, parallel support of two majors | Almost never |
Migration | Product team engineering time, regression testing, visual QA across surfaces | Almost never |
Drift and parity | Reconciling design files against shipped code after both have moved | Almost never |
Decline | Maintaining a system a portion of the organisation has quietly left | Never |
The pattern is consistent. Costs that are legible to a project plan get funded. Costs that are continuous, distributed and unglamorous do not. Nielsen Norman Group put it flatly in Design Systems 101: "Design systems, unfortunately, are not a one-and-done solution", and "Creating and maintaining a design system is a time-intensive activity which requires a dedicated team."
The migration cost is the one that bites
A design system with real adoption is a dependency. Every breaking change you make is work you have handed to teams who did not ask for it and cannot decline it. This is the cost that most reliably exceeds its estimate, because the estimate is made by the system team and paid by everyone else.
The instinct is to avoid breaking changes. The consequence of avoiding them is that the system accumulates compatibility layers, deprecated props that never die, and components with three ways to do the same thing. That is the 43 per cent reporting technical debt as their top challenge. You can pay for migrations or you can pay for debt. There is no third option where the system stays clean and nobody has to move.
Three failure modes
The system that forks
Forks are not usually acts of rebellion. They are what happens when the cost of waiting exceeds the cost of copying. A product team needs a variant, the contribution queue is six weeks deep, the component is close enough to copy, and a parallel component is born. Multiply by eighteen months.
The zeroheight report quotes a respondent on exactly this dynamic: "Because teams prioritise shipping features, they want to use what already exists rather than spend time adding to it". The same pressure that drives adoption drives forking, depending on whether the system happens to already contain what the team needs.
A fork is not a governance failure. It is a pricing signal. Someone measured the cost of going through your process against the cost of going around it, and your process lost.
The component nobody uses
Sparkbox found only 16 per cent of maintainers tracked metrics in 2022, and 31 per cent in 2021. If you do not measure component usage you will keep building components on the strength of the loudest request, and you will never find out which ones are dead.
Dead components are not free. They appear in documentation, they show up in search, they get upgraded when the framework version changes, they get reviewed for accessibility, and every one of them widens the surface area a new team has to understand before they can start. A library of 120 components where 40 carry all the traffic is a worse product than a library of 45.
The subscriber side of the 2022 survey is instructive here. Sixty-five per cent of people required to use a system said it met their needs. Their top complaints were poor documentation (39 per cent), unclear status of features (35 per cent) and missing functionality (26 per cent). Note the second one. A third of users could not tell what state a given piece of the system was in. That is a direct product of a library that has grown past the point where its owners can describe it.
Three names for one colour
Token layers are where systems quietly become unaffordable. The standard architecture is three tiers: a primitive palette, a semantic layer, and component-level tokens. Each tier is defensible. Together they produce this:
Nathan Curtis, who has written more carefully about token naming than anyone, sets out the possible levels in Naming Tokens in Design Systems (October 2020) as category, property and concept, plus modifiers for variant, state, scale and mode, plus object levels for components and their elements, plus namespaces for system, theme and domain. His warning is the part people skip: "Avoid dogmatically including all levels possible or duplicating token-tuples redundantly", and "Don't globalize decisions prematurely".
The interoperability problem behind this is real and still unsolved. The Design Tokens Format Module from the Design Tokens Community Group exists precisely because, as the draft puts it, tool-specific exports mean "the burden is therefore on design system teams to create and maintain their own, bespoke 'glue' code". That specification remains a draft community group report. Anyone budgeting a token pipeline on the assumption that a stable standard will arrive and absorb the maintenance is budgeting on a hope.
Governance is not paperwork, it is the product
Nathan Curtis's Team Models for Scaling a Design System, published in September 2015 and still the clearest short treatment, names three shapes: solitary, centralised and federated. He is sharp about the first. In the solitary model, "The overlord's primary motive is inward on their own product." Everyone else is adopting a byproduct of somebody else's roadmap.
The survey data tracks his taxonomy. Sparkbox 2021 found 46 per cent centralised, 26 per cent solitary, 24 per cent federated. zeroheight 2025 found 50 per cent centralised, 41 per cent hybrid and only 9 per cent federated. Federation is what most teams say they want and very few sustain, because it requires people to do system work that their own performance review does not measure. Curtis warned in 2015 that without sustained maintenance work "that living style guide seems quite dead" within a year.
If you want to see what a genuinely rigorous contribution model costs, read the GOV.UK Design System contribution criteria. To propose a component you must show that "There is evidence that this component or pattern would be useful for many teams or services" and that it does not duplicate something existing. To publish it, the implementation must be usable, meaning "It has been tested in user research and shown to work with a representative sample of users, including those with disabilities", as well as consistent with existing styles and versatile across services, browsers and assistive technologies.
That is the correct bar for a system used across government. It is also a full research and engineering programme per component. A studio or a mid-size product organisation that adopts that bar without adopting the staffing will simply have no contributions, which is the 54 per cent in the Sparkbox 2021 data.
The claim I would push back on
The business case for design systems is usually made with figures from vendor case studies. Figma's The New Business Case for Design Systems cites Freshworks reporting a 28 per cent reduction in customer service costs and Grammarly reporting that its system saved design and development teams 25 per cent of their work week.
Those may well be true. But they are self-reported figures from companies discussing their own systems, published by a company that sells design system tooling, and I could not find a published methodology for either number. They are not independent measurement, and they should not be used as a planning assumption. The honest position is that the aggregate return on design systems has not been measured well by anyone, and the surveys that do exist measure effort and frustration far better than they measure savings.
The crossover point
A design system costs more than it saves when the marginal cost of routing a decision through it exceeds the marginal cost of making that decision locally. That sounds abstract. In practice there are three legible signals, and all three are visible in the published data.
My own error, and I will name it because it cost a client real money: I built a three-tier token architecture for an organisation with two products and one brand. The semantic layer had no second consumer to justify its existence. It bought nothing except an extra indirection that every new person had to learn and every change had to pass through. The correct answer for two products and one brand is a palette and a small set of semantic aliases, added when a second theme actually appears. I built for a future scale that never arrived, and the cost of that decision showed up every week for two years.
The useful question is not whether to have a design system. Most organisations past a certain size already have one, whether or not it is named. The question is how much of it to formalise, and the honest answer is: only the parts where duplication is currently costing you more than governance would. Everything else is a cost you have chosen to carry in exchange for a consistency nobody outside the team has asked for.
Sources
zeroheight, Design Systems Report 2025, survey of 294 respondents conducted September to November 2024. - Design System Report 2025 - release version.pdf
Sparkbox, The 2022 Design Systems Survey, 219 responses. designsystemssurvey.sparkbox.com/2022/
Sparkbox, The 2021 Design Systems Survey, 376 responses. designsystemsurvey.sparkbox.com/2021/
Nathan Curtis, "Team Models for Scaling a Design System", EightShapes, 17 September 2015. medium.com/eightshapes-llc/team-models-for-scaling-a-design-system-2cf9d03be6a0
Nathan Curtis, "Naming Tokens in Design Systems", EightShapes, 15 October 2020. medium.com/eightshapes-llc/naming-tokens-in-design-systems-9e86c7444676
Design Tokens Community Group, Design Tokens Format Module, draft community group report. designtokens.org/tr/drafts/format/
Therese Fessenden, "Design Systems 101", Nielsen Norman Group, 11 April 2021. nngroup.com/articles/design-systems-101/
Government Digital Service, "Contribution criteria", GOV.UK Design System. design-system.service.gov.uk/community/contribution-criteria/
Figma, "The New Business Case for Design Systems", Figma Blog. figma.com/blog/the-new-business-case-for-design-systems/
Related reading
Latest Articles.
© Moc Mallen Studio
Thoughts, ideas, and perspectives on design, simplicity, and creative process.
