Table of contents

• Introduction
• What did not work
• What could work
• Final words

est 8 min read

Introduction Persuading management to invest in design systems is tough. In my experience, it's not that leaders don't grasp the concept or irrationally oppose it; it's often about how product teams present their requests.

In this story, I'll offer insights on overcoming these challenges and what to anticipate when proposing one. My other stories are about creating and adopting a design system.

What does not work

• Focusing on the what When pitching a design system, it's natural to focus on the what and how: "What is a design system?" "How will we implement it?" "What are the benefits?" However, these presentation slides often miss addressing the company goals. To resonate with management, I realised that you must answer a more important question: “Why do we need it?”

”Working better” is not always a priority for a larger organization. By basing your argument on your own needs, you risk making the design system seem like a personal whim or a fancy tool to make you more comfortable.

Again, unless you align your requests with the goals of the person you are asking, or the company in general, your project will never get off its feet.

• Focusing on the future If you find yourself explaining that what you want to do will solve a problem that your company will have in 2-4 years, then perhaps you’re asking too soon.

Anticipating problems is important, but it is easy to go to the opposite extreme. You don’t want to invest a lot of energy in solving problems that do not exist yet and will not exist in the short term. With my previous experiences I try to point them out early these problems but I am always being cut off with “we are going to cross that bridge when we get there”.

I learned to focus on the present or the immediate future to stay grounded and relevant if I want to get ahead with a design system.

• Not having a ROI defined If your project lacks clear goals, success metrics, timelines, or a defined scope, you're heading for trouble. Leadership dislikes open-ended commitments and will express concern, reminding you that the company doesn't have endless financial resources.

To avoid this, I learned to be precise and have a scope or present the return of investment of having a design system. Metrics such as “saving development time on features, 0 to 1 products, less bugs”. But again the metrics need to be aligned with the organization product roadmap or solve an internal problem company currently has.

These strategies I personally tested when proposing a design system, none of which succeeded in obtaining approval. There may be other factors at play that I have yet to encounter in my career.

What could work I started working on a project that had a few uncoded components in a design library in Storybook and some scattered components in Figma. They did not match in styling or functionality but for that company that was their “design system”.

As our team expanded and our product grew, product teams recognized the need for a robust design system. Securing management buy-in became essential. The main hurdle was showing company leaders the value of the design system. It's not that management didn't understand. They were highly competent, but they had their own priorities. Our pitch needed to align with those priorities.

We pitched and did not got the buy-in. Instead what we did was to start small, because we knew it was important to start. All of our team members were familiar with “Atomic Habits” book. Even if creating the design system didn’t have the status of a formal project, we carved out some unofficial time to show that it’s not that hard to get started. And then we focused on showing results as fast as possible.

Our goal was to demonstrate that for every two-week sprint, we could build or refactor two to three commonly spread components in our products. The idea was to do small things in each sprint that would make our product teams be more productive in the next sprint. Take some workload from their shoulders.

It took a few cycles but the results were starting to appear. Eventually our CTO said, “Ok, let's make a design system official team”. So now the design system efforts were no longer “underground”, and we got our Azure DevOps with our own backlogs and tasks.

Instead of thinking too big and far, we started with the simplest, most common, easiest-to-build components. We called them the “low-hanging fruits”. While working with them we started already to encounter common values that will later would become our design tokens.

How Atomic Habits book helped me in selling the design system: