I haven’t talked to a single person working in design systems that wasn’t selling something to someone. It could be convincing leadership for funding. It could be cajoling people to use it. It could be lots of things, but it was always something. Yes, design systems get more scrutiny than other teams. Is that bad? I’ve come to think it’s not.
This post doesn’t have “answers”. If there were answers, there wouldn’t be countless people asking about it. But I do have experience. I’ve been working on design systems long enough to develop a point of view.
Design systems represent massive change to how most software teams work. Of course the design systems team thinks design systems are great. Please excuse those who may have questions before turning everything upside down.
We need more skepticism in this industry. A healthy amount of skepticism keeps us honest. Unfortunately, it disproportionately resides in design systems. The practice will be better for it in the long run. Use that skepticism to improve your skills at influence. That skill will always be valuable.
A common complaint I hear from people who work on design systems is that “nobody cares” about the work they do. It’s true, people overlook systems design work when everything is humming along. When something goes wrong, not so much. Design systems are infrastructure. We don’t gaze in awe at a running faucet pouring clean, drinkable water on demand. We should, but we don’t. The same thing goes for design systems.
The best thing I learned about working on design systems was to stop waiting for the medal. Most people aren’t ever going to care. That’s OK. Those people care about all sorts of things I don’t care about. Design systems don’t need people to care, they need people bought in.
I was far too impatient early in my time working on design systems. I didn’t respect how much change design systems represented—and change is hard. I expected the mountain to come to me, which was immature. Getting buy in doesn’t happen overnight. It should’t happen overnight. Getting buy in is a slow, gradual process of gaining trust.
Be prepared for things to take time. “No” will be be a common term. Do your best to translate every “no” to “not yet”. Use each “not yet” as a data point for improving your case.
There’s almost always something you can do to show progress. It may mean working slower than desired, but some progress is better than none. Focus on what you can do with what you have. Avoid impatience or the delusion of instant acceptance.
This isn’t rocket science, focus on what the company is focused on. The folks who fund the work are more likely to fund what helps their work. The folks who do the work are more likely to use what helps their work. It’s easier to get people bought in when they see how there’s a clear connect between your work and theirs.
Aligning to company priorities may mean delaying critical foundational work for the system. This becomes a balancing act. The foundational work needs to happen, but funding makes it more possible. There’s no right answer for this. Find a blend that works best for all parties.
It’s not enough to align priorities though. The work needs to be visible. People need to know that the design system is driving company priorities. And visibility can be really hard. Getting people to see what other teams are doing requires dogged communication. It’ll be a lot of work, but if our experiences match, it’ll be well worth it.
Charlie Munger said, “Show me the incentive, and I will show you the outcome”. People will not use a design system if there’s no incentive to do so. People will definitely not use a design system if there are incentives against it.
Understanding the ecosystem of incentives at your company and tap into them. It could be compensation, performance, convenience, validation, or all of the above. And don’t stop with one! Different people react to different incentives. Build up a diverse portfolio to pull from.
“We” and “us” are a go-to word in the system designer’s lexicon. “Our system will help us all be more effective”. “We’ll have higher quality output in less time”. That makes sense because the focus is on the whole. And it’s all true. It’s a big part of why I work on design systems.
My experience has taught me buy in doesn’t come from “we”. It comes from convincing people how it will benefit them, as in singular. As in, “Your work will be easier.” “The design system will unblock your pet project.” “Your OKRs will go green.” That piques interest.
Different companies want different things from design systems. For some places I worked, they wanted cost reductions. For others, speed of delivery. Others, quality. Don’t sell quality to a team that’s looking for speed. The beauty of design systems is that there’s so much value to be had. Understand what the company wants and hammer that talking point.
The same goes for people. Some find motivation by doing great work. Other people want to climb the ladder. We’re not here to judge, we’re here to get them bought in. Understand the language that resonates with individuals and deliver it.
A design system without a mandate is a design system with no leverage. If you create any reason for teams to not use it, there’s a good chance they won’t.
A common example is framework choice. Let’s say the company uses Angular but the design system team wants to use React. That’s clearly a bad idea because you’re giving teams the ultimate easy-out for not using the system. Teams will not completely refactor their code base to use something no one is requiring them to use.
A more subtle example would be a design system’s Figma library. Designers have an easy-out if the library isn’t improving output and/or efficiency. People are not going to volunteer to make their work harder. At least not with any regularity.
If the system is not required, the upside needs to be clear and present to everyone. It’s never a bad thing to make a design system desirable to use, but it’s needed without a mandate.
People are more invested in what they’re a part of. Keep an arm’s length from your customers at your own peril. Contributions are an obvious way to make that happen. I’m on record saying that design system contributions are a real mixed bag. But there’s no denying how they can help create personal investment, and thus buy-in.
There are other ways to get people to get people involved beyond contributions. It can be a suggestion on improvement. It can be adding guidelines to documentation. It can be lots of things. The actual thing is less important than its impact on people.
A major in design systems requires a minor in sales. If there’s one thing to take away, it’s that fostering buy in is a full time job. A full time job that no one has time for. The answer isn’t to do two jobs. Instead, find ways to bake selling into the work you’re actually paid to do.
A design system has many touchpoints. Documentation, design librarys, weekly updates, office hours. All of which can help sell the system. There’s nothing stopping documentation from making the case for the system’s value. You can’t expect people to get it if they aren’t made aware.
I spent the majority of my time on “selling” at Pinterest. Either in our comms or prioritizing ways to make Gestalt more appealing. “If you build it they will come” is a fallacy. People won’t buy what you aren’t selling. Prioritize this work.
I believe the substance of design systems is what eventually wins people over. But damn if a little style doesn’t get people’s attention in the short term.
You’re in the game of building trust and credibility. As much as I hate this about people, things that look nice are more trusted. I fought this reality for far too long. Don’t repeat my mistakes.
I primarily focused on substance when I started working on Pinterest’s design system. I leaned on logic and fundamentals to drive the case for Gestalt. I thought improving fundamentals would be the most effective first step. We focused on documentation writing, infrastructure, and core components. I don’t regret that decision, but it did create an uphill battle because those things didn’t turn heads.
Later on we began adding polish to our docs, our Slack comms, and pretty much every other touchpoint. That’s when visibility and buy in accelerated. Would that have happened without the fundamentals in place? Debatable. But there likely was a better blend of basics and pizazz that could have gotten us further, faster.
Don’t sacrifice substance. But also don’t shy away from sprinkling in “just enough style” to get people’s attention. Spend the time to make your artifacts clear and well crafted. This takes precious time, but it’ll build up credibility and trust. And that’s going to get you buy in.
If style gets people’s attention, substance keeps it. Even with the best marketing and hype train-ing, people will eventually ask for proof.
Proof can be a lot of things. It can be testimonials or case studies, but numbers are my go to. Yes, metrics have flaws. People play plenty of games to make the numbers tell the story they want. But there’s not a more effective way to make your case than accurate and honest data.
For every sprinkle of style, heap on a big ol’ glob of substance. Which means you need to have measurements in place. Take the time to quantitatively measure the value of your system. Please. And once you have data to share, share it.
A few other bits of advice:
I’d love to say getting that elusive buy in is where you ride into the sunset and credits role. Unfortunately, buy in on its own can be downright dangerous. A design system team isn’t set up for success if the people around you don’t know what they just bought. That’s a recipe for unmet expectations.
No, the work of getting buy in may not be fun, but buyer’s remorse is much, much less fun. But that’s another topic for another day.