How to build the business case for a design system correctly

And actually, it’s obvious why: it saves time, ensures consistency, and brings structure to design and code. Your product or dev team would benefit directly from it.

‍
But: the decision is made by others.‍

‍
And this is exactly where it gets tricky.‍

‍
A sentence like “We need a design system” is rarely going to cut it.

‍
Because the question decision-makers ask is a different one:‍

‍
"What does it bring to the company — as in, hard numbers?"

‍
This is where this article comes in.‍

‍
It shows you how to build the business case for a design system in a way that it is understood and accepted.‍

‍
You’ll learn:‍

‍

• Which arguments work at the decision-maker level

• How to counter typical objections

• Which numbers you should prepare

‍
If you’re just getting started with the topic and want to learn more about the structure, components, or use cases of a design system: Here’s the beginner’s guide. There, we also discuss when to consider which elements of a design system.

Since not all design systems are created equal: What is this about?

Design systems come in all shapes and sizes: from small UI kits in Figma to comprehensive sets of rules that often include code snippets in various programming languages and are published publicly on a website – as is the case with Porsche.

‍
This “comprehensive” version ensures that visual guidelines are clear even for subcontractors or various agencies working with Porsche. After all, brand consistency is extremely important for a well-established image like Porsche’s.

‍

For most SMEs, the design system typically includes a UI kit or a component library in Figma. Strictly speaking, that’s not a (complete) design system, but it’s still often referred to as one.

‍

For SMEs, the goal is less about aligning external partners and more about making internal design and development processes more efficient and consistent by defining reusable design components.

‍

No matter how big you envision your design system to be:

‍
This article provides the key arguments for your business case.

Why Design Systems Are a Business Topic

Many decision-makers see design systems as purely a UI topic.

‍

Something that happens between colors, buttons, and components in Figma.

‍
What often gets overlooked: structure also brings efficiency, scalability, and better collaboration across the entire product team.

‍
A design system is, at most, a design project at first glance—because in reality, it also has technical, organizational, and economic impact.

‍

From a Design Problem to a Business Investment

Two buttons with different padding. Three slightly varied components. A form that’s structured horizontally in one product and vertically in another.

‍
At first glance, these are small things. But it’s exactly these details that lead to real costs.

‍
Developers lose time because they have to recreate or adjust components. Designers rebuild things in Figma that already exist. And during the handoff between design and development, context is regularly lost — leading to follow-up questions, rework, or unwanted inconsistencies.

‍
Even new features take unnecessarily long to develop.

‍
Why?

‍
Because basic UI decisions like spacing and states have to be renegotiated every single time.

‍
The result: Every product team solves the same problems—but in different ways.

‍

This means:

‍

• Higher development effort

• Unpredictable project timelines

• A UI that behaves slightly differently from platform to platform

‍

A design system puts a stop to all of this.

‍

It provides centralized rules and reusable building blocks, which lowers initial effort, increases quality, and enables teams to work together instead of against each other.

‍
That not only saves effort but also actively prevents scaling issues.

‍
A benefit that decision-makers can understand.

‍
A design system doesn’t just save design time—it saves product time, development time, and thinking time.

‍

And that’s exactly why it deserves a seat at the table when it comes to investment decisions.

Typical Objections – and How to Address Them

Anyone proposing a design system rarely gets an immediate “yes.”

‍
Instead: follow-up questions, skepticism, sometimes a nod followed by radio silence.‍

‍
That’s not because the idea is bad.‍

‍
It’s because it’s misunderstood.‍

‍
Here are four common objections you should be prepared for – and how to respond to them.‍

‍

“We don’t have the (design) resources for that”

‍
Probably the most common argument.‍

‍
And it’s completely understandable—almost every team is overloaded.‍

‍
But this objection actually offers a great opportunity.‍

‍
Because a design system shouldn’t be seen as an extra project, but as a way to save time.‍

‍
What you can say:

‍
“That’s exactly why we need it. Because we’re already spending too much time on repeated work and coordination. The system would help us roll out features faster—consistently.”

‍
Even better: show concrete examples of how much time is currently spent on manual UI decisions, and how that process could be streamlined in the future.‍

‍

“It’s not a priority”

‍
Here, it helps to be direct: a design system involves design, but it also relieves development, product management, and QA.‍

‍
What you can say:

‍
“Design creates the foundation, but it’s built, maintained, and used by multiple disciplines. It’s not about look & feel—it’s about reusability, technical quality, and product speed.”

‍
A small shift in perspective is often all it takes to turn a “design thing” into a team-wide initiative.‍

‍

“But we already have components”

‍
Almost every product team has some kind of component repository.‍

‍
What decision-makers often don’t realize: a design system is more than that.‍

‍
What you can say:

‍
“A design system ensures that design and code are aligned—inclusive of documentation, guidelines, and tokens. That’s when it becomes usable across teams: by devs, designers, and PMs alike. A loose collection of components is a start, but it’s not a system.”

‍
Tip: Make it visible where current components differ, how often near-duplicates are created, or where documentation is missing. That helps make the issue tangible.‍

‍

“That’s only worth it for big companies”

‍
A common misconception.‍

‍
In fact, smaller or mid-sized teams can benefit even more from a design system—because resources are more limited.‍

‍
What you can say:

‍
“We’re already building recurring elements—just without a system. With a compact, well-documented setup, we’d see results quickly. It doesn’t have to be a massive project.”

‍
Emphasize that it’s possible to start small: with an MVP, the most important components, and clear rules. Then grow step by step.

‍

If you identify and address these objections early, you can turn resistance into openness.
And a “maybe later” becomes: “Show me what that might look like.”

The Elements of a Convincing Business Case

If you're proposing a design system, you’ll need numbers, comparisons, and a clear narrative.‍

‍
The business case serves as a kind of decision-making template for your manager.‍

‍
And it works best when it convincingly answers three key questions:‍

‍

• What does it cost?

• What does it deliver?

• What happens if we don’t do it?

‍

Here are the essential elements your case should cover—pragmatic, concrete, and adaptable to your organization.‍

‍

Define Your Goals

Don’t start with the system. Start with the problem.

‍
What exactly should the design system achieve for your company?‍

‍
Typical goals include:‍

‍

• More consistent UI across multiple products

• Faster implementation time for new features

• Less redundancy in code

• Fewer back-and-forths between design and development

‍

Important: Avoid vague terms like “better quality.”

‍
Instead, be as specific as possible—for example: “Reduce UI rework by 30%.”

‍

Current-State Analysis

A business case becomes convincing when it clearly shows how costly the status quo is.‍
Make visible:‍

‍

• How often are components built more than once?

• How long does it currently take to go from design to development?

• How many design decisions have to be renegotiated repeatedly?

• How much time is lost due to missing documentation or clarification questions?

‍

You don’t need perfect numbers—estimates and small audits are often enough to indicate the trend.‍

‍

Example:

‍
“On average, it takes 4 hours to hand off and implement a button. With 15 buttons per release, that’s 60 hours. With system components, it would be just 10.”

‍

Key Figures & ROI Logic

Now it gets tangible: What will the system cost—and what will it save?‍

‍
Most of the costs come from the working hours and focus required during setup.

‍

Typical items in a design system planning phase include:‍

‍

• Design time to build components, tokens, and guidelines

• Dev time to create and document code components

• Coordination with teams on roles, naming, usage, and governance

• Enablement: training, onboarding, and documentation

‍

What does that mean in numbers?

‍
That depends largely on the scope of the system, team size, and existing design foundation.

‍

As a guideline:

‍
An MVP setup with 6–8 core components might take about 5 person-days.

‍
A more comprehensive system with 25 components — including individual atoms and full sections — could take 2–3 weeks of work.

‍

But here’s what matters: it’s a one-time initial investment that can be planned in stages, e.g. spread over a quarter.

‍

A design system isn’t an abstract cost block—it’s an investment that pays off quickly under realistic usage scenarios.

Stakeholder Perspectives: Who Needs What – and How to Convince Them

Not all decision-makers care about the same things.‍

‍
A CEO thinks in terms of numbers and impact.‍

‍
A CTO looks for scalability and code quality.‍

‍
A product team wants to ship faster—without sprint frustration.‍

‍

That’s why:‍

‍
Tailor your arguments to the perspective of each stakeholder.‍

‍
Here are the key roles – with matching talking points:‍

‍

Product Teams

‍
What they need: Predictability, less back-and-forth, clear UX

‍
What you can say:

‍
“A design system cuts down on standard discussions during sprints. It provides patterns everyone can rely on—so you don’t have to make the same decisions over and over. That speeds up your work and makes features more consistent.”

‍

Developers / Engineering Leads

‍
What they need: Reusable code, less duplication, technical quality

‍
What you can say:

‍
“Instead of building the same component five different ways, we use defined building blocks with clear state logic. That saves time, reduces bugs, and lowers long-term maintenance effort.”

‍

Designers

‍
What they need: Fast iteration, less redundancy, clearer design decisions

‍
What you can say:

‍
“Instead of rebuilding buttons, modals, or forms each time, we rely on tested system components. That speeds up prototyping and gives us more time to focus on real UX improvements.”

‍

CPO / Head of Product

‍
What they need: Time-to-market, team efficiency, focus on user value

‍
What you can say:

‍
“When standard UI elements no longer need to be reinvented every time, teams gain time to focus on the actual product. That accelerates development—especially for recurring requirements.”

‍

CEO / CFO

‍
What they need: Cost efficiency, brand strength, strategic impact

‍
What you can say:

‍
“A design system pays for itself within a few months—by reducing redundancy, easing team workloads, and preventing technical debt. At the same time, it strengthens the brand experience and reduces long-term maintenance costs.”

‍

The clearer you show the specific value for each role, the more likely you are to gain buy-in.

‍
Because every stakeholder needs to see themselves in the system—and understand the benefits.‍

‍

4.5 Pilot Projects & Quick Wins

You don’t need to start with a full-blown system.‍

‍
Propose starting with a pilot team or an MVP component set.‍

‍
That lowers the entry barrier and gives you early wins to help argue for further expansion.‍

‍

Example:

‍
“We’ll start with 6 core components in Figma and Storybook. Goal: to use them consistently by Release X, gather feedback, and document the effort.”

‍

This shows that you're addressing concerns and willing to demonstrate value with minimal initial investment.

Conclusion and Call to Action

A design system is more than just a style guide.‍

‍
And a business case for it is more than a few nice-sounding arguments.‍

‍
It’s about clearly and strategically demonstrating why the investment pays off—for your team, your product, and your company.‍

‍

Key takeaways at a glance:

• A design system is the infrastructure for building better, faster products.

• A strong business case speaks the language of decision-makers: concrete, economical, and goal-driven.

• Focus your argument on numbers, time, and risk—not on aesthetics.

• Show what the status quo is costing you and what systemization could unlock.

• Start small but intentional: pilot projects and MVPs build trust and deliver measurable results.

‍

Now Plan Your Next Steps

If you’re thinking, “We really should do this,” then now is the right time.‍

‍
Here’s what you can do:‍

‍

• Conduct a small UI inventory: What’s being repeated often? Where are the friction points?

• Document specific pain points: How much time, back-and-forth, or confusion do they cause?

• Outline an MVP system: 5–6 core components are often enough to get started.

• Align with your tech and design colleagues: Who has capacity? Who needs what?

• Prepare a brief decision memo: goals, effort, and benefits—no PowerPoint needed.

‍

And if you still need to convince others internally:‍

‍
Feel free to share this article.‍

‍
That’s exactly what it was written for.

‍

If you have any questions or are looking for support:

‍
We’d be happy to help you with your design system setup.