You run the workshop, you make the case, you bring people into the process, and eventually you launch the system with alignment. For a while it feels like the hard part is done. Everyone is on board, the direction is clear, and you’ve got the buy-in you need.

But people leave, new people join, priorities shift, teams reorganise, leadership changes. The clarity you worked so hard to build doesn’t stay fixed, and that’s where most systems wobble. Buy-in is often treated as a one-time event at setup, when really it’s something you have to keep alive long after the launch.

Decisions are never finished

You can document every choice and write down all the rationale in the world, but you’ll still find yourself coming back to the same debates a few years later, or sometimes only a few months or even days later 😭. Shadows or no shadows. Tabs with underlines or backgrounds. Dividers in lists, I’ve lost count of how many times that’s come up.

This can sometimes feel like the end of the world, like you or your team did something horribly wrong and failed everyone. But it’s often not the case at all, it’s usually just an indicator that the design, brand and business are evolving.

The actual mistake happens when we treat our decisions as permanent instead of recognising they will always be challenged, especially as new people join and bring their own perspective.

Documentation helps, but it is not enough on its own. If the rationale doesn’t hold up when questioned, then maybe it wasn’t the right call. Strong reasoning lasts while weaker reasoning falls apart, no matter how well it was written down or communicated.

Of course, we shouldn’t dismiss challenges purely for the sake of change or opinion; you know what I’m talking about, when designers just don’t like something (you know we do this often, don’t pretend). That’s when our rational and better judgment steps in to challenge what’s being proposed or done.

Onboarding is alignment in disguise

When someone new joins your company, they weren’t in your original workshop. They didn’t sit in on the trade-offs or the debates you had. All they see is what exists today, and if you don’t give them the story behind it, they will either reinvent the past or dismiss what’s in front of them.

Onboarding isn’t just “here are the tokens and components.” It’s about showing people the bigger picture of why the system exists, how decisions were made, and how they can play a part in shaping what comes next. The system itself also has to help with this. If your library is cluttered, components are hard to find, or important things feel buried, people won’t stick around to read the rationale. They’ll simply build their own.

The UX of your system needs to be just as visible as the documentation, otherwise the best reasoning in the world won’t stop duplication. For more on this, readDesign System Documentation Sucks (and how we can do better).

Good documentation is never private

Writing documentation for the sake of it or ‘because we have to’ isn’t the point; getting people to use it is. That means surfacing it where people already work, keeping it connected to the components themselves, and making sure that when someone looks for a pattern, they can also find the context that explains it. When the system and its documentation drift apart, people lose trust, and that is when duplication starts.

Here are a few tactics that help keep the system visible and trusted:

Each of these approaches makes documentation feel less like something hidden away and more like part of how the system actually works.

Rogue components will always exist

No matter how polished your system, some teams will go off and build their own versions. Sometimes they didn’t realise the system already had what they needed. Sometimes they believe that their use case is unique. Sometimes, they simply don’t agree, or their user feedback or testing indicates otherwise. More often than not, you’ll see components that look like they came from the system but actually don’t, and while that can be frustrating, it’s not always a disaster. These highlight gaps or blind spots your team wouldn’t have been able to see outside of that product or feature space.

The bigger risk is when components are rebuilt, not out of disagreement, but because people can’t find what already exists. That is not rebellion, that’s visibility. If someone can’t locate a component or its documentation quickly, it’s often easier to rebuild it than to search. This is why the UX of the system matters so much. A system that hides its value behind poor navigation or scattered files quietly invites duplication.

If this is happening, pair visibility work with tactics like a Global Component Audit, Measuring Component Usage, and Component Retire & Replace, so you can see what is actually in use and clean up what is not.

For a deeper look at why contribution is often difficult and what makes it easier, readDesign System Contribution is F***ing Difficult, Let’s Change It.

Scaling alignment is about representation

When you’re working with a handful of apps, you can bring teams into a room and co-create. Once you have a hundred or more, that is not realistic. This is where governance becomes essential, not as top-down rules but through representation and visible ways to participate.

IBM’s Carbon Design System operates in the open with clear contribution pathways and a community model. There is a published steering committee that brings together voices from across design and development. There are explicit contribution guidelines and open code paths that show how work moves through review. Carbon has also written about running the team like a service to drive adoption at scale, and they shared an internal tool called Beacon that helps teams self-evaluate their adoption and maturity. These examples highlight how governance, visibility, and service operations can sit alongside the design work.

Google’s Material Design takes a similar approach with public contribution guidance in the component repos and a strong emphasis on review culture. They have written about how design reviews improve both speed and quality, and how Material itself evolved from a vision into production-ready code. The pattern here is clear standards, open contribution, and repeatable rituals that keep quality high without freezing change.

Public sector systems also show how alignment can scale transparently. The GOV.UK Design System runs a formal working group and maintains a public community backlog where anyone can contribute or comment. They have also written about how they prioritise contributions and how they iterated their contribution model in the open. The NHS Service Manual uses a similar model with clear community guidance and shared resources.

If you want to apply these ideas inside your own organisation, start with tactics like Choosing a Governance Model and Contribution and Review Model. Keep momentum alive with Design Crit and Cross-functional Show and Tell so the conversations stay open and representative.

Culture is the deciding factor

Adoption is rarely about whether the components are technically good enough. It is about whether people trust the system and feel like it represents them. Do they understand why the decisions were made? Do they feel included in the process? Do they believe they have a voice if they disagree?

It is not only about the wider company culture, although that definitely plays a part, but also about how the system itself shows up. A system that feels closed, rigid, or unapproachable will always struggle. One that feels open, transparent, and collaborative stands a much better chance of surviving the inevitable changes that come with growth. If you are looking for a starting point, Crafting System Principles can help anchor decisions, while Design-Developer Collaboration and Design-Developer Pairing Practices ensure the behaviours match the intent.

Keeping the rhythm

Buy-in doesn’t happen once at the beginning. It happens every time someone new joins, every time a past decision is questioned, every time a team decides to go their own way, and every time the system itself evolves. The systems that last aren’t the ones that launch with a perfect pitch. They are the ones that build habits that make ongoing alignment normal. They make components easy to find and decisions easy to understand. They keep contribution processes visible and reviewable. They keep the conversation going so alignment becomes a rhythm rather than a moment 💡.

What this looks like next week

If you want to keep momentum alive, here are three small steps you can take right away:

These are lightweight, repeatable habits that make the system feel present and active, not hidden in a file.