Design Leadership

Building a compelling business case for a Design System

August 6, 2019

Building a compelling business case for a Design System

The art of convincing business brains that a design system is a worthwhile investment for your product team.


Design Systems have reached peak popularity. It’s no secret that this has been an outrageously popular topic over the past few years. It seems like every product team has either built one, is building one, or wants to build one.

For the past 10 years, we’ve been through a bittersweet journey of convincing each other that the benefits of a design system outweigh the potential loss of design freedom, and we’ve come out the other side as a united force. Designers & product teams are convinced, and ready to take the next step towards a more consistent & efficient future, if they haven’t already.

But it’s not designers who we have to convince when it comes to investing in the build of a design system. Especially if we aren’t lucky enough to be in an organisation where design holds the proverbial, yet elusive, ‘seat at the table’. We’ve gotta convince the ones who’ll be setting the budgets, assigning the resources and understanding the cost vs benefit of the initiative.

How can we sell the benefits of a Design System with more focus on appealing to upper management, who may not see the same benefits we do?

Depending on where your organisation is in their journey, you might be:

  • Looking to introduce a design system into your product for the first time
  • Gathering insights to bolster your case to increase the business investment in an existing design system
  • Trying to get the budget to allocate dedicated full-time resources and governance to your already-built system

Design System saturation

A comprehensive Design System is no small task to deliver. That’s why it’s all the more impressive how rapidly the concept has been adopted in product teams around the world.

Design System maturity

When we are looking at Design System adoption & maturity, there’s a full spectrum to consider. It’s not as simple as presence of system, or no system.

Level 1: No system
  • The wild west of design & development
  • Everything is a bespoke design brought to life with custom code
Level 2: Style Guide
  • Styled HTML documentation to show buttons, typography, form fields
  • Component driven code practices starting to form in the front end team
  • Possibly a few reusable symbols built in Sketch
Level 3: Pattern Library
  • Shared vocabulary between design & development forming
  • Documentation of core components (e.g. buttons, form fields), but also documented complex component structures & patterns
  • A suite of reusable nested symbols built in Sketch, but not integrated with the development processes yet
Level 4: Design System
  • Design System is a living organism that generates off the same code that runs your core product
  • Mostly documented system with maintenance of system built into design & development process
  • Design System used as sandbox to build new components
  • Integrated with day-to-day workflows for designers & developers
Level 5: Advanced Design System
  • Fully documented system with a roadmap of future improvements
  • Dedicated full-time team governing, supporting & developing the system
  • Design System is used across UX, UI, Front end Development & QA teams
  • Deeply integrated and essential to day-to-day workflows

Why have Design Systems taken off?

Looking at the state of design in recent times, it’s easy to see why design systems have taken the design & development world by storm, and why building one is a no-brainer for product teams:

  • Growing design teams
    Design is maturing. Organisations are recognising the competitive advantage of good user experience and investing more in design than ever before. This means we are suddenly operating with larger teams, on bigger initiatives. Growing our teams, and onboarding becomes a much simpler task when you have a robust design system to lean on during those first few months when new designers are finding their feet.
  • Infinitely more complex design problems
    The sophistication of our users is increasing rapidly. Since the advent of the iPhone and the AppStore, we’ve turned to software to solve more & more of our life problems. Software needs to become more sophisticated to keep up with the demands & desires of our users.
  • Delivery models that emphasise cross-functional teams
    Agile delivery models are here to stay, encouraging cross functional delivery teams over siloed disciplines. We are all moving at a faster pace, and we’re no longer co-located with other members of our design squad, so delivering consistent experiences across a single product has become harder than ever.
  • Global & Distributed teams
    Our fellow designers & engineers used to be just a few desks away, or a brisk walk across the office. Now it’s become more & more common for our colleagues to be oceans apart and still collaborating through remote tooling to build great products.

UX your business case

As designers, it’s easy to see the benefits of having a central design language to make things more streamlined and cohesive. Design Systems just make good sense. These benefits make sense to the product teams on the frontline of design & delivery, but they are of little consequence once you start to travel up the chain of command in various organisations.

So how can we design our business case to best communicate the clear and tangible benefits of having a design system?

1. Know your audience

Emphasise benefits that appeal to your audience, not to you
Remember, you & your team are convinced about the benefits of crafting a design system. Resist the urge to only focus on the team benefits, and focus on measurable business benefits instead.

Write in the parlance of your audience
Avoid developer jargon or newfangled design terms and craft your business case by articulating your case clearly, and persuasively.

Shape your story by what your audience is thinking
Getting your design system approved & off the ground is contingent on answering all of the following questions:

  • Cost: How much will it cost?
  • Time: How long will it take?
  • Resources: How many people do we need to pull off other projects?
  • ROI: What’s the return on investment?
  • Risk: Who’s going to be responsible for this long term

2. Don’t go to war alone

Get internal support before seeking external buy-in
There’s no point in trying to convince upper management that you need a design system if you haven’t successfully convinced your team yet. Focus on garnering support for the initiative amongst your direct team before putting your case together to get buy-in at the executive level.

Form a united, cogent case together
Get designers, developers, BAs, product managers together and capture every teams perspective. You’ll find more and more benefits this way, and when it comes time to present your case to the powers that be, you’ll have a well rounded argument for why this move will supercharge all aspects of the product team.

3. Timing is everything

Recognise your position in the funding cycle
Is the business investing to scale up? Or is upper management doubling down on cost reductions? Try to avoid asking for a large investment when the business is scaling down.

Present the cure when the pain hurts the worst
If a design system has been a hard sell, focus on waiting for an opportunity where the benefits can really shine.

Getting the timing wrong can make the rest of your case fall over
Time your business case for high impact. If it’s presented at the wrong time, when there’s no appetite for an internal initiative of this size, you can blow your chances of getting buy-in.

Translate team benefits to business outcomes

  • Efficiency
    Efficient team workflow & communication across product verticals
  • Maintainability
    Easier to test and maintain code
  • Consistency
    A consistent user experience & interface across products & devices
  • Accessibility
    Baked in accessibility, to create more inclusive products
  • Scalability
    Knowing that we won’t need to knock back key feature requests in the future.

What does it look like if we re-interpret or translate these benefits into a format that provide business outcomes?

36% faster to market, for new features and products

42% less ongoing maintenance cost for the business

18% less support requests, resulting in one less person per support team

potential user-base increase, unlocking further revenue streams

A stable foundation that will support the next 5 years of feature growth

Shift your focus to tangible business outcomes, instead of filling your case with vague phrases like ‘more maintainable’ or ‘increased efficiency’

The anatomy of a great business case

Now that we know how to translate our product team benefits into more tangible business outcomes, we’re ready to start pulling our case together.

1. Problem Statement

There are two parts to executing a good problem statement. Problem selection, and framing the problem.

Problem Selection
Your product team is likely to be impacted by multiple problems. Instead of selecting one of your own problems, first remember to frame your case for your audience.

  • UX your business case by choosing a key business problem
  • Select and emphasise problems that will appeal to your audience (even if they aren’t the biggest challenges your project team is facing)

Framing the Problem
Once you’ve chosen the right business problem that your design system case will focus around, the next step is to frame the problem.

  • Identify the core problem
  • Outlines who’s impacted by the problem, and how
  • Persuasively articulate how this negatively impacts business objectives

2. Benefits & ROI

What are we gaining from the proposed initiative? As designers, sometimes it’s easy to forget about the things that really drive decisions home at higher levels.

  • Financials come first
    Unless they hail from Design or Engineering backgrounds, executives in upper management will usually look for financial benefits and cost savings first, before focusing on peripheral benefits.
  • Emphasise business outcomes, over team benefits
    Remember to frame your business case around tangible business outcomes, rather than ambiguous team benefits.

A design system increases ROI largely because it reduces cost rather than directly increasing revenue — Brad Frost

It helps to frame your expected ROI by measuring your current inefficiencies.
Start with:

  • How long does your design team spend preparing & communicating detailed specs to engineers?
  • How long does it take to onboard the average designer into your team?
  • How much time is spent ‘recreating’ (designing+developing+testing) elements that already exist?

3. Cost

  • Demonstrate that you clearly understand the cost
    It’s much easier to persuade the naysayers if you can calculate & clearly articulate the project costs.
  • Present multiple cost scenarios
    Give your case a better chance by presenting different cost/resourcing options to balance the project funding & risk.

4. Risk

  • Be realistic, rather than utopian
    Your credibility is at stake if you aren’t as open and honest as possible about the potential risks of the project. If you sell the dream too much, and present a utopian story of success-only, your case will seem too biased and might get chucked to the bottom of the pile.
  • Outline the risks of failure
    What happens if we proceed, and it fails? What’s the worst case scenario? Is there a strategy we can put in place to make sure that any failure is mitigated effectively.
  • Articulate the risk of staying still
    Bigger product team = Increased need for design system
    As a product team grows larger, there’s more need for standardised ways of working. The more people you have, the less efficient workflows will be.

5. Implementation Plan

  • Present a solid roadmap
    Show a clear, deliverable scope, as well as your plans to grow & extend the design system over time.
  • Pinpoint where you’ll see a return
    Clearly indicate in your delivery plan when and how you’ll start to reap the benefits of the design system (hint: the sooner the better)

Introducing the Design System Canvas

To help frame your business case, and start thinking about all the main building blocks of your proposal, it can be helpful to run a team exercise with all the essential brains in the room.

Inspired by the popular Business Model Canvas, the Design System Canvas is a handy new resource to help you kickstart building your compelling business case for a design system in your organisation.

Available to download as a free PDF or PNG resource here.