We're still terrible at the people parts
Why teams with perfect systems still build around them instead
A few years ago, I was consulting with a health-tech company that had what looked like a textbook design system. Beautiful documentation, a comprehensive component library, clear visual guidelines. The team was proud of it. Leadership loved showing it off to stakeholders.
Then I started talking to the developers.
"We don't actually use it", one told me quietly. "It's easier to build things from scratch than figure out how to make their components work for our edge cases".
The designers weren't much happier. "Every time we propose something new, it takes three months of committee meetings to get approved. By then, the product requirement has changed twice".
The problem was obvious: they'd built a beautiful system that nobody wanted to use. All that effort on components and style guides, but they'd completely missed how people would actually work with it.
And honestly? It bothered me. Not because of the team, but because of our industry’s obsession with shiny documentation sites, while teams are still struggling with basic adoption.
We’re pouring energy into the wrong places – we keep solving the wrong problems.
Perfect component libraries, beautifully crafted tokens, extensive documentation sites that win awards. Meanwhile, teams are building around the system because it's easier than using it.
The data reveals what practitioners already know
What I witnessed within that organisation is happening everywhere. The numbers from this year’s industry survey paint a familiar picture: resource constraints hit 54% of larger companies, while 41% of smaller organisations feel understaffed. Communication consistently ranks as the biggest challenge across all team sizes.
Satisfaction with adoption actually decreases as company size increases – smaller companies report 44% satisfaction with contribution processes, while organisations with 500-999 employees drops to just 28%.
This tells us that most governance models don't scale.
According to the report, over 50% of teams have minimal or no automation for keeping design and development in sync. But automation is just part of the problem.
When you're a small team and everyone sits together, governance can sometimes feel like overkill. "We'll just talk to each other". But then you hire three more designers, split into product teams, and suddenly nobody knows who's responsible for updating the button component when marketing needs a new variant.
I wrote about design system entropy earlier this year – how even well-maintained systems accumulate inconsistencies over time. The governance data shows this isn't just a problem caused by design or technical debt.
It's a communication problem masquerading as a process problem.
What works: Lessons from the field
As a consultant, I’ve had the pleasure of working on a number of design systems with a number of different teams. Regardless of the industry, the patterns of success and failure are remarkably consistent.
Start with constraints, not culture
The most successful implementations I've seen don't try to change culture first.
They make the design system the easiest path for developers, while providing escape hatches for edge cases. I've watched so many teams exhaust themselves trying to change hearts and minds when they should be changing incentives – people will use your system if it saves them time. Not because you wrote beautiful documentation explaining why they should.
Successful teams make the design system the path of least resistance.
Invest in communication as a core discipline
Teams that treat advocacy as equally important as building components see dramatically higher adoption rates. The Design Systems Collective featured one of my recent articles, discussing the concept of teams needing practical guidance, not just documentation.
But what does "communication as a core discipline" actually look like? It's messy and human. And sometimes frustrating.
Take Société Générale's approach: they replaced their fixed "core team" with a flexible council model, used GitHub issue templates for all requests, and saw a 93% reduction in confused questions. The key was creating a single place where people could ask questions without worrying about whether they were asking the "right" person or using the "right" channel.
It's not technical. It's structural, and it works.
Size teams appropriately, but cap growth
It might seem logical for teams to continue scaling their design system team alongside the company, but the most successful teams cap at 20-25 people regardless of company size. Beyond that, teams need hybrid models that combine central coordination with distributed execution.
This mirrors what we see in baseball – the best teams don't just add more scouts or coaches. They get better by combining different types of expertise. You need some people focused on the big picture strategy, others handling day-to-day operations, and clear ways for everyone to contribute without stepping on each other.
Treat documentation as a product
The teams that succeed long-term treat their design system as an internal product, complete with user research, roadmaps, and success metrics. They separate design token versioning from component releases, maintain version-specific documentation, and have clear deprecation processes.
But most importantly, they never stop talking to their users. When teams go quiet, that usually means they're struggling and have given up asking for help.
The federated fallacy
Nathan Curtis made waves in September last year, when he declared the "fallacy of federated design systems", stating that he'd seen a zero percent success rate for truly federated systems (and he’s consulted with over 80 of them). Zero percent.
Let that sink in for a moment.
It matches my experience exactly – the promise of federated contribution sounds amazing in theory: distribute the mainenance burden, get more buy-in from teams, scale beyond a central team's capacity. In practice, it almost never works without significant central coordination.
Here's why: you can't federate accountability. You can distribute tasks, sure. But when something breaks, someone needs to own fixing it. When two teams want conflicting changes, someone needs to make the call.
The hybrid approaches that are succeeding combine central control with federated contribution, but they're very careful about what gets distributed. Design token management stays central. Component architecture decisions stay central. Visual design principles stay central. What gets distributed is implementation details, edge case handling, and domain-specific variations.
Agency vs in-house: Different games, different rules
Having worked both agency-side and in-house, the governance challenges are completely different.
Agencies face project-based resource allocation that conflicts with the ongoing nature of design system maintenance. You're constantly balancing project completion pressure with system quality, and you need to plan for knowledge transfer from day one.
The most successful agency approaches I've seen treat each client system as a mini-product, with clear handoff procedures and post-project maintenance planning. You can't just build it and walk away.
In-house teams have the opposite problem: they have time for long-term thinking, but they often lack the external pressure that forces good governance decisions. I've seen in-house teams spend months debating button corner radius while ignoring fundamental adoption issues.
Fixing the governance problem
All of this analysis is useful, but how does this problem actually get solved? Here's what I've seen work consistently:
Week 1: Audit your communication
Don't start with components or processes – start by understanding how your current system actually gets used (or doesn't). Talk to developers, designers, product managers. Find out where they're working around your system instead of with it. Research shows that most design audits reveal critical gaps between intended use and actual behavior.
Ask specific questions: Which components do teams avoid? What workarounds have they created? Where do they get confused? Document these patterns – they can help reveal your real governance problems.
Month 1: Implement single entry points
Set up one place for all requests to be routed to, whether they're bug reports, feature requests, or questions. And use templates that force people to be specific about what they need.
Société Générale saw a 93% reduction in confused questions after implementing GitHub issue templates with clear categories: requesting something new, general feedback, or reporting bugs.
Most governance problems start with unclear communication. When people don't know where or how to ask for help, they stop asking and start building workarounds.
Month 3: Establish working agreements
Document not just what your components do, but how decisions get made, who has authority over what, and how conflicts get resolved. This includes contribution processes, review criteria, and escalation paths.
Research consistently shows that governance clarity correlates with higher adoption rates.
Define roles explicitly: Who can approve new components? How are breaking changes communicated? What's the process for deprecating old patterns? This is boring work that pays massive dividends.
Month 6: Measure satisfaction, not just usage
Usage metrics tell you what's happening, but satisfaction metrics tell you why.
Survey your users regularly about their experience working with the system, not just whether they use it. Teams with higher satisfaction scores show significantly better adoption rates.
When satisfaction drops, dig deeper immediately. Often, a drop in satisfaction precedes people abandoning the system entirely.
Ongoing: Treat governance as a product
Your governance framework should evolve based on user feedback, just like any other product. What works for a 50-person company won't necessarily work for a 500-person company, and that's fine.
Regular governance reviews are essential – successful teams review their processes annually with specific components reviewed more frequently as needed.
Listen to your users, iterate on your processes, and don't be afraid to change what isn't working.
The industry is maturing past the "build it and they will come" phase. The teams that succeed going forward will be the ones who master collaboration, communication, and cultural integration, not just technical implementation.
AI will accelerate this trend – the organisations that figure out governance for humans will be the ones who can harness AI effectively. Those that haven't, will find that AI amplifies their existing dysfunction.
I've been working in design systems for over a decade now, and I've never been more optimistic about where we're heading. Not because the technology is getting better (it is), but because we're finally having honest conversations about what actually works.
Unlike some of the more abstract problems in our field, governance is something we can actually fix. We just need to stop pretending that it's a technical problem, and start treating it like the people problem it's always been.
Thanks for reading! This article is also available on Medium, where I share more posts like this. If you're active there, feel free to follow me for updates.
I'd love to stay connected – join the conversation on X, Bluesky, or connect with me on LinkedIn to talk design, digital products, and everything in between.