A design system is not an asset you buy once. It is a service you either run or slowly lose.
The return is real, and smaller than the slides say
The business case for a design system usually rests on two studies. Both are honest, and both are smaller than the way they are quoted.
In Figma's study, designers finished a task in 34% less time when they had an up-to-date design system (Figma, 2019). Figma did not publish how many designers took part. The author is careful: he expects this to be the maximum a team would see in real work, because the system in the test was current and relevant to the task.
In Sparkbox's study, eight developers built one contact form in a median of 2 hours with IBM's Carbon design system, against 4.2 hours from scratch (Sparkbox). The authors call it "a small study of a handful of excellent developers". The form was built from scratch first, and two of the from-scratch versions were more accessible than their Carbon versions.
The most transparent model I know, by Maximilian Speicher and Guido Baena Wehrmann, prints its formula, lists its assumptions and recommends reporting about ±25% around any result (Smashing Magazine, 2022). Its time savings are averages of studies like the two above. It is a good model. It is still a model.
I looked for an independent study that measures the return of a design system across a whole organisation over time, and found none. That is the honest limit of the ROI case. And notice the condition hidden inside the best evidence: the system has to be current. A system that has drifted does not return the time these studies measured.
Drift is work done twice
Imagine a product company with three apps and one design system. In March, a designer detaches the card component to meet a launch date. In April, an engineer on another team builds a new dialog, because the system's dialog does not support a footer and nobody answers the request in time. In May, an AI coding agent copies that dialog into a third app, because it was the nearest example. Each choice was reasonable. Nobody decided to leave the system. By the summer there are three dialogs, two cards and a Figma library that describes none of them.
This is drift, and practitioners report it plainly. Maintainers name technical or creative debt (43%) and parity between design and code (37%) as their top challenges (Sparkbox Design Systems Survey 2022). AI makes it faster: 59% of practitioners report interface bypassing the design system, half say it is causing real problems, and 44% of organisations tolerate it (zeroheight, State of AI in Design Systems 2026, 123 respondents).
The cost of drift is not the duplicate itself. It is everything that follows: two components to fix when an accessibility issue is found, two answers when someone asks which one to use, and a little less trust in the system every time.
Decay is a system falling behind its products
Products change every week. A system that changes every quarter falls behind, and teams stop waiting for it. This is decay: the system is still there, but it no longer describes how the products are built.
The adoption numbers show it. In zeroheight's 2025 survey, 40% of systems were widely adopted and 10% fully adopted, so half were not (zeroheight Design Systems Report 2025). In research interviews, six of nine design-system leaders said keeping a system evolving with its products is hard. One described the challenge as "maintaining it, making sure it's still relevant even after a few years" (Lamine and Cheng, 2022).
Decay has its own bill. Every release that products cannot absorb becomes an upgrade someone postpones. Every postponed upgrade makes the next one more expensive.
Maintenance falls on very few people
The work of keeping a system current lands on a small team. In zeroheight's 2026 survey, 3 in 5 design-system teams did not have enough people to meet their goals (zeroheight Design Systems Report 2026, 147 respondents). The average team was three people at companies under 100 employees, four at 100 to 499 and nine at 500 or more (zeroheight Design Systems Report 2025).
A team of four cannot answer every request, review every pull request, check every Figma change and read every line an agent writes. So it prioritises, and the quiet work is the first to go. zeroheight's 2025 report describes the result: important elements such as accessibility and documentation are "left to rot".
Drift, decay and an overloaded team are not three problems. They are one problem seen from three sides.
Tools count the problem, operations fix it
Design teams already have good tools. Figma shows detached instances. Documentation platforms describe the system well. Linters catch raw values. Some teams run these tools very well, and they should keep doing so.
But a tool does not decide who owns a rule, who reviews a change, how long an exception may last or what happens when a deadline meets a standard. When five designers share a library with no agreed way of working, each makes a reasonable choice and the system comes apart. That is not a failure of the people. It is a missing structure.
This is why I argue for operations: owners with names, one review queue with service levels, exceptions that expire, rituals that are prepared from data, and a way to see the health of the system over time. Operations turn drift from something that happens to the team into something the team manages.
How Loom tackles each cost
We built Loom to run this work with a design team, in their own repository.
For drift, the audit reads the repository and scores eight areas with evidence, including raw values and re-implemented components (how the audit works). Agents check their work against the system before hand-off, so off-system interface is caught where it is written (agents and MCP). Exceptions are allowed, and each one lasts at most 90 days before it returns to its owner (governance).
For decay, breaking changes are decided by a contract diff, deprecations name a replacement and a date, and the audit reports every remaining use. Needs that people and agents could not find are logged with request counts, so the owner sees what the system is missing.
For maintenance load, every request waits in one review queue with an owner, a due date and a service level counted in working days (operations). Agents receive the rules through an MCP server and an AGENTS.md pack, so routine questions are answered by the system instead of by the team.
Some of this is new, and I want to be clear about how new. Health over time, the radar that turns repeated needs into drafts, and codemods with migration pull requests now run on our sample systems, but none of them has run in a client's repository yet. The Academy that keeps people current when the system changes is coming next. Loom also does not quote savings: it will cite numbers only from its own measured client work, and it has none yet. What we offer instead is a calculator where you enter your own numbers, see the formula and get a range, not a promise.
Budget for keeping, not only for building
If you lead a design-system team, measure drift and decay once, now, so you have a baseline before anyone asks. If you fund one, ask what it costs to keep the system current, and fund that as a service with owners and service levels. The build is the smaller part of the cost.
A design system pays back only while it is kept. Fund the keeping, or pay for the drift.
Continue the conversation
These sources, all cited above, give the evidence and its limits.
Measuring the value of design systems by Figma
The controlled study behind the most quoted figure, with its own caveat that it is a maximum.
Yes, design systems do improve developer efficiency and design consistency by Sparkbox
A small, transparent study of one form built with and without IBM's Carbon.
One formula to rule them all: the ROI of a design system by Maximilian Speicher with Guido Baena Wehrmann
A published ROI model with its formula and assumptions in full.
Design Systems Report 2025 by zeroheight
Survey data on adoption, team size and resourcing.
Understanding and supporting the design systems practice by Yassine Lamine and Jinghui Cheng
Research interviews with design-system leaders on why keeping a system current is hard.