01
Cash & Return
Shorter time-to-market and lower cost. Higher ROI. Faster cash generation from what the system doesn't make you build.
Component imports are a bad proxy. Code coverage is a better one. And behind both are five dimensions of business impact that any horizontal team should be able to name.
If you ask most design system teams how they measure impact, you'll get some version of the same answer: component adoption. How many teams are using the library? How many components are being imported? What's our reach?
That number isn't nothing. But it isn't impact, either.
A team can import a Button into a hundred features and produce a hundred wildly inconsistent experiences on top of it. Another team can import zero of your components and still ship on-brand, accessible, high-quality UI — they just did it themselves, the hard way. Either way, "components imported" tells you almost nothing about what the system is actually doing.
Component imports as a reflection of adoption is a limited measurement of impact. So what's the alternative?
If we look at the amount of system assets used in a given feature — not just whether the system was touched — we can start to establish co-occurrence with real measurements of impact. You can express that as raw counts (number of system components imported) or as a percentage of all components that came from the system.
But the clearest relationship between system use and impact is a specific version of usage: code coverage.
I use the phrase to mean four things at once:
These are four facets of the same measurement. One from the system's perspective (how much did we contribute?), one from the feature team's perspective (how much did we not have to build?), and one from the user's perspective (how much of what they're seeing came from the system?).
That last framing matters. It reframes the design system from a library people opt into to a layer that shapes the experience — whether or not anyone's paying attention.
Code coverage tells you how much of the product the system is shaping. It doesn't yet tell you what that shaping is worth.
To go from "how much" to "how much is that worth," you have to connect coverage to something the business already cares about. That's where a framework helps.
I use one adapted from Susan Colantuono's No Ceiling, No Walls, which breaks business impact into five dimensions. Every horizontal team's investment can be defended in the language of at least one of these — and usually several.
Any horizontal team should be able to point at at least one of these when asked "so why does what you do matter?"
Framework adapted from No Ceiling, No Walls · Susan L. ColantuonoShorter time-to-market and lower cost. Higher ROI. Faster cash generation from what the system doesn't make you build.
Expanding offerings via development or acquisition. New products reuse the system instead of rebuilding.
Ability to execute. Prototype quality. Experiment velocity. Integration quality on new products.
Retention, expansion, acquisition. Feature success, customer sentiment, quality audits — the trust of a consistent surface.
Accessibility, security, privacy, performance, localization. Solved once at the system layer, met everywhere else by default.
The interesting move is to associate system usage — measured by code coverage — with a specific dimension of business impact. Not "we shipped a lot," but "we shipped a lot, and here's the impact you can now defend."
Here's the mapping I work from:
| Dimension | Metrics you can associate with system usage |
|---|---|
| Cash & Return | Anecdotal evidence of project feasibility enabled by the system. |
| Growth | Time to market. Feature velocity across teams. |
| Capability | Experiment quality. Prototype efficiency. New product integration quality. |
| Customers | Feature success measures. Customer sentiment. Quality audits. |
| Compliance | Bug counts. Audits. Performance measures. Anecdotal evidence from the sales process. |
Notice how many of these are qualitative or anecdotal. That's fine — a story with a coverage number attached is more persuasive than a coverage number alone. The point isn't to be able to publish a p-value. The point is to be able to speak the business's language back to them, with real examples.
Perceived impact still tells a story. When you ask engineers "how much time did the system save you on this feature?" — even their guess is data. And just as importantly, collecting this information trains your users to start thinking in these terms, which quietly creates a culture shift toward measuring impact at all.
You don't need a full metrics practice to start measuring. You need one question, asked consistently.
If a design system team can only defend itself with "we shipped these components," it will always be seen as a cost center. If it can defend itself with "we increased feature velocity by X while reducing accessibility remediation by Y — here's the code coverage that made it possible" — it becomes an investment.
The measurement work is the leadership work. Do it early. Do it consistently. Be honest about the parts that are still anecdotal. And treat every conversation about "what do you actually do?" as a chance to reset the narrative from craft to capability.