Design system ROI: how to calculate it and make the case

The most-cited number in design system business cases, 34% faster, comes from a 2019 Figma experiment whose author expected it to be the maximum time saving a team would see in practice. Most slide decks leave that part out, and leadership usually notices.

Design system ROI is the value of the design and engineering time a system saves, minus what it costs to build or buy and then maintain, divided by that cost. You calculate it from your own team's hours and rates, and use published studies only to sanity-check the savings rate you assume.

What does the published research actually show?

Two controlled studies get quoted most, and both are smaller than their reputations.

Figma (2019). Designers completed two equal-length tasks in a bank account aggregator app, one with a relevant design system and one with old design files for reference. Each designer was their own control, task order alternated, and participants chose their own stopping point. With the design system, they finished 34% faster, and several said they felt more confident in the result. The post doesn't report a sample size, and its author notes the system was directly applicable and up to date, which is why 34% reads as a maximum.

The post then projects onto Figma's own team: seven designers with 20 focused hours a week each, 140 hours, become 212 hours of design work, "equivalent to adding another 3.5 designers." That arithmetic divides 140 by 0.66, so it assumes every task gets the full saving.

Sparkbox (2021). Eight developers built a contact form from scratch, then built it again with Carbon, a system none had used. The median time fell from 4.2 hours to 2 hours, which Sparkbox reported as 47% faster. The two best submissions for visual consistency used the design system, while two scratch builds beat it on accessibility. Sparkbox calls it a small study of a handful of excellent developers.

The 2026 roundup on Figma's blog summarizes research from the Design Executive Council and includes self-reported figures, such as a Grammarly internal survey finding the system saved design and development teams 25% of their work week. Treat those as stories, not benchmarks.

Published studies set the ceiling for your savings rate, not the number you put in the model.

How do you calculate design system ROI?

Use four inputs you can defend: UI hours, a savings rate, a loaded hourly cost, and the system's cost.

1. Annual UI hours = people doing UI work × focused UI hours per week × working weeks.
2. Annual savings = annual UI hours × savings rate × loaded hourly cost.
3. Total cost = build or license cost + adaptation + ongoing maintenance.
4. ROI = (savings over the period − total cost over the period) ÷ total cost.

Here is a worked example. Every number below is an illustrative assumption, not data: 8 designers at 20 focused hours a week (Figma's estimate for its own team), 20 engineers at 15 UI hours a week, 46 working weeks, a $100 loaded hourly cost, and a 15% savings rate, well under both studies.

That's 21,160 UI hours a year. At 15%, the system saves 3,174 hours, worth $317,400 a year. Published studies set the ceiling for your savings rate, not the number you put in the model.

Build vs buy: where the math tips

Same team, same savings rate, two ways to get the system. The assumptions: building takes a three-person team for year one, then two people to maintain it, with savings starting in month seven. Buying takes two people for four weeks to retheme and adapt, half a person ongoing, and savings start in month two.

The point isn't that building is wrong. Savings scale with headcount, and a dedicated team's cost doesn't shrink for a smaller one. Under these assumptions, the build breaks even within three years only with a UI team about 60% larger. Building also wins when your product needs patterns no bought system covers. Be honest the other way too: a bought system that fits fewer of your screens earns a lower rate, and at 10% the buy column falls to about 100% ROI.

How to present the case to leadership

Leadership doesn't buy a design system. It buys faster delivery, fewer UI defects, and lower accessibility risk.

1. Start with their metric. Lead with time to ship a feature or the count of inconsistent components from an audit, not with tokens.
2. Show a range. Present a conservative case and an expected case, with every assumption on one slide.
3. Cite studies with their limits. Saying the 34% figure was a ceiling buys more credibility than it costs.
4. Propose a pilot. One product area for one quarter, measuring adoption, time on a defined task, and UI defects before and after.
5. Ask for a dated decision. Agree now on the number that would justify scaling it.

Then report back against the pilot's metrics. A second, measured business case is far easier to approve than the first, because it uses your own numbers.

Where Pegasus fits

Pegasus changes the cost line of the formula rather than the savings rate, which stays yours to measure. As of October 2026, the Figma library costs $79 one-time, and the full system (Figma library, React code, Storybook, and a local MCP server, with unlimited team seats) costs $149 one-time. The license is perpetual, covers unlimited commercial projects including client work, and includes free updates, so there's no recurring license line.

The adaptation line is where most of the buy cost sits. One token source themes both the Figma variables and the React theme object, so retheming is a token change rather than a redesign, and the 14-Day Rebrand Guarantee refunds the purchase if you can't retheme Pegasus to your brand within two weeks. Pegasus Lite, a free subset of the components, lets you run a small pilot before any purchase.

FAQ

What is a good ROI for a design system?

There's no published benchmark worth anchoring to, because team size, coverage, and maintenance vary too much. A reasonable bar is a positive three-year ROI under conservative assumptions, such as a savings rate well below published study results. If the case only works at the 34% ceiling, it isn't ready, and leadership will find the weak assumption before you do.

Is the 34% faster statistic from Figma reliable?

It's a real, controlled result, but narrow. Designers did one screen task with a relevant, up-to-date design system and another with old files, and the post doesn't report how many took part. Its author expected 34% to be the maximum real-world saving. Use it as an upper bound for design time, not as a forecast for your team.

How do you measure design system ROI after launch?

Track the inputs of your model. Measure adoption from component usage in code and design analytics, time on a repeatable task before and after, UI defect counts, and the hours spent maintaining the system. Recalculate quarterly with real numbers in place of assumptions, and report the trend rather than a one-time figure.

Sources

• Measuring the value of design systems, Figma (2019)
• Yes, design systems do improve developer efficiency and design consistency, Sparkbox
• Yes, design systems do improve developer efficiency and design consistency, CSS-Tricks (2021)
• The new business case for design systems, Figma (2026)