Demonstrating a design system’s worth

A design system acts as a single source of truth, containing elements and standards that enable product building and design management at scale. Design systems focus on reducing redundancy, creating consistency, and communicating a shared visual and technologic language across a digital product. A well-built design system benefits the end user by providing an accessible, usable, and familiar experience.

Whether you’re convincing leadership to invest in a new design system or proving your system’s benefit over time, you need to be able to accurately and quantitatively communicate your system’s benefit to the company. This data helps in budget conversations, to increase headcount, and to continually communicate your system’s (and team’s) benefit. Sure, the customer benefits of consistency, accessibility, and brand recognition matter. But cynically, what the business cares about is the return on investment.

If you search for how to communicate design system value, most teams or leaders will share at a high-level their most important metric: time savings equating to monetary savings. As of now, time savings has become a standard way to prove design system value. There are a few quick (though imprecise and missing nuance) methods to measure time savings. Figma proposes to do a small user test of designers creating one design using a system and the other without a design system to see how much time is saved. There’s also pre-launch methods such as Smashing Magazine’s ROI formula to convince a business to make an initial investment.

Here, we’ll discuss two approaches I’ve seen used in the industry with notes on the gaps in each method.

A caveat to all of this — to get perfectly accurate time savings data, we’d need to create some sort of ‘big brother’ scenario where every designer and developer mouse stroke is recorded as they work. It might be possible, but it’s also not worth our time and effort. We should be investing our energy into our systems, making them more usable, accessible, and robust. So let’s explore a couple of reasonable ways to track and communicate value.

User-reported time savings converted into monetary savings

A common way to estimate time saved is by asking designers and developers how much time they save on average by using your design system. The average hourly salaries for designers and developers can then be used to figure out overall cost savings, giving you a quantitative number.

But there’s a downside. While you’re turning user reported time savings into a quantitative metric, it’s really a qualitative, subjective number, leaving it open to criticism. You’re relying on your users’ memory to estimate some sort of average number of hours per day/week/month. However, in lieu of having more exact data, users’ perceptions of time savings can equate to estimated design system value.

So how do we gather and calculate reported time savings? The first step is to conduct a survey. I recommend doing a design system user survey twice a year. Keep designer and developer responses separated. For smaller, fixed population sizes, you can use Qualtrics’s sample size calculator to figure out how many responses you need to be statistically significant. Using a confidence level of 90% with a 5% margin of error, in my experience you should be able to get enough responses to have an accurate sample size.

A standard way to ask about time savings is: “How much time, on average, do you save using {design system name}?” with response options of fixed percentages such as 0%, 10%, 20%, 30%, 40%, 50% and above. Asking for hourly or exact percentage savings is difficult and almost impossible from a user memory standpoint; they will be more comfortable and confident offering a percentage of average time savings.

Before doing the full calculation of cost savings, you need to gather a few numbers:

• Total number of designers and number of developers using your design system. “Designers” is generically used here to include writers, content strategists, visual designers, UX designers, etc.
• Working hours per month based on an individual person. Take into account the number of days in the month, any company holidays, and an average work week for employees (typically 40 hours in the US) to get a number representing the available working hours. You don’t need to worry about who all took time off; omitting it will make our final metric more conservative.
• Average hourly rates for designer and developer roles. You can work with someone in management, HR, or finance to get an average estimate to use. Check in once a year to make appropriate adjustments.
• Average time savings per role based on survey responses. For example, if you have as designer responses 10 for 10%, 23 for 20%, 5 for 40%, and 1 for 50% or more, your average time savings would be 21% (rounded to nearest whole number).

Calculate the cost savings per month as the average time savings multiplied by working hours multiplied by designers (or developers) supported multiplied by average hourly salary.

For example, 21/100 (average time savings percentage) x 168 (available working hours in January) x 6 (number of designers) x 50 (average hourly designer salary) = January cost savings for designers.

Your data tracking would look something like this for the first 2 quarters of the year:

You can go a step further and subtract the cost of your design system team (dedicated or part time) from the savings to get a hopefully positive view of your team paying for itself while still saving the company money.

Funding support

A completely different quantification of your design system comes in the form of funding from other teams. You’ll have more success with this approach when the business is doing well and there’s a positive economic environment. You have two routes: offering opt-in preferential status in exchange for funding, or directly requesting funding from teams with high design system usage. This approach is akin to treating your design system as an internal SASS product or how design teams at large companies allocate resources when funded by projects, other organizations, or leadership rather than design team’s budget.

One route is providing opt-in preferential status that includes providing hands-on support, dedicated office hours, and prioritized feature requests. Funding for extra support appeals to teams that heavily use the system and frequently need the expertise of the design system team. It comes with the tradeoff of having to commit extra time to whoever is giving you funding, but it is an incredibly tangible and straightforward proof of the design system team’s worth. This option is more likely to be successful at larger companies where there are multiple engineering leaders and a larger design team (or multiple design teams) or multiple business lines/organizations with distinct budgets.

The more direct route is to request funding from teams you know frequently use your design system. Consider trying first with leaders that you already have a strong relationship with, who would be more receptive to the idea. Combine it with your time savings calculation to formulate how much time you’d save the specific team to come up with an appropriate monetary request. This option can work at companies of various sizes, as long as at a certain level (maybe Director and above) there are distinct budgets that can be spent at the leader’s discretion.

Choosing which approach to focus on

I recommend starting with user reported time savings as a first effort. Calculating that data has minimal dependencies on anyone outside of your team, minus surveying your users.

However, the ability to have a team (or hopefully multiple teams) provide funding is an ultimate testament to the value that your design system and team brings to the company. No matter what size business you’re at, budgets often have an aim of frugality, only spending what’s necessary to produce a quality product. To have a team allocate budget to a design system demonstrates how much they value it.

Overall, no matter what you choose, you’ll likely get questions and critiques over the data. Leadership will continue to look for ways you can improve accuracy on proving your worth, just like you would for any product or feature you launch.

Something neither of these calculations consider is the nuance of how designers who use a system have more time to focus on actual customer challenges when they don’t have to think about building the core pieces of an experience. They may actually spend close to the same amount of time to finish a project, but the output is higher quality (more usable, accessible, successful) customer experiences. If I ever figure out how to quantitatively prove that nuance, I’ll be sharing it with everyone who’s willing to listen!

Experiment with what sort of data story compels your leadership, trying approaches you come up with yourself. The design system community will continue to iterate on this challenge to continue surviving.