If you’ve ever worked on a design system (or been on the receiving end of a design system build), you’ve probably seen people spend months crafting the perfect system. There’s a load of components with a beautiful Figma library. “Everything” is in place, ready to be used.
And then… nothing. Adoption lags. Designers and developers ignore it or find ways around it. Engineers build their own micro-solutions. Product managers push for custom experiences because the design system “can’t do what they need.”
Why? Because the moment you tell people they have to do something, they start looking for ways not to do it. It’s an observable human trait. Just put a button in front of someone and tell them “don’t touch it,” and the first thing they want to do is… well… smash that button. Nobody likes being forced to do (or not do) something, especially when it feels like a constraint rather than an enabler.
In my years as a design systems leader, I’ve realized the problem isn’t always the system itself (though it often is). Sometimes, it’s the approach to adoption.
Think Like a Product Team Instead
Here’s a mindset shift: Your design system isn’t a rulebook. It’s a product. And I know that word “product” comes with a lot of baggage, but try to set that aside for a moment and come along with the illustration.
For the sake of adoption, what if you thought about your design system like a product? Your customers are designers, engineers, PMs, and other stakeholders who benefit from the system.
Like any product, a design system competes for adoption. Your consumers don’t care about your system’s internal logic or how much work went into it. They care about whether it helps them do their jobs better. If your system slows them down, forces awkward solutions, or lacks flexibility, they’ll find a workaround—just like customers abandon clunky apps in favor of better alternatives.
So instead of assuming compliance, ask:
- What makes this system the best option for our designers and engineers?
- What would make them excited to use it?
- Where does it fall short of their needs, and how do we fix that?
A system that prioritizes its consumers (the teams that use it) will naturally earn adoption. It won’t happen overnight, but good products get attention and traction.
Once you start thinking of your system as a product, it changes how you approach adoption. Instead of demanding compliance, focus on enabling teams to succeed.
Enablement vs. Enforcement: A System That Earns Adoption
Shifting from enforcement to enablement is a newer way of thinking for me. But it’s one that’s proved its value. I had a brilliant dev manager who recommended that we take this approach. At first, I was resistant. I’d never experienced a design system that wasn’t enforced. I was skeptical, but after thinking it over, it made all the sense in the world.
This might feel like a luxury, but the best design systems don’t enforce adoption—they enable it. Instead of restricting teams and punishing people who don’t adopt, they empower them to build what they need within a structure that makes sense. The system is seen more as a supporter than a newfangled process that gets in their way.
This means two things:
- Give teams flexibility when needed. Not every problem fits neatly into an existing component. Teams should have the freedom to build independent one-offs when necessary. They will build it using the system’s foundational elements and tokens, but the flexibility is still there.
- Make contribution easy. If a new pattern keeps popping up, the best move isn’t to reject it—it’s to integrate it. A system should evolve based on real needs, not just its original vision. I personally like the motto, “One is an outlier, two is something to watch, three becomes a pattern.” It’s not perfect, but it’s a helpful guide when looking at what to systematically support.
When people feel like they have a voice in shaping the system, they’re far more likely to use it. It’s no longer something “out there”; it’s something they are a part of.
Consistency as a Feature, Not a Rule
A lot of teams worry that too much flexibility leads to chaos… and it can. But here’s the thing: Consistency shouldn’t have to be enforced—it should emerge naturally.
If your design system is truly the best way to build, people will use it because they want to. Consistency becomes a byproduct of a solid system that gets natural adoption, not a rule people begrudgingly follow.
Of course, guidance still matters. But it should come in the form of support, not policing:
- Design leads encourage systematic thinking rather than gatekeeping every decision.
- Design system teams consult and provide help without being a bottleneck.
- The structure and shape of the system itself should nudge teams toward best practices without feeling restrictive.
A rigid system that doesn’t fit drives people away. A useful system with helpful supports pulls them in.
Governance: When and How to Require the System
OK, but seriously, at some point, you need governance, right? In my opinion, yes. Governance does have a place, but only when the system is mature enough to be set up for success. If the system doesn’t meet 80% of needs, requiring adoption will just lead to resentment. And to understand what those 80% needs are, you have to know your consumers.
The key is keeping it as small as possible while still being useful. Every new component or pattern adds complexity, so build only what’s necessary. Rather than focusing on complex componentry, focus on a really good set of foundations that people can build with—still inside the design system.
In the atomic world, three fundamental particles—electrons, neutrons, and protons—make up everything we see. Design systems should work the same way: a strong foundation of essential building blocks, rather than an overwhelming list of rigid components. Those foundational elements create structure and meaning, inviting teams to build within it. (And, it’s not new thinking at all. Thanks, Brad Frost.)
When governance does come into play, it should feel less like a mandate and more like the logical, natural choice. People should use the system because it’s genuinely the best option, not because they’re forced to. They should say, “Oh, I’ve heard good things about this, and it really seems to make sense.”
Final Thought: If You Build It, They Might Come… If It’s Worth It.
A design system isn’t successful because leadership mandates it. It’s successful when people in organizations (like designers and engineers) choose to use it. They opt into the benefits of the system.
The real measure of success isn’t compliance—it’s enthusiasm. And that feels a lot like a good product. A good product gets people excited about its benefits and value.
If your system is struggling with adoption, maybe the answer isn’t more enforcement. Maybe it’s better enablement. Make it so good that people don’t just use it—they can’t imagine working without it.
💬 How has your team approached design system adoption? Drop a comment—I’d love to hear your experiences!
• • •
Oh, one more thing: This is my first article in a short series I plan on leading design systems. If you have specific topics you’d like to see covered, leave a comment or note, or reach out on LinkedIn, and I’ll consider adding it to my upcoming list.
