After a decade of designing and building software platforms, the benefits of design systems are second nature to me. However, I often find myself needing to rehash those benefits to rally new teammates and organizations to the cause.

The featured image from Jeremy Brett does a great job of framing the reality that system designers have to negotiate:

Most disciplines in tech companies don’t care whether there’s a design system; they care about the outcomes that a system can facilitate.

In my experience, even design, engineering, and product management have their own hang-ups with design systems, so today I want to address how you might bring those influential groups to your side to bolster support for your next design system effort.

Let’s dig in.

Framing for designers

News flash: many designers are reluctant about design systems.

While it might sound obvious, your first order of business in establishing a system is to get the rest of the design team to care. Otherwise, you’re dead on arrival.

The main concern I’ve experienced with designers is a perception that adopting a system will be too restrictive to their creative process and that it will inhibit their ability to solve specific customer problems. It’s a fair concern, but my response is that a good system is designed to facilitate better design, full stop.

Systems intentionally place restrictions, but the good kind, like guardrails. Designers know how important setting constraints is for the creative process; projects without them often feel paralyzing! A good system acts like a useful starter kit of technical constraints and helps us ensure we deliver something meaningful for the user without getting lost in the weeds.

You shouldn’t have to reinvent the wheel for every pattern you need to achieve a good, new customer outcome. And you shouldn’t have to red-line spec the same component over and over again for development to achieve a consistent execution.

A good system lets you design a pattern once in detail, and then apply it to solve many customer problems. It’s also flexible enough to evolve when you encounter a scenario that requires something new!

Designers get:

1. A flexible tool that facilitates their focus on solving user problems
2. A useful set of constraints when starting new, nebulous work
3. Freedom from designing the same things over and over again
4. Higher likelihood of consistent execution of their designs

Framing for engineers

Most software engineering teams easily see the value of scalable back-end systems. The reasons are clear:

1. If the back end fails, you cease to have a product
2. If the back end is inefficient it crushes you with obvious costs (hello AWS bill).

When it comes to front-end scalability, teams are often more ambivalent since the consequences of inefficiency are less drastic.

However, the impact of a weak front-end system is insidious. Platforms often appear okay visually but the reality of the code makes them hard to maintain and slow to deliver value.

Your HTML and CSS footprint may not make as much of a direct performance impact as other parts of your code, but its complexity at scale can waste expensive hours of developer productivity playing “whack-a-mole” with UI bugs.

This sucks for the developer, delivers a worse customer experience, and slows the team’s ability to ship features that would add more value.

Managing 10 discrete button instances? Not that big of a deal.

Managing 100? Orders of magnitude more challenging, error-prone, and expensive.

Engineers get:

1. UI that’s DRY! (kill off that redundant code)
2. Less time wasted on specific, one-off UI bugs
3. More time building meaningful features
4. Quality new UI with less effort

Framing for product managers

The product management team doesn’t benefit as directly from design systems as design or engineering, but what it does get highlights the core value that systems return for the business.

Design systems are a high-leverage investment.

They require a bigger up-front cost to establish, but achieving a critical mass of system adoption significantly amplifies future UI investment returns. The cost of experimentation, the time to deliver value for customers, and the time to bring a new idea to market all decrease with a good design system.

New features that otherwise would have taken significant runway to design and develop can be prototyped with system elements to achieve a first iteration that adds value for the business much more quickly. Whether that’s just the value of learning or dollar value to your bottom line depends on the circumstance, but either way, it’s value that otherwise would be harder and more expensive to attain.

Finally, for your current customers, a design system helps ensure consistent and dependable experiences. That means internal consistency within your own product(s) as well as consistency with external standards that customers already know and expect. Unintentional inconsistency increases the cognitive load of using your application and results in the perception of a worse user experience even if it works as designed.

PMs get:

1. Higher leverage UI and lower cost builds
2. Better time-to-value and time-to-market
3. More consistent and dependable customer experiences

Final thoughts

The process of getting design system stakeholders to care about system efforts isn’t so different from getting potential customers to care about your product: you have to put on your empathy hat, consider what those people really want, and then work to deliver something that meets their needs. Without that buy-in, any strategy for system creation will struggle.

Ultimately, developing a strong system is a win for everyone, but to build the support you need to execute, you have to communicate the benefits in terms that make sense for each of the roles that will be impacted by it (either directly or indirectly). Bring that added specificity to your pitch and I’m confident you’ll see good results.

If you got some value from this post, consider sharing it, subscribing to my newsletter, or following me on Twitter.