Design System Culture Can't Be Governed

Culture Is Cultivated

In history, both past and present, when a people feel over-governed or a government oversteps its bounds there’s usually a common outcome: revolt.

Revolt against a system that isn’t serving you appears in many aspects of life. We’ve all lived through our 12 - 25 years old phases.

We’ve also likely worked for bosses with rules that made no sense, teachers that took the letter of the rulebook a bit too strictly, and dealt with someone with a voice that was only matched in volume by their haircut. Found out about shoelace code and walked around awkwardly without shoelaces on after the fact. Oh that was just me?

Enforcers sometimes act as the catalyst for a culture - one that is determined by the oppressed and in direct-opposition to the goals of the mainstream. A popular Rage Against the Machine lyric fits nicely here.

You can’t policy and punish your way into a culture of high-morale and positive engagement.

Culture emerges from a shared experience, expectations, and language. Culture won’t show up in dress code, but it will show up in style. It can’t be dictated by laws, but will arise in the gray areas between the laws.

We must be careful not to continue the use of vocabulary based in governance. Any attempt to govern the culture which created the design language of your organization will be met with resistance. The design system team is then seen as an obstacle, an enemy of design innovation, not as an enabler.

Elevation, Not Origination

Your product teams tackling interface challenges, experience gaps, and user needs are at the cutting edge of the business’s evolution. They’re the ones in the weeds, iterating fast, discovering what actually works. The design system team should get out of the way in these moments. Let the experts explore. Let the visionaries push boundaries.

The best design in your organization isn’t coming from the design system team. It’s coming from the product teams solving unique problems, evolving the brand, working under product constraints.

Now steps-in the design system team. The best design in your organization is likely to be silo’d, locked into a single team or workflow without a strong presence of community sharing and education. The design system team should first and foremost promote, elevate, and celebrate design decisions that align with the needs of the organization and the users. Without having to write a single line of code or move a single layer in a design file, the design system team can achieve its goals through hype and influence.

This attitude moves the design system team away from the sense of being the dreaded presence in the room to being the group everyone is hoping to hear from. The design system team’s greatest contribution isn’t what they create but what they find and who they connect it to.

Speak The Language of Your Consumers

You can’t influence a culture you don’t understand. Especially so when your natural first instincts are to correct when the opportunity you’re presented with is to listen.

Inclusion within a culture can’t be achieved by observing from a distance. It’s about doing the work to solve problems alongside the people who are in it daily. How do your consumers describe their problems, how do they work through a new interface, what questions do they ask to arrive at their first draft vs what they ask along the way to get to their final shipped and polished feature?

Learning these use cases is impossible without embedding with your teams or building a relationship so trusted that these moments are discussed and shared.

When you’re close enough to listen, you start hearing things that never make it into a support ticket.

You discover that your naming doesn’t match theirs, components you call one thing they call another. Patterns you designed for one purpose are being stretched across three different use cases you never anticipated.

You find the workarounds. Teams aren’t filing issues for half of what’s not working. They’re just quietly building around it because it’s faster than asking permission to do it differently. You only hear about these workarounds when you’re in the room watching them happen.

And you start noticing the questions they ask versus the questions they don’t. What they ask tells you where the documentation is unclear. What they don’t ask tells you where they’ve already given up on the system having an answer.

When you finally close that gap, the system starts reflecting how people actually work instead of how you imagined they would. The vocabulary becomes shared because it was built together, not handed down.

Of course you can’t be in every meeting, every review, every consultation. But you can build habits that keep you close. Browse active design files before they’re marked ready for dev. Scan pull requests. Keep a Slack channel where works-in-progress are shared and equally celebrated and critiqued. Stay close enough to the work and listen how the language is actually being spoken.

This brings us back to the question that started this article. “When is the right time to allow for differentiation?” But if you’re close enough to listen, you realize differentiation isn’t something you allow. It’s already happening. The better question is whether you’re paying enough attention to learn from it.

A Fluent Design System

Every language has levels. You don’t talk to your CEO the same way you text your friends. You don’t write a legal brief the same way you write a Slack message. But nobody would say you’re speaking English wrong in either case. You’re adjusting to context. That’s what fluent speakers do.

In linguistics this concept is called register. The levels of formality that exist within a single language. Formal, professional, casual, slang. All the same language. All appropriate depending on the situation.

Design systems may be more effective through registers.

Your flagship product, the one on the homepage, the one in the investor deck? That’s formal. Full adherence. Every token, every pattern, every interaction considered and intentional. This is the organization presenting itself at its most polished.

The day-to-day product work that ships to customers? That’s professional. Consistent, considered, but with room for judgment calls. A team making a thoughtful decision to deviate from a pattern because their use case genuinely demands it isn’t breaking the rules. They’re being fluent.

An internal tool or early prototype? That’s casual. Still recognizably part of the same design language, but looser. Not everything needs to be pixel-perfect when you’re testing whether an idea even works.

A hackathon experiment or edge-case exploration? That’s slang. Push things. Break things intentionally. See what happens when you use the system in ways nobody planned for. Some of the most interesting innovations in any language started as slang that proved itself useful enough to move up.

Words Matter

The shift I’m proposing isn’t radical, and it doesn’t require you to rebuild your design system from the ground up. It’s a change in posture, in how we show up as a team and how we think about our role within the organization. Rather than positioning ourselves as the authority that needs to be obeyed, we can be the team that listens first, that elevates what’s already working across the organization, and that pursues fluency in the design language alongside the people using it every day. The design system itself doesn’t need to change, the energy we carry through it does.

This matters even more as we head into a world of generative interfaces and AI-assisted design. When a designer can generate a dozen layout variations in minutes, or an engineer can scaffold an entire feature through a prompt, a governance model can’t keep up. But a team that is fluent in your design language? They’ll prompt better, see when a generated output fits the culture and when it doesn’t, make good decisions faster because they’ve internalized what good looks like rather than relying on a checklist to tell them. Fluency scales in ways that governance never will.

From one language you can create prose, poetry, novels, instruction, speeches, propaganda, love letters, breakup texts. All from the same vocabulary, the same grammar, the same shared understanding of how the pieces fit together. Nobody governed English into producing Shakespeare. The language provided the foundation and then got out of the way.

In my opinion, we will reach “peak design system” when we’ve achieved a shared language expressive enough that teams can build anything from it. Not because they followed the rules, but because they’re fluent enough to know what works.