I once watched a very talented design director lose a boardroom so completely that the CEO started talking about lunch plans before the Q&A had even started. It was a Tuesday in November, a financial services firm, and the deck was genuinely excellent. The argument was airtight. The design director had spent three weeks on it.
But somewhere around slide four - the one with the component library diagram - the CFO's eyes glazed over, and that was that.
I've been in that room more times than I'd like. Sometimes presenting, sometimes sitting alongside the presenter, sometimes just watching. And the pattern is always the same. The argument is right. The language is wrong.
A design system sounds like a design team project. Why does the C-suite need to be involved?
That reaction - and I hear it constantly - tells you everything about the gap. Design systems aren't a design team project any more than the electrical wiring in your office is an electrician's personal hobby. It's infrastructure. The thing that makes everything else work faster and more reliably. But if the only people who understand it are the ones who build it, it'll never get funded properly. And if it never gets funded properly, you'll keep rebuilding the same button from scratch. Over and over again.
Let me strip this right back, because the terminology is half the problem.
A design system is a shared library of reusable building blocks - buttons, forms, navigation patterns, page layouts, typography rules, colour definitions - that your teams use to build and maintain digital products. Instead of every designer and developer creating these elements from scratch every time, they pull from a common kit. Think of it like LEGO. You don't mould new bricks for every model. You use standardised pieces that click together predictably.
The system includes the components themselves, the rules for how they're used, the code that powers them, and the documentation that keeps everyone aligned. When your brand updates its primary colour, you change it once in the design system and it propagates everywhere. When you need a new landing page for a campaign, the marketing team assembles it from existing, pre-tested components instead of commissioning a bespoke build.
That's it. No jargon required.
Without a design system, every project starts from a blank canvas. Every new page, every new product feature, every campaign microsite is a custom job. Custom jobs are slow, expensive, and inconsistent. With a design system, you're assembling from proven parts. The build is faster. The testing is lighter, because the components are already tested. The output is consistent. And crucially, you're not dependent on an agency every single time.
Vague assertions about "efficiency gains" won't survive five minutes with a CFO. You need numbers.
Build speed. Organisations with mature design systems report 30-50% reductions in UI development time. Salesforce documented a 50% reduction after implementing their Lightning Design System, and similar figures show up across firms that have actually measured it. If your team currently spends 2,000 developer hours per quarter on UI work, that's potentially 600-1,000 hours freed up. At a blended contractor rate of £100-150 per hour, you're looking at £60k-£150k per quarter in development cost savings alone.
Rework and inconsistency. Without a shared system, design inconsistencies create rework. A developer builds something that doesn't match the designer's intent. QA catches it - or worse, a client catches it. It goes back. This cycle typically accounts for 20-30% of total project effort. I worked with a mid-sized SaaS firm last year that tracked rework hours before and after implementing a design system. Before: roughly 22% of each sprint was rework. After: 7%. That's not a rounding error. That's a structural change to how much you're paying to get things done.
Agency dependency. This is a bit close to home for me to say, given what we do for a living, but I'll say it anyway. If every content update, every campaign page, every minor UI tweak requires an external agency, you're paying premium rates for commodity work. A design system gives your internal team the building blocks to handle 60-70% of those requests in-house. One firm we worked with - a financial services business with about £400k in annual agency spend on digital - got that down to £180k within 18 months of implementing a design system. Not because they stopped using agencies. Because they stopped using agencies for things they could do themselves.
Time to market. When your competitors launch a product page in two days and it takes you three weeks, that's a revenue problem. Design systems compress turnaround times because you're not reinventing the wheel on every project. I've seen campaign landing pages go from a three-week turnaround to two days. For a firm running 20-30 campaigns a year, that cumulative shift in speed is enormous.
Numbers on their own aren't enough. You need a story. And the best business cases I've seen for design systems follow a pretty consistent structure.
Start with the current cost of not having one. Audit what your team is spending today. How many hours per sprint go into building UI components that already exist somewhere in the codebase? How much rework happens because of inconsistency? How much are you paying agencies for work that could be done internally with the right toolkit? How many weeks does it take to launch a new page or product feature? These are your baseline numbers. They're almost always worse than people expect, because nobody's been tracking them as a unified problem.
From there, project the savings. Based on industry benchmarks and your own baseline, model the reduction in development time, rework, and agency spend. Be conservative. If the research says 30-50% reduction in UI development time, use 25% in your business case. CFOs respect conservatism. It also means that when you hit 35%, you look like a hero.
Include the investment cost honestly. A design system isn't free to build. Depending on the complexity of your digital estate, initial investment typically ranges from £80k-£250k for a mid-sized organisation, with ongoing maintenance of roughly 15-20% of that annually. Don't hide from these numbers. Present them alongside the savings and let the maths speak for itself. In almost every case I've seen, the system pays for itself within 12-18 months - often faster.
And show the compounding benefit - this is the bit most people miss. A design system isn't a one-off efficiency gain. Every new product, every new feature, every new campaign benefits from the investment. The hundredth page you build with the system costs a fraction of the first. Over a three-year horizon, the ROI curve gets steep.
If you want help running the numbers for your specific situation, we can do a design system ROI assessment in a fortnight. It gives you a document your CFO can actually work with, not a design deck with aspirational quotes about consistency.
I've sat through enough of these conversations to predict the pushback with reasonable accuracy.
"It's too expensive." The most common one, and honestly the easiest to counter. The question isn't whether a design system costs money - it does. The question is whether it costs more than not having one. Add up your current UI development hours, your rework cycles, your agency invoices for routine updates, and the opportunity cost of three-week turnarounds. In almost every case, you're already spending more than a design system would cost. You're just spending it inefficiently, spread across dozens of budget lines where nobody's connecting the dots.
"Sounds like a luxury. We've got bigger priorities." I get this one. When you're juggling platform migrations, AI strategy, and a CRM held together with duct tape and optimism, a design system can feel like a nice-to-have. But a design system makes all of those other initiatives cheaper and faster. Calling it a luxury is like calling the foundations of a building optional because you're focused on the kitchen design. You can skip it, but everything you build on top will cost more and last less long.
"Can't we just use templates?" Templates solve a different problem. A template gives you a pre-built page layout. A design system gives you a complete, interconnected set of components, rules, and code that can be assembled into any layout - including templates. Templates don't scale because they're rigid. When your business needs something a template doesn't cover, you're back to custom builds. A design system is flexible enough to handle the templates and everything else.
"We tried something like this before and it didn't stick." Fair. A lot of design systems fail - usually because they were built by the design team in isolation, without developer buy-in, without governance, and without executive sponsorship. Which is, ironically, exactly why you need C-suite involvement. A design system treated as a side project will die as a side project. One that's funded as infrastructure, with clear ownership and ongoing maintenance budget, becomes part of how the organisation operates.
The mistake most design leads make is pitching the design system as a design initiative. The moment you do that, it gets categorised alongside mood boards and brand guidelines in the executive's mind. That category has a budget ceiling, and it's low.
Frame it as a delivery infrastructure investment instead. You're not asking for money to make things look nice. You're asking for money to make things go faster, cost less, and break less often. That's an operations argument. A CFO argument. A CEO argument.
A framing I've used that tends to land well: "We're currently paying for bespoke craftsmanship on every digital project when we should be paying for standardised manufacturing. The quality goes up, the cost goes down, and the speed goes up. We just need to invest in the tooling."
Manufacturing versus craftsmanship. Most C-suite leaders get that distinction immediately. Nobody thinks BMW should hand-build each dashboard from scratch.
Getting the initial budget approved is only half the battle. The harder half is keeping the design system alive after launch.
Design systems that thrive have three things in common. A named owner - someone whose actual job includes maintaining and evolving the system, not a side-of-desk responsibility. A governance model - a lightweight process for proposing new components, reviewing requests, and retiring old ones. And ongoing budget: typically 15-20% of the initial build cost per year, but enough to keep the system current and stop it becoming another piece of technical debt.
That last point is worth sitting with. An unmaintained design system is worse than no design system at all, because people stop trusting it and go back to building things from scratch - except now you've also spent money on the system. So when you make the case to your C-suite, make the case for the ongoing investment too. Not just the build.
If you've read this far, you're probably already convinced a design system makes sense. Your challenge isn't belief. It's ammunition.
Download our design system business case template - it gives you a structured way to calculate your current costs, project savings, and present the argument in a format that speaks to finance and operations leaders rather than design leaders.
And if you need specific numbers tailored to your organisation - your development costs, your agency spend, your current turnaround times - we can run a design system ROI assessment in a fortnight. It's a diagnostic, not a sales exercise. It gives you something you can take into the boardroom with confidence.
Because the worst outcome isn't that your C-suite says no. It's that they never hear the argument in the right language, and you keep rebuilding that button. Over and over again.