Building a compelling business case for a Design System

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?

Efficiency
36% faster to market, for new features and products

Maintainability
42% less ongoing maintenance cost for the business

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

Accessibility
12% potential user-base increase, unlocking further revenue streams

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

*Remember*
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.