I've spent the last four years building and scaling a design system at Swisscom. In that time, I've watched some teams adopt it in weeks, while others still fight it after months. The difference was never the quality of the components.

The real problem isn't the system

Most design system teams obsess over the wrong things. They polish button states, debate border-radius values, and build elaborate token architectures. Meanwhile, the product teams they serve keep shipping custom solutions.

The issue is almost always adoption, not quality.

A design system with 30 solid components that every team uses will always outperform one with 200 perfect components that nobody trusts.

Three patterns I've seen kill adoption

1. Building in isolation

The classic mistake: a dedicated design system team builds for six months in a vacuum, then presents a finished library to product teams. The result? Components that don't quite fit real use cases, naming conventions that confuse developers, and zero sense of ownership from the people who need to use it.

What works instead: Co-creation from day one. Invite product designers and developers into your process. Let them shape the API. Their fingerprints on the system make them advocates, not resistors.

2. Ignoring the developer experience

Designers love Figma components with auto-layout and beautiful variants. But if the coded component has a different API, different prop names, or behaves differently than the Figma version, trust evaporates instantly.

What works instead: Code and design must evolve together. Every Figma component update should have a corresponding code update. Tools like Code Connect help bridge this gap, but the real solution is cultural: designers and developers reviewing each other's work.

3. Treating governance as gatekeeping

Some design system teams become the "design police." Every deviation triggers a review, every custom component needs approval. Product teams start avoiding the system to move faster.

What works instead: Make the system the path of least resistance. If teams consistently build outside the system, that's feedback — your system is missing something. Track deviations as feature requests, not violations.

What actually drives adoption

After years of iteration, these are the three levers that consistently work:

  • Speed — If using the design system is faster than building custom, teams will use it. Period. Invest in documentation, starter templates, and copy-paste-ready code.

  • Flexibility — Build components that handle 80% of cases perfectly, and provide clear escape hatches for the other 20%. Rigid systems breed workarounds.

  • Trust — Ship updates reliably. Fix bugs quickly. Communicate breaking changes early. Trust is earned in sprints, not presentations.

The metric that matters

Forget coverage percentages and component counts. The one metric that tells you if your design system is working:

How many product teams voluntarily choose to use it when they could build custom?

If the answer is "most of them, most of the time," you've built something that works. Everything else is vanity.

Start small, stay close

If you're building a design system today, my advice is simple: start with three components that solve real pain points for one product team. Ship them, iterate based on feedback, then expand. The temptation to build everything at once is strong, but restraint is what separates systems that last from systems that get abandoned.

The best design system is the one people actually use.

Want to discuss design systems, UX strategy, or just say hello? Find me on LinkedIn.