The number that changes source depending on where you read it
Design systems are frequently justified with a claim of 47% faster development.
Follow the citations. One source attributes it to Sparkbox. Another attributes it to a 2022 study of IBM's Carbon Design System, reporting a median of two hours versus 4.2 hours for building from scratch. A third attributes it to Sparkbox again, but specifically for form development, dated 2024.
Same number, three sources, three scopes. Alongside it circulate claims of 38% gains for design teams, 31% for developers, and interface consistency improving conversion by up to 20%, generally citing vendor reports or internal case studies.
This is what citation drift looks like. A figure enters circulation, gets re-attributed, and acquires authority through repetition rather than replication.
There is better data available, and it is not about returns. It is about failure.
What the survey data actually shows
Sparkbox has run an annual design systems survey since 2018. The samples are small — 86 respondents in the first year, 71 in-house responses on the failure question in 2019, 157 responses on challenges in 2021 — and self-selected, shared through social media and Slack. Sparkbox is a studio that sells design system work.
Under the grading used across this series, that is thinly evidenced as a source of ROI claims.
It is more useful for something else. Across five consecutive years, the same failure modes appear:
Adoption is the top challenge every year since 2018. In 2021, 52% of agency respondents said lack of adoption was among the most common reasons client design systems failed.
42% of in-house respondents in 2020 felt the way their design system was originally built had created technical or design debt for the organisation.
35% of in-house teams in 2021 had considered or begun starting over on a new design system.
Just over 25% in 2018 described their system as average or unsuccessful, citing absence of an executive champion, adoption difficulty, and staffing.
36% in 2022 had no defined process for accepting contributions.
A consistent pattern across five years of a weak sample is worth more than a single impressive percentage from a vendor deck. The finding is not that design systems fail — most respondents report theirs meeting their needs. It is that when they fail, they fail the same way, for reasons that are organisational rather than technical.
The layers, and which one matters most
Design tokens. Named values for colour, spacing, type scale, radii, motion. The primitive layer. Tokens are the part that survives redesigns, platform changes, and framework migrations, because they encode decisions rather than implementations.
Components. Buttons, inputs, cards, navigation. Built from tokens, with defined states and variants.
Patterns. Recurring compositions — a form layout, an empty state, a checkout step. Where components combine into recognised solutions.
Documentation. What exists, when to use it, when not to, and what to do when nothing fits.
Most systems over-invest in components and under-invest in tokens and documentation. Tokens are what make a global change possible in one edit. Documentation is what determines whether anyone else can use the thing.
Atomic Design: useful vocabulary, held lightly
Brad Frost's Atomic Design proposes five levels borrowed from chemistry — atoms, molecules, organisms, templates, pages.
It is a documented practitioner method and its real contribution is shared language. Before it, teams had no agreed way to discuss the difference between a button and a checkout form, and the absence made component decisions unnecessarily contentious.
Held too literally it creates arguments. Whether a search field is a molecule or an organism consumes hours and changes nothing about the interface. The taxonomy is a communication aid, not a classification system requiring correctness.
The four failures, and what prevents each
Adoption. The most-reported problem, five years running, and rarely a design problem. Teams do not adopt a system when using it is slower than not using it, when it lacks what they need, or when nobody has been asked to. The preventive measures are unglamorous: make the system the path of least resistance, respond to gaps quickly, and have leadership state that it is the default.
Design and code drift. The library says one thing, production says another. Once developers cannot trust the system to match reality, they stop consulting it. Prevention is a single source of truth for tokens — generated from one definition into both design tools and code — rather than two parallel definitions maintained by goodwill.
Debt created at the outset. The 42% figure is the one worth sitting with. Systems built by capturing every existing variation encode the inconsistency they were meant to remove. A system should be built from decisions about what the interface will be, not from an audit of what it currently is.
No owner. Systems built by a project team and handed over decay from the day the team disbands. The survey data consistently names staffing and executive sponsorship among failure causes.
Treat it as a product
The single most useful framing. A design system has users — the designers and developers consuming it — and it succeeds or fails on whether they choose it.
That implies the same disciplines as any product. A named owner. A roadmap. A way for users to report gaps. A contribution process, which 36% of teams surveyed did not have. Versioning and release notes. Measurement of whether it is being used.
The measurement question is the practical one, and it does not require ROI modelling: what proportion of interface work uses system components rather than custom ones? That single figure tells you whether the system is working, and it moves for reasons you can investigate.
Where systems are over-built
Before there is anything to systematise. A pre-product-market-fit business building a comprehensive component library is optimising for repetition it does not yet have. Tokens plus a handful of components is the right scope.
Covering cases that occur once. Every component added has a maintenance cost forever. A component used in one place is a file, not a system entry.
Governance heavier than the organisation. Approval workflows suited to a hundred designers, imposed on six, produce a system nobody contributes to.
Diagnostic: will this system last?
Six tests.
Tokens are defined once and generated into both design tools and code, not maintained separately.
There is a named owner with time allocated, not a project team that has moved on.
A defined contribution process exists for teams that need something the system lacks.
The proportion of interface work using system components is measured.
The system encodes decisions about what the interface should be, rather than an inventory of what already existed.
Documentation states when not to use a component, not only when to use it.
Test one is the technical root of drift. Test two is the organisational root of everything else.
What this produces
Consistency that does not require anyone to remember.
That is the honest claim, and it is smaller than the marketing but more defensible. A design system does not make teams faster in a way anyone has convincingly measured. What it does is remove a category of decision from every piece of work — what should this button look like, how much space goes here — so that attention goes to the decisions that are actually specific to the problem.
The second effect matters more commercially. Consistency across touchpoints is what makes a brand read as one organisation rather than several. That is a positioning outcome delivered through an execution mechanism, which is why the system belongs to the business rather than to the design team.
Frequently asked questions
Do design systems actually save time?
The commonly cited figures — 47% faster development, 38% design gains — trace to vendor surveys and case studies with inconsistent attribution, and the same number appears against different sources and scopes. The consistency benefit is easier to defend than the speed benefit.
Why do design systems fail?
Survey data across five years names the same causes: adoption, maintenance, staffing, and absence of an executive champion. In 2021, 35% of in-house teams had considered starting over, and in 2020, 42% felt their system's original construction had created debt.
What are design tokens and why do they matter?
Named values for colour, spacing, type, and similar primitives. They matter because they encode decisions rather than implementations, which is what allows a change to propagate everywhere at once and what lets a system survive a redesign or platform change.
Is Atomic Design still relevant?
As shared vocabulary, yes. As a classification system requiring correct answers, no. Debating whether a component is a molecule or an organism consumes time and changes nothing about the interface.
When is a business too early for a design system?
Before there is repetition to systematise. A pre-product-market-fit business needs tokens and a small set of components, not a comprehensive library. Every component carries maintenance cost permanently.
How do we measure whether the system is working?
Track the proportion of interface work using system components rather than custom ones. It is a single number, it moves for investigable reasons, and it requires no ROI modelling.
Who should own the design system?
A named person or small team with allocated time, backed by leadership. Systems built by a project team and handed over decay from the day that team disbands — a pattern the survey data names repeatedly.
Sources
Sparkbox Design Systems Survey, 2018 to 2022 — annual self-selected samples, conducted by a studio offering design system services
Frost, B., Atomic Design
Published design system ROI claims, including the 47% development speed figure and its varying attributions
Structure your next phase
Zerologic builds design and brand expression systems that hold up in delivery — tokens, components, and the ownership structure that keeps them true.
Talk to us: partners@zerologic.io · zerologic.io
