A design system business case & business benefits — the ultimate guide

Published in

UX Collective

33 min readMay 24, 2020

An illustration of designers holding design props. — Design vector created by stories — www.freepik.com

In-house built design systems have become an essential enabler for product teams. [32,37] They bring a large number of benefits from efficiency to consistency to improved collaboration. Consequently, they drive better business results as they allow teams to spend more time solving real user problems and get solutions faster to the market.

Over the past five years, I’ve helped initiate and I’ve also contributed to several design systems. I’ve experienced the benefits of aligned teams, reusable components and rapid high-fidelity prototyping, which among other improvements, allowed us to quickly launch experiments, measure their impact, and deliver value faster.

However, building and maintaining a design system is a big task. And starting can get even more challenging if you don’t yet have the buy-in from fellow design, engineering and business folk. If that’s your case, you’ve probably heard at least some of these:

We need to develop and ship. This is not a priority.
It’s going to slow us down.
It’s going to be too expensive. We can’t afford this right now, maybe in the future.
You don’t have components already?
Design system what?

As someone interested in or working on a design system, you probably don’t need to be convinced about design systems’ benefits, however, getting others onboard requires having the right arguments. I went through lots of books and articles so that you don’t have to. In this article, I’ll focus primarily on how to sell a design system idea to your business colleagues but we touch upon other audiences as well. Let’s dive in.

Contents ✍️

The importance of a business case
Understand the approval process in your company
How to structure a design system business case
1. Determine the strategic need or opportunity
2. Lay out your project approach and goals
3. Describe the business benefits of creating a design system
4. Estimate the project costs
5. Outline risks
6. Estimate ROI
Conclusion
Acknowledgements
References

The importance of a business case

Why is it not always easy to get the budget for a design system, when having one just makes sense? While working on our immediate projects, we often don’t see that each initiative is competing for limited company resources. The better we can show how our activities tie to the company business goals, the better the chance of getting our projects going. [12]

If you happen to be a UX professional, it should come naturally to you to first understand your customers’ needs (in this case the decision-makers’). Put yourself in their shoes, find out what is important to them and how they are evaluated. As Sheen and Gallo write in [26], with a business case you are “enabling your leadership team to make a wise investment decision. A business case addresses the question: What happens if we take this course of action?”

Creating a solid business case is a lot of work but you’ll see that if you get the final ‘yes’, it will be worth it. Before we get there, though, you’ll need to find out how your company approves projects.

Understand the approval process in your company

An illustration of two men shaking hands. — Business vector created by stories — www.freepik.com

Without knowing when and where to go, what to focus on, and what level of detail is needed, you might be doing a lot of great work and still get nowhere. Therefore, before you even start building your case for a design system, understand how projects and initiatives are approved in your company. Find out the following:

1. General approach to project funding

How a budget for an initiative like a design system is dealt with?

Is there a centralised budget? Who owns it?
Do departments who benefit from a project co-finance it?
Do you need to have a ‘sponsor’ who is already willing to fund your initiative? [12]

Are projects budgeted for a certain period of time, all at once, in phases? Can they stand alone or do they need to be tied to a larger portfolio?

2. Funding cycles & timing

Understand when new projects can apply for funding — is it at a certain point in time (e.g. calendar or fiscal year) or is it continuous (on an ad hoc basis)?

Is there then a one-off meeting you need to set up, a regular committee, or a formal process you need to follow? When is it happening? Seems trivial but can make a big difference knowing whether the committee you need to go to is held fortnightly, quarterly, or once a year.

Are there other business cases evaluated at the same time? What are they? Is there something different, specific about yours that could catch the evaluators’ attention?

Take into account recent events which may have had an impact on your business — these could play a big role in the decision-making process and priorities.

3. Evaluation criteria & level of detail

Is your company currently trying to expand, save costs or is it in the middle of a transformation journey? Knowing this will help you present your design system effort from the right angle.

Which criteria are being considered by the decision-makers to determine which projects shall be approved? These normally reflect your business priorities and goals — think KPIs, OKRs, etc. Already start thinking about how your design system could positively affect those. There might be a direct or indirect impact — consider both.

Find out what level of detail your decision-makers expect.

4. Decision-makers

Know your audience. Know who ultimately decides (e.g. one decision-maker, committee, multiple stakeholders). Bear in mind that there might be different processes depending on how much you ask for.

Who do the decision-makers take advice from? Is there a dominant person or department which is key to get on your side? Is there something they respond well to? Or something they hate to see in a business proposal? Are they revenue-oriented, is customer satisfaction a driver? What do they care about the most? What do they ask about when reviewing proposals?

Find a design system advocate who has a say or can influence decision-making. Your chances are highest with a person whose division, department, product, or service will benefit from a design system.

Note: Here it’s also important to consider who usually presents in such meetings as it might not be you. It could be your CTO, CDO, CPO or another manager. Also, the design system could be a part of a larger budget request. This person will need to know the business case story inside out and they need to be bought in to be able to answer questions and to be persuasive.

5. Templates

Your company may have a specific template you need to use when presenting a business case or if you want to decide on a budget. Get it. If you don’t use the standardised form your decision-makers require, you might be disqualifying yourself already in the first round. Also, ask colleagues who have successfully applied to show you how they filled in the template. Rejected cases will also be a good resource for learning.

If the above is not known to you yet, approach it as a research study, it’s gonna be more fun. Interview colleagues who know more than you and who got projects in your area approved before. What did they do right? What didn’t work well? What would they focus on if they were you?

Once you have a good grasp of how your company’s pennies get split, it’s time to start working on the business case itself.

How to structure a design system business case

Raymond Sheen, the president of Product and Process Innovation, Inc, underlines that the winning business cases tell “memorable and compelling stories”. He recommends approaching business cases as an adventure novel, in which your company overcomes a problem or seizes a new opportunity by implementing your idea. [25] You want to find the just-right mix of storytelling and facts which is appropriate for your audience.

The structure you choose may need to be adapted based on your specific approval process. Below, I’ll outline a general business case structure found in business, design system and UX related literature. [7,12,17,25,26]

In general, your stakeholders will want to see ROI (Return On Investment) and how your project is helping the strategic goals. They will want to see the specific costs and benefits, as well as risks and opportunities. The rest of the article tackles the main topics one by one:

Determine the strategic need or opportunity
Lay out your project approach and goals
Describe the business benefits of creating a design system
Estimate the project costs
Outline risks
Estimate ROI (includes design system stats)

💡 Consider framing the case in the wider context of Design thinking business benefits

A design system on its own won’t fix bad design and bad design practice. However, if it is a part of a transformation towards customer-centricity, it becomes one of the cornerstones of your design process, helping teams to collaborate and deliver better quality products to users faster. So if your company is not too far on the UX maturity scale [8,9], it might be helpful to tie your design system business case to user-centred and design thinking benefits overall.

In her talk at the Design Systems London 2019 conference [38], Anja Klüver, suggested framing the case for a design system in the wider context of Design thinking. Design thinking practices have been proven to drive amazing business outcomes if done properly. For example, IBM’s Design Thinking Practice has brought 301% ROI, cost-savings of $20.6 million, 2x faster time-to-market, 75% reduced design time, and 33% reduced development time. [3] Consider using those numbers to get your stakeholders’ attention.

👉 More design-system-specific figures in chapter 6. Estimate ROI.

1. Determine the strategic need or opportunity

An illustration of a young woman and a question mark. — People vector created by stories — www.freepik.com

There must be a business need. Otherwise, what are you solving with the design system and why should anyone pay for it?

You might already have some problem candidates — something probably isn’t going as well as it could. Make sure to look into each problem properly and make it crystal clear. If you cannot articulate it well, you can’t expect your audience to buy into it. Ground the problem or the opportunity in research — ask your stakeholders and peers from relevant disciplines what they are struggling with; observe; create an experience map for both designers and developers; gather relevant data — find the root cause and document everything. Ask them for help if needed, they might even become your supporters which can be very helpful (especially if their departments are later part of the approval process).

Unless your company is a start-up, chances are that you have to deal with legacy systems and processes, technical debt [39], UX debt [10,40], etc. All these are slowing you down in an environment that screams: ‘Faster!’. Businesses, therefore, often find themselves having to decide between investing in foundational work (e.g. a design system) vs pursuing functional work (launching features and products), long-term benefits vs immediate goals. [28] If the foundational work is weak and your company is growing or has to adapt quickly to changing needs, the lack of systematic design thinking and doing will manifest in the following areas:

Time to market too slow → Missed business opportunities

The digital economy is growing fast, we are moving more and more from digital products to services which require constant development. If you are not evolving, you can be sure that someone else is. As if this wasn’t enough, it’s not only the direct competition we need to constantly monitor, customers are now comparing digital products beyond traditional sectors (liquid expectations [24]).

Keeping such pace without introducing a design and development debt [10,39,40] is impossible unless you have a systematic approach to building digital products and services (and even then it’s a challenge).

Missed design & development deadlines → Projects over budget or never delivered

Design-development handoffs, messy structures both in design files and in the codebase, non-existent onboarding materials, a non-existent glossary of terms leading to ambiguity, designs not implemented to designers’ wishes on one side and custom styling of every component which is very time-demanding to maintain on the other [14].

You may be also seeing duplicated efforts across your teams, effectively making a single component x-times more expensive for the company.

Scattered brand image → Perceived quality, trust and your brand equity compromised

Design teams are being increasingly invested in. Our teams grow (which is amazing). If you’re working on an international product, the odds are that your team is also distributed across cities, countries or even continents. With growth, however, it becomes much harder to keep everyone on the same page when it comes to following the same design language. As a result, parts of the same product or a suite of products may start to look and feel as from different brands, quality may vary broadly.

💡Interface inventories are a powerful tool to showcase inconsistencies, redundancies and, therefore, show how time and money might be being wasted in the current way of working. They also show how your brand identity is being compromised. If you have a large digital product or a suite of products to maintain, some parts of them might be on-brand while others are outdated. What message do you send to your customers?

As Alla Kholmatova puts it in her book Design Systems: “Intuition is not always reliable or scalable.” [14]

Poor user experience → Low user satisfaction, product adoption & loyalty

More complex design problems. Our products, services, and, therefore, the interfaces through which our users access them, have become much more complex. Product teams are often only looking into small pieces of the interface or the customer journey at the time. Without a systematic approach stemming from a shared purpose and vision, there is a risk of losing the sight of the bigger picture leading to fragmented customer experience. [14,30]

Arbitrary design decisions. When there are no standards and only vague guidelines, everyone’s opinion counts. If designers don’t have clear argumentation stemming from a higher purpose, principles and guidelines, HiPPOs, decision-makers and many other actors in the process (including the design team) can easily require design changes based on their personal taste. This can lead to unsystematic design decisions which may break the user experience, predictability of the product and user trust in the system.

Usability issues & Design debt. Bad design decisions (see above) and unsystematic design process often lead to usability issues, incoherent visual language and poor interactions — UX and design debt. Your team has launched a new feature out to the world but it has a lot of issues, which you’ll need to fix. As we’ll see later, fixing such issues post-launch is dramatically more expensive + it’s hurting your brand perception. In other words, you’ve taken a loan but if you want your customers to be happy with your product, you’ll need to pay it off and there’s going to be a high interest attached to it. [39]

Strangled innovation, low product adoption & loyalty → Missed business opportunities & small market share

A new product/service/feature adoption is dependent on multiple factors — from marketing to customer service to product design, etc. The key prerequisite for any product success, however, is solving the right user issue (remember the classic Norman’s double diamond phases → #1 Finding the right problem, #2 Finding the right solution [19]). So many companies put a lot of effort and money into finding ‘the right solution’ to a problem which doesn’t exist or is not worth solving. Simply put, they skip the ‘finding the right problem’ phase.

That’s not to say that finding the right solution and crafting it well is less important. Your product can be failing exactly because of this — you’ve found the user need but you are not offering the right solution.

If your designers’ and developers’ time is spent focusing on repeatedly reinventing your system building blocks for every product or service, you are doing a disservice to both your current and future products. Instead of understanding user needs properly, designing, coding and testing to mitigate the risks of launching a product which no one wants and/or is super buggy, your team is stuck working on low impact, low value-adding activities.

Weak performance & bugs → Low trust, broken credibility, abandonment

You can have the best visual and interaction design in the world but if your system’s performance is slow and your users are getting a lot of errors, it doesn’t matter. Even a second of delay can cost your business millions. [34,41] And it’s not only the immediate sale you’ve lost, it might also be all the future ones since the customer is now with your competitor who provides a faster and more reliable service. Errors also break the trust between the user and your service and can lead customers to question your credibility and the quality of all your products (think of the last time you were buying an airplane ticket and the site threw an error; did that make the airline feel safer?)

In large-scale digital services, you need a degree of standardisation which makes it possible to put the whole system together while keeping it coherent and fast. Without clear guidelines and reusable components (UI building blocks) which are carefully crafted both design and code-wise, you are playing a dangerous game as at some point it will become very difficult to maintain and sustain. A bloated code base slows down your service and as you see below, that can have a dramatic impact on whether people abandon your product.

Page load 1–3 seconds, the probability of bounce increases 32%; page load 1–10 seconds, probability of bound increases 123%. — *Source:* *New Industry benchmarks for mobile page speed* *[42]*

Once you’ve determined the key strategic business need and/or opportunity (The Why), it’s time to look at your project approach (The How).

2. Lay out your project approach and goals

An illustration of a women writing in between gear wheels. — Idea vector created by stories — www.freepik.com

Your decision-makers will want to see that you have considered multiple scenarios of how to deliver on the business need and that you have a high-level understanding of how your proposal could be turned into reality.

Show alternative solutions

This is a tough one. You’ll need to show alternative solutions (ideally two to three) to meet the business need. Show which is most efficient, cost-effective, most appropriate for the organisation’s culture and capabilities. [26]

You can be convinced that a full-fleshed design system is the only good solution and that might as well be true. However, your decision-makers will want to see that you’ve thought of alternatives too and analysed them properly. It may be discouraging but let’s keep our empathetic hat on — if they don’t know much about design systems, how do they know that a design system is the best option to satisfy the business need? What could be the alternative? A design system is a serious investment and they are responsible for mitigating risks for the company.

💡Tips:

An alternative might be a static style guide, or whatever is the current status you are not happy with (that is is the do-nothing option [26]). Adam Zielonko explains nicely the difference between the style guide-based and design system-based products in the below charts.

Style guide-based products vs Design system-based products. Design system-based products evolve over time. — Adam Zielonko’s explanation of the difference between a static style guide and a design system. [33]

Show that having a design system has become a de facto industry standard. Show the numbers.
Give yourself several budget estimates to play with — what could you do if you had this much, that much? What would be the pros and cons? If that’s too abstract, think about specific design and dev roles and — how many people you might need?
Don’t forget to tie your alternatives back to the original strategic need of opportunity.

Show a high-level project plan

You need to show how your idea is going to be implemented, a very high-level project plan. You don’t need to have everything figured out, of course, but you shall be clear in the direction.

What would implementing a design system mean? What would the new team or allocation of the existing team members look like?
What would other departments need to do? (e.g. an IT department will need to implement and secure a new tool, etc.)
Are there any prerequisites that need to be done even before you start? By whom?
How long might this take? Is there a high-level timeline to follow? What are your milestones?
How would you propose rolling out? In phases? Big bang? Why? What should happen then? (E.g. training; including the design system in the onboarding process; etc.)
On the other hand, what processes and tools might be eliminated?

Set measurable goals

One thing is clear — if you can’t measure it, you can’t improve it [attributed to Peter Drucker]. In our case — if you can’t measure it, you won’t be able to continuously show the value of your design system. To get ongoing funding, you need to show that a design system will help you reach business goals faster and at a lower cost.

Depending on what is important to your stakeholders and the design & dev community, select your objectives and key metrics. Start with the current state (benchmark) and then continuously measure across the same metrics to monitor the change. As the design system matures and gets more adopted in your products and teams, you should be seeing clear benefits in your ROI. Once that happens, don’t forget to communicate that with your peers and management.

Use a goal-setting framework that your business expects. As Objectives and Key Results (OKRs) have become a widely adopted way to set the direction and track progress, below are a few of my suggestions and also some examples found in the literature [5,30].

Objectives could include:

Accessibility is built into everything we do
Maximised adoption by products within a certain timeframe
Reduced development times and increased time to market
Reduced design time and increased time to market
Reduced technical debt and bugs
Reduced UX debt
Increased collaboration among teams
Increased speed of design and development handoff
Speed up and improve the quality of onboarding
Integrate the design system into our flagship products
Get a budget to fund a stable design system team

Key results could include:

Employee satisfaction score with the current way of working vs design system
Team happiness scores
Time to launch new product or design, develop and ship a new feature
Reported bugs
Reduced technical debt
Rework — how many things had to be reworked post-launch?
Brand equity
Brand perception
Design system adoption rate
Funding of the design system (e.g. capacity, allocation)
Productivity (e.g. sprint velocity)
Measure of user satisfaction and usability
NPS score
Product/Service adoption rate
Customer loyalty

As you’ve now introduced the recommended solution, the alternatives, the high-level plan, and your goals. Now, it’s time to show more detail.

3. Describe the business benefits of creating a design system

An illustration of a woman and devices with various screen sizes — illustrating responsivity. — Illustration vector created by stories — www.freepik.com

The benefits should not be vague (like increasing customer satisfaction) — get specific. The more you can showcase concrete benefits and quantify them, the better. However, getting to specific numbers might be a challenge. Directly or indirectly, a design system will change certain behaviours — ”those are the business consequences you can measure” [26].

Round numbers are okay at this stage. Nobody can expect you to have precise numbers, it may even be suspicious. Those numbers will more likely be educated guesses. If you truly cannot assign a price tag to a cost or an income estimate to a benefit, still mention it if it’s relevant.

Note: If you still need to be proving the value of UX in general, it’s better to be conservative with your benefit calculations and rather over-deliver than over-promise. [12]

Money-wise, there are two ways you can help your business:

Increase revenue
Cut costs (make savings).

Product costs — these are the direct expenses you need spend to create the product itself; this is where a design system can shine as it can make the product creation much more efficient
Overhead costs — these are all the expenses surrounding the product (e.g. marketing, accounting and legal fees, customer service, maintenance); a design system can free up your team to spend more time thinking about the bigger picture, crafting better user and customer journeys which may ultimately need less maintenance, less customer service and if people love it, less advertisement

With design systems, we are primarily looking at the cost-saving benefits. However, if the system helps you get to market faster or gives your team time to think more about the experience you’re designing as mentioned before, you might be also contributing to increasing the revenue.

I went through quite a few design systems books, talks, and articles [1,2,7,11,14–16,18,20,22,23,27–30,33,35,36,38,43–46], then created a mind map of the benefits the authors talked about and added extra ones from my own experience.

My goal was to create a comprehensive list that you can then go through and pick the relevant items for your specific context, challenges, and business goals. Many of the benefits below would fit in multiple categories, so please ‘mix and match’ 🌟

A gif in which a cook selects various ingredients.

Faster time to market → Seize the opportunity

Design systems lead to increased productivity which allows you to get your idea to market faster and in higher quality.