Make the case: How to get buy-in for building a design system

We've all talked about design systems enough that it seems like by now, the benefits of having one would be clear. A design system helps us build products faster, enables teams to understand shared components and processes, and creates a consistent user experience. But in practice, we often face organizational barriers to implementing said design systems. Not to mention, sometimes it's hard to even sell other designers on the need for a design system.

You’re reading this post, so I know that you probably feel the costs of working without a design system every day. But it’s not always easy to communicate the downsides of not having one, along with the possibilities and benefits of implementing it.

This challenge sits at the core tension of most companies’ two competing needs. There’s the need for functional work (e.g., to ship features), and the need for foundational work (to build infrastructure like design systems that supports operations and growth). Choosing to invest time, energy, and money in one means investing less in the other.

Often, functional work produces tangible, short-term results, like a new onboarding flow that increases conversion rates. But foundational work contributes intangible, long-term results, such as increasing the velocity of feature launches. And yet, both are essential components to running a long-term, sustainable business.

There are many unseen costs of working without a design system. Getting buy-in comes down to showing not just why it makes your life easier, but how it can make an impact at every level of your organization. Here are three practical ways to get it.

Demonstrate how siloes slow down shipping (and create duplicate work)

“Where can I find the latest version of this?”

Whether we hear the question from a new designer or engineer, it pops up when it's not clear where or who to turn to when you need to find something.

One way to get buy-in for building a design system is to find inefficient workflows that highlight the need for more structure. Here are some ways other teams have approached it:

• A peer-to-peer review system, recommended by designer João Araújo, can help uncover breakdowns in the work without specifically pointing fingers. Fanduel found that a design system helped them peer review within a distributed team, because they could all see the design process and provide feedback along the way.
• At Everlane, annotating, exporting, and handing off files to engineers was the final, time-consuming phase of their design process. Now that their team works with a design system, all the files are in one place and can be annotated and then inspected by all team members immediately, no handoff required.

Once you’re talking about how workflow is breaking down, you can suggest how you can work together to fix it. You can demonstrate the need for a design system by highlighting where there are multiple versions of files, duplicative workflows, and a general lack of organization in the design files.

Documentation also decreases the likelihood that we'll be duplicating work. When I worked at Instacart, each designer had their own set of files and multiple copies of said files. Sound familiar? The lack of transparency in our team’s progress created inefficient workflows, which have since been resolved by a design system (one which I had the pleasure of helping implement 😁).

By demonstrating how a design system can be that single source of truth, clarifying the collective decision, and allowing every team to work knowing they have the latest assets, you’ll be better positioned to “sell” it more broadly. You already know, but soon others will, too: when everyone can work with fewer interruptions, we all become more agile.

Highlight how customers notice fragmentation

There was a time when I worked on a small team that was releasing one feature every week. After our initial feature sprints settled down and we were no longer simply treading water, we were able to take a look around, talk to customers, and figure out how to refine the product. In conversations with customers, we noticed them saying things like:

• “I don’t understand why your color palette is super different in this area, and this area.”
• “I know when I click on this one feature, it works this way, not the other way.”

There were clearly points where the product didn’t feel cohesive to the customer. Each segment of the app felt like the voice of each individual designer. Because we hadn’t committed to a standardized set of principles and components, we would often rely on varying personal preferences (“I chose this color palette because it suits my individual feature”).

Inconsistencies in interaction and components cause cognitive strain on new users who can’t understand the logic of the UI.  Ultimately, it leads to an unintentionally diminished customer experience. A lot of this comes from shipping new features constantly, like my team was, without looking back on how the previous features have been performing.

We began to see clear signs of design debt, which my team had accumulated by not prioritizing foundational work as we grew. Over time, we had to refine a lot of design in order to address our customer expectations.

Our focus on shipping features is what caused our design debt to pile up in the first place. If our team is able to consider usability, the benefits of a design system become even more clear.

Another way to increase the likelihood that your organization will buy into the need for a design system is to use metrics and feedback to highlight how we’re negatively affecting the customer experience. Give them the hard facts! Whether it’s pulling in real customer feedback, or adoption/retention numbers.

In the absence of a design system, we put extra responsibility on the customer to figure out how to navigate a platform instead of presenting them with an intuitive and unified design throughout the product experience. Make your design system about the customer, not you.

Involve allies and emphasize design system co-ownership

Despite its name, the benefits of a design system expand beyond the design team. Starting a conversation about how a design system improves workflow contributes to better overall design collaboration, too. More importantly, it allows engineering to become a part of the conversation early, inspiring a sense of ownership throughout the entire process.

Mike Dick, Design Technologist at SurveyMonkey, recommends finding an engineering counterpart within your company, someone who shares your passion for closing the designer and developer gap. This ally can teach you how design systems will be used by developers and how you can best appeal to them. Julie Nergararian, Software Engineer at HubSpot, echoes this need for collaboration: “Redesigns only work when co-owned by designers and developers.”

To start the wider discussion, invite everyone who would be involved in or affected by a potential design system. Keeping participants updated and involved will remain an important part of your design system, post buy-in.

Kick off the conversation by looking for widespread issues within your company. Nick Stamas, who created WeWork’s design system, Plasma, says he started with a Google Doc, getting team members to articulate their problems and where the workflow was breaking down. If something is slowing down a designer or developer, you know it’s also affecting the product manager, who’s responsible for the features that are being shipped out. Since a design system needs to solve issues for a company as a whole, we need to first show team members that each problem is a shared pain that we need to tackle together.

Take those common problems and use them to examine the potential of a design system. Jordan Girman, Senior Director of User Experience at Glassdoor, had his team members look at three questions:

• What’s the need for this system?
• How is design being implemented now?
• How should it be implemented?

Posing these questions to your teammates will not only have them considering how to fix the problems we identified together, but will also how a design system can solve these problems. You can then set design goals and requirements that work for the company as a whole.

Getting other teams involved early means they’re far more likely to actually care when they understand the origins of the design system and the intent behind it from the onset. Seeing the design system evolve over time will also just evoke greater overall enthusiasm and investment into what it will become.

Don’t forget to let people know about your design system

Though change requires upfront investment, our teams can’t grow sustainably without a design system.

Once you’ve gotten buy-in and your team is working on a design system (or has completed a first version of it), it’s important to socialize it. You need feedback from the people using it.

Continuing to keep stakeholders in the loop on system updates will ensure that you’ll all feel a sense of ownership and collectively continue to contribute to make it better. Get people together, even if you have to resort to food bribery (hey, I’ve done it). Because ultimately, a design system supports the core tenets of what it means to be part of a team: people working together to make an impact.

‍