Célio
  1. About
  2. Projects
  3. Contact
  1. Author
    Célio Pires
  2. Published
    2025
  3. Category
    Design Systems

Driving adoption in design systems

Building a design system is one thing. Getting people to actually use it is another. Across projects like El Español, Telefónica, Commons, and Metallicus I saw the same pattern: great components, zero adoption, and chaos creeping back in.

Design Systems - Design team discussing the design system
Design Systems - Design team discussing the design system

Why adoption matters

Building a design system is one thing. Getting people to actually use it is another. Across projects like El Español, Telefónica, Commons, and Metallicus I saw the same pattern: great components, zero adoption, and chaos creeping back in.

Without adoption, teams build their own versions, logic shifts from squad to squad, engineers patch things on the fly, reviews drag on, and design debt piles up. A system only works if people use it. Otherwise it's just a Figma file.

I didn't just build components. I made teams understand why the system mattered, how to use it, and how to keep it alive. Half my time was talking, half was designing. Getting teams to actually use the system required a mix of strategy, communication, and persistence.

Getting teams to actually use the system required a mix of strategy, communication, and persistence. The approach changed depending on the team size and product complexity, but the core principles stayed the same.

Getting buy-in

The first step was showing the cost of chaos: slow delivery, mismatched UI, more bugs. People adopt when they see the pain. I showed teams before and after implementing the system how much pain it removed: fewer inconsistencies, faster development, shared vocabulary, easier onboarding, and fewer UI bugs.

Once people realised it actually made their life easier adoption happened on its own.

Engineering alignment

I looped in developers early, agreed on naming and logic. Even without Storybook, the system mapped cleanly to code. Every component came with clear usage notes: when to use it, when not to use it, behaviour rules, accessibility basics.

This alignment made the difference between a system that lived in Figma and one that actually worked in production.

Rollout

Different products needed different plans. For smaller teams a simple library and a short guide was enough. For bigger ones I created a migration plan, support sessions, deprecation process and a feedback loop.

The key was starting small, proving value, then expanding. Teams that saw immediate benefits became advocates for the system.

Handling resistance

"This doesn't fit my flow?" I reviewed, adjusted, or explained trade-offs. Most pushback is clarity, not intent. When someone said a component didn't work for their use case, I'd sit with them, understand the actual need, and either adjust the component or show them how it could work.

Sometimes the system needed to evolve. Sometimes people needed to see it differently. Both were valid.

Keeping it alive

A design system dies fast if nobody takes care of it. So I added a small routine of reviews: check new components, audit the library, clean duplicates, refactor when the product changed.

Nothing fancy. Just consistent care. Review new components, clean duplicates, audit usage, refactor when the product shifts. Simple, consistent care kept the system relevant and teams trusting it.

Impact

The results were pretty consistent: teams shipped faster, UI mismatches dropped, less rework, cleaner code, happier designers and engineers.

Sometimes bug counts went down.

Sometimes the same buttons stopped being rebuilt three times a week.

Sometimes both.

What I learned

A design system isn't just components.

It's alignment, trust, and adoption.

The structure matters, but adoption is what makes a system real. If people trust the system everything else is easier: design, code, decisions, releases.

Latest Articles

Insights and learnings from building design systems across different products and teams.View all articles

Driving Adoption in Design Systems article
Driving Adoption in Design Systems
Building a design system is one thing. Getting people to actually use it is another. Across projects like El Español, Telefónica, Commons, and Metallicus I saw the same pattern: great components, zero adoption, and chaos creeping back in.
Creating and Scaling Design Systems article
Creating and Scaling Design Systems
I've worked on a bunch of products over the years and most of them had the same issue. As teams grew the UI started to drift. One team shipped something new, another team updated an old screen, someone copied an old button from a file from 2019… you know how it goes. A design system became the only way to keep things clean and predictable.
Working with Engineering article
Working with Engineers
Design systems only work when design and engineering move in the same direction. On projects like Bitloops, Clutch and Metallicus I learned that early alignment saves everyone time.
Rolling a Design System out article
Rolling a Design System out
Rolling out a system is never "drop the library and pray". Each product needed something different.
Handling Resistance article
Handling Resistance
There's always a moment where someone says "this component doesn't fit my team's flow." Most resistance is not about the component. It's about trust.
Keeping a Design System alive article
Keeping a Design System alive
Most design systems die after the first release. Everyone's excited for two weeks and then the product grows and the system stays still. Nothing fancy. Just consistent care.