Getting executive buy-in for your design system

Designers, you’re likely familiar with the challenge of explaining inside your company what exactly a design system is and what value it provides.

Something else that’s pretty common for us designers: getting executive buy-in without having analyzed the specific circumstances of our company, assuming that executives have to understand the advantages without any previous explanation.

My team at Solera Global Data & Content (GD&C) recently went through the process of getting executive buy-in for our design system, and I’d love to share what we learned along the way.

First things first: Understand your context

The challenges faced by a startup are different from those faced by a company with thousands of employees and dozens of products. At Solera, a global player present in more than 80 countries with a wide product portfolio, we fall into the latter category.

For an organization like ours, having a shared design language is key to align all of those products. If you’re in a similar context, creating the business case for your design system shouldn’t be too difficult. But if you’re at a startup, you still have solid reasons: no matter the size of the company, a design system will allow you to iterate faster, will strengthen your brand image, and will allow you to scale in the future.

As a general rule: The bigger the product portfolio, the more necessary a design system is, so the more likely it will be to get executive buy-in.

In a similar way, if you’re competing in an industry with high design standards, having a high-quality design language is a must in order to be competitive, which should make it easier for you to get executive buy-in. If that’s not the case, things might be a little more difficult at the beginning, but it will also be an opportunity for you to show the value of design because a design system can be a strong competitive advantage.

Related: Managing your design system just got easier

Finally, have a clear idea about who you have to convince first to launch your design system. It will probably be a CEO, a head of product, or a head of engineering, so you’ll have to wear a business hat. In our case, we decided to convince first the VPs of product and engineering, and now they’ve become the biggest supporters of our design system!

Build a combined initiative and align your team

A design system isn’t something that affects the design team exclusively, so don’t go to war on your own: Build a combined initiative with the front-end team, and your chances of getting executive buy-in will be much higher. It’s not a set of beautiful components built in your preferred design program, but a set of design and coding principles and UI components ready to be used in your products. So for them, it’s as important as it is for you.

And don’t forget to prepare your pitch and your approach with your team. We worked and discussed the different approaches for weeks before trying to convince the rest of the world.

Focus on the value proposition

Think and act as a product manager. Your design system is your product, so you must define a clear value proposition for it. You can build it following a problem-solution-value structure: Create a three-column table and write down the problems you’re facing today in one column, how the design system will provide solutions for them in the middle column, and the value generated by each solution in the last one.

Other benefits we’ve detected by carrying out a similar exercise at Solera GD&C were:

• Scalability: you’ll be more prepared to scale both the design and front-end areas in the future.
• Creativity: by building a repository of rules and components, you’ll spend less time on pixels, which gives you more time to redesign your customers’ experience and come up with disruptive solutions.
• Learning-curve: once your products are consistent, their interfaces will be more predictable, leading to a reduced learning curve across products.
• Updates: it will be faster and easier to update your products’ UI.
• Themes: you will prepare your products for themes! This is especially important if you’re planning to build white-label solutions or products for third-parties.

You should now have a clear idea about the core elements of your value proposition, but we’re still missing a central element: facts supporting it. Let’s take a look!

Related: The benefits of shared design systems

Don’t forget the facts

The same way that a product manager has to forecast the potential business impact of a product to build a business case, you should think of ways to estimate the impact of your design system. It can be tricky and scary if you’re not used to it, but it shows that you’re thinking in business terms. You can extract facts from third-party studies or build some metrics yourself, which I highly recommend. Let’s look at some metrics you could use.

Time saved per feature (performance)

Try to be creative finding ways to measure ROI. For instance, you could estimate how much time and money you would save with a design system by doing a hackathon with your team:

• Select a couple of features or screens using the sizing standards used in your company. Let’s say an M.
• Measure how long it takes to design it from scratch, creating all components versus reusing components.
• Measure the difference.
• Calculate how many hours you could save per month and per designer.
• Multiply it for the number of designers in your team and the average designer salary per hour within the industry.

Delivery increase (performance)

If you work in sprints like we do at Solera GD&C, knowing how much time you save by using a design system and how many story points you currently burn per sprint, you could estimate the increase in your team’s delivery.

Bugs reduction (performance)

You could ask the front-end team to calculate what percentage of the bugs reported could be removed by using the design system. Many of the bugs come from the problems mentioned earlier.

Usability metrics improvement (performance)

If you’ve conducted tests with users in your company, you’ll already know that some of their problems are produced by a lack of consistency and clear UI design guidelines. So you could estimate at a high-level how much the success rate could improve for certain tasks. This improvement in the usability metrics would also have an impact on your customers’ satisfaction, so you can expect an improvement in metrics like NPS.

Team happiness increase (satisfaction)

You could launch internal satisfaction surveys to detect how happy your team is and how much dissatisfaction is caused by bugs or back-and-forths between the designers and the developers… This would allow you to estimate the level of improvement in your team’s satisfaction.

Related: An in-depth chat on design systems with digital product design leaders

Be transparent and set realistic expectations

A design system will not be the solution to all your company’s problems. If your products aren’t competitive, a design system won’t fix them. So set clear expectations about what you will or won’t be able to solve with it. When presenting your ROI estimations, be transparent about the calculation method and the assumptions behind them. And don’t forget to be realistic about your capacity. Don’t over-promise.

At Solera GD&C, we’re now more than 14 designers and researchers distributed across two locations (Madrid and Dallas), so we now have capacity. But at the beginning, we were just three designers, so we started aligning a couple of products, using them to build the initial set of components and principles, and growing from there.

Finally, although you want to focus your pitch on your value proposition, you can expect some tactical questions like:

• "Will it take you long to build it? Will it have an initial negative impact on your already arranged deliveries?"
• "We have several distributed front-end and design teams. How are you planning to coordinate them?"
• "How will you manage versioning and how are you planning to update the products?"

So before doing your pitch, have a high-level "day after" plan.

Plan the day after

Onboard new designers

The new designers joining your team will need some time until they gain confidence using your design system, so assign them a mentor and give them some onboarding time.

Define a design governance model

This is especially important if your team is big and/or is distributed across different locations, and your designers work on different projects, which is our case here. In this scenario, you need to make sure that there’s a clear process to expand the design system and that all the designers are aligned. Otherwise, you’ll end up with designers adding components that already exist, which will cause them to waste time and get frustrated.

To meet those goals, we have defined a distributed model with these principles and rules:

• Contributors and reviewers: We took this idea from InVision. Any designer can be a contributor or a reviewer. If you’re working on a design that requires creating a new component, you will be a contributor, and you will have to send your component to a reviewer to be included in the design system. The reviewer will make sure that the component is aligned with the design system’s rules and principles.
• Cross-office validations: If a component is created by a designer based in Madrid, it needs to be reviewed by a designer based in Dallas, and vice versa. This way, we "force" both teams to be in close communication.
• Global reviews: Every two weeks (every sprint), both teams meet to review all the components added from both offices during that specific sprint to make sure that everyone is informed about the latest updates to the design system. We also have a Mattermost channel dedicated to these communications.

Define a workflow with front-end and QA teams

You’ll need to work in sync with the front-end and QA teams from day one, so define with them a high-level workflow to design, code, and test new components. You will have to iterate it, so keep it simple and light. You can start with this simple workflow:

1. Design: Either on your own or in collaboration with the front-end team (recommended).
2. Review: Once designed, review it with the front-end team to make sure that it’s doable. Solve any doubts and improve it based on their feedback.
3. Code: Now it’s time for the front-end team to code the component.
4. Test: At this point, both designers and QAs should review the component to make sure that it’s been implemented respecting the original design and your quality standards.
5. Include: Once the component has passed the tests, it’s ready to be used in your products, so you can include it in your design system.

Make a high-level alignment plan

If you need to align your products to your new design system, prepare a high-level plan explaining how you’re planning to proceed. Show where you are and in which direction you want to go, especially during the first three months. It doesn’t make much sense to conduct a huge gap analysis of all your products at this point. Like product managers do, look for quick wins.

Related: Don’t personalize design. Make it situationally relevant.

I convinced my boss! Now what?

Communicate often

Now it’s time to start the bottom-up communication. You can send updates by email, do online demos, face-to-face workshops, etc. But don’t forget that the best way to communicate is by showing that you’re adding value.

Be flexible and patient

Launching a design system and aligning your products to it will have an impact on many teams, so it will imply negotiation with different people. In order to succeed you must be empathic, understand the others’ needs and problems, and flexible enough to know when you can and when you cannot push. If your company has a large portfolio, you likely won’t be able to convince everyone from day one, and you can expect different levels of support, so learn to live with imperfection. Be realistic and patient. Find out where the main areas of resistance are and what you can do about them.

Track your progress

Keep track and communicate to your line manager your progress in these four areas:

• Your progress on the design system itself: added components, principles…
• The alignment status of each product
• Metrics showing the ROI of the design system
• Blockers and impediments found

I hope all this helps you convince your company to start working on a design system—I can’t stress enough how much of a positive impact design systems can have on a business, not to mention an increase in customer satisfaction, boost in brand perception, and improved team performance and happiness.

>