Why a Design System Still Needs a Business Case

Design systems are now standard practice across the digital industry — companies like Amazon, Google, Airbnb, and Uber all rely on one. A substantial body of research supports their effectiveness in boosting productivity, reducing bugs, and improving product quality. Yet in practice, teams frequently find themselves having to justify the investment in a design system all over again, even when competitors have already adopted one.

For most product features, a simple competitive benchmark settles the argument: if everyone else is doing it, the reasoning goes, we can too. That logic rarely extends to design systems. The reason is that, unlike a discrete feature, a design system reads as an abstract investment — its payoff is deferred and indirect. Meanwhile, the upfront cost looks steep compared with the concrete features a team could ship in the same time, producing more immediate, visible value (along with more technical and design debt).

The burden of proof therefore falls on anyone proposing to build a design system. Based on our own repeated experience making this case, we have developed a formula for approximating the ROI of a design system using a minimal set of parameters. It complements the more strategic guidance that Ben Callahan has already offered on the topic.

Defining the Scope: What Counts as a Design System

A design system is a collection of reusable components governed by explicit standards, assembled together to build applications. Well-known examples include Google's Material Design, Salesforce's Lightning, and Shopify's Polaris. A true design system is not the same as a style guide or a component library. It extends across the whole organization — interaction design, visual design, engineering, brand, content — and it adds clear guidance on how and when to use its pieces, especially in combination.

"A design system [sometimes also called a 'design language'] is a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels." — Fessenden, 2021

The benefits are well documented: greater quality and consistency, less time wasted on repetitive work, a unified vocabulary across cross-functional teams, visual consistency across products and channels, faster onboarding, and a single source of truth for everyone involved.

Design systems can be run under different operating models, the two most common being centralized and federated. Our formula assumes the federated model, where designers and developers contribute to the system while remaining on their product teams.

We made this choice for two reasons. First, when management buy-in is the obstacle, proposing a dedicated centralized team only raises the bar higher. A federated approach lets people start building the system on the side and can later evolve into a centralized or hybrid model once its value has been proven. Second, a centralized design system often grows into a product of its own with its own management overhead. To keep the formula practical, we restrict the analysis to designers and developers — productivity gains in these roles are easy to benchmark, and even this limited scope produces a compelling business case.

Building the Case for a Design System

A design system is an investment with a payoff curve that takes time to materialize. The formula that follows calculates ROI by comparing what you spend on ramp-up and maintenance against what you gain in productivity over a five-year window.

$$ cost = \max(\frac{240}{X},6) \times X\% + \min(60 - \frac{240}{X}, 54) \times Y\% $$ $$ gain = \max(\frac{120}{X},3) \times \frac{Z\%}{2} + \min(60 - \frac{240}{X}, 54) \times Z\% $$ $$ ROI = \frac{gain - cost}{cost} \times 100 $$

This model is built on the assumption of a “Design System Efficiency Curve”: productivity initially dips while you build the system, then rises to a break-even point, and finally exceeds the original baseline once the system is mature.

A diagram with time on the x-axis and productivity on the y-axis. A horizontal line at ca. 50% productivity denotes the constant base state without a design system. The curve for “with a design system” first lies under that line, then crosses it and is well above that line in the long run.
The ‘Design System Efficiency Curve.’ Taken from Callahan (2021). (Large preview)

Key Assumptions

To make the formula tractable, several conservative assumptions were set, based on discussion within a design and engineering task force:

  • A design system is effective for five years (60 months) before a major revamp is needed.
  • Investing 20% of team time takes 12 months to get a design system running. The ramp-up scales linearly with the investment: 240 person-months of total effort.
  • The ramp-up takes at least 6 months, no matter the investment. This is where the constants 6 and 54 come from.
  • The first half of the ramp-up yields no gains; the second half yields 50% of the steady-state gains.
  • After the ramp-up, the system provides full productivity gains for the remaining months.

The Parameters

Three parameters drive the formula:

$$ cost = \max(\frac{240}{{\color{Fuchsia}X}},6) \times {\color{Fuchsia}X}\% + \min(60 - \frac{240}{{\color{Fuchsia}X}}, 54) \times {\color{orange}Y}\% $$ $$ gain = \max(\frac{120}{{\color{Fuchsia}X}},3) \times \frac{{\color{Bittersweet}Z}\%}{2} + \min(60 - \frac{240}{{\color{Fuchsia}X}}, 54) \times {\color{Bittersweet}Z}\% $$

X is the percentage of time spent building the design system during ramp-up. If X=20, ramp-up takes 240/20=12 months. Note that for X<4.62, the ramp-up would stretch beyond five years, and the formula breaks down.

Y is the percentage of time spent on maintenance after the ramp-up. It can be anything; in practice, Y=0.5X was used.

Z is the hard part: the percentage of time saved thanks to the design system. Since future efficiency is impossible to measure in advance, the most defensible approach is to pull from base rates.

Aggregating reported figures from existing studies — Klüver (2019), Loomer (2016), Ray (2018), Slack (2019), and Sparkbox — gives:

  • Design teams: Z=38 (average of 50%, 31%, and 34% efficiency gains).
  • Development teams: Z=31 (average of 25%, 20%, and 47% efficiency gains).

Worked Examples

Design Team ROI

Consider Acme, Inc., with 5 designers. They commit X=30% time to the ramp-up and Y=10% time to ongoing maintenance, and they take Z=38 from the base rate data.

On the cost side, a 30% investment means a ramp-up of 240/30=8 months. That works out to 8×30%=2.4 months of effort. The remaining 52 months at 10% maintenance adds another 5.2 months, for a total of 7.6 months.

$$ cost = \max(\frac{240}{30},6) \times 30\% + \min(60 - \frac{240}{30}, 54) \times 10\% \Leftrightarrow $$ $$ cost = 8 \times 30\% + 52 \times 10\% = 2.4 + 5.2 = 7.6 $$

For gains, the first 4 months of the ramp-up yield nothing, and the next 4 months yield half the full gain. The remaining 52 months produce the complete benefit:

$$ gain = \max(\frac{120}{30},3) \times \frac{38\%}{2} + \min(60 - \frac{240}{30}, 54) \times 38\% \Leftrightarrow $$ $$ gain = 4 \times 19\% + 52 \times 38\% = 0.76 + 19.76 = 20.52 $$

So the design team invests 7.6 months and saves 20.52 months, producing an ROI of (20.52-7.6)/7.6=170%. At $5,000 per designer per month, that is $190,000 spent to save $513,000.

Development Team ROI

The cost side is identical for developers: 7.6 effective months spent on the system. The only change is the efficiency parameter, with Z=31.

$$ gain = \max(\frac{120}{30},3) \times \frac{31\%}{2} + \min(60 - \frac{240}{30}, 54) \times 31\% \Leftrightarrow $$ $$ gain = 4 \times 15.5\% + 52 \times 31\% = 0.62 + 16.12 = 16.74 $$

With 10 developers costing $6,000 monthly each, the system costs $456,000 and delivers savings of $1,004,400, for an ROI of (16.74-7.6)/7.6=120%.

Combined Results

  • Design: $190,000 cost, $513,000 gain, ROI = 170%.
  • Development: $456,000 cost, $1,004,400 gain, ROI = 120%.
  • Total: $646,000 cost, $1,517,400 gain, with net gains of $871,400 and ROI = 135%.
A bar chart made of stacks of dollar bills illustrating $646,000 in costs, $1,517,400 in gains, and $871,400 in net gains. Next to that, we reiterate the ROI formula and indicate 135% ROI.
Overall costs, gains, net gains, and ROI from our Acme, Inc. example. (Large preview)

For a final presentation, it is reasonable to round those numbers and show uncertainty bounds derived from parameter sensitivity. A five-year estimate of “135% ROI and $900,000 (±225,000) net gains” is within ±25% of the possible variance in the inputs.

What the Formula Doesn’t Cover

To keep the model practical, we deliberately restricted it to efficiency gains for designers and developers working in a federated team model. That leaves several real sources of value out of the equation, including onboarding speed, consistency and user trust, and improvements to accessibility and usability. Those benefits go beyond raw productivity (Callahan, 2021) and would push the actual return higher than our estimate suggests.

We also excluded productivity increases for product managers, QA engineers, and user researchers, who typically benefit from a design system as well. The choice was intentional: a formula with three parameters is easier to explain and defend in a business meeting, and benchmarks for estimating Z in design and development are widely available. The trade-off is that the ROI figure you get from the formula is conservative. In practice, the true return on a design system is almost certainly larger.

A Practical Closing Argument

Despite the simplifications and underlying assumptions, the case for a design system is strong. The formula we’ve outlined should be enough to build a credible business case, at least for contexts similar to the one we work in. If your situation differs, the parameters can be adjusted to match your own data. When there’s still doubt, the most convincing next step is a small-scale design system MVP and a controlled experiment to measure the effect directly. Our hope is that this formula helps you get that pilot approved.

Acknowledgments

Thanks to Ben Callahan and Martin Schmitz for reviewing early drafts and offering invaluable feedback, and to all members of the BestSecret Design System Task Force.

References

Smashing Editorial