Design systems in large organizations: when coherence is a decision of governance, not aesthetics
A well-built design system is not a collection of buttons and fonts. It is the decision of how an organization ensures consistency when hundreds of people build the same product. And that decision is one of direction, not design.
A design system is not a library of components. It is a government decision.
There's a conversation we often have with new clients. It starts when they tell us that they already have a design system, and it ends when we ask them who decides what goes into it.
If the answer is "there is a team that manages it", we are good. If the answer is "it depends," "it's not clear," or "every team has something different," the problem isn't the system — it's the governance around it.
Or rather, the lack thereof.
The mistake of treating a design system as a design product
Most design systems fail for the same reason: they are designed as if they were a design product when in reality they are an organizational infrastructure.
A design product has a design team, a product team, users and a goal. It is iterated, it is improved, it is launched. Quality is measured in usability, in adoption, in impact on the business.
A design system has all that, plus something a normal design product doesn't: multiple teams that depend on it to build their own products. Equipment with different needs, with different deadlines, with different aesthetic criteria and with different levels of understanding of what the system is and what it is for.
Managing that complexity is not a design problem. It is a government problem.
What does it mean to govern a design system
Governing a design system means having answers to these questions:
Who can propose changes to the system? Any team, or just some? With what process?
Who approves the changes? A committee, a person, the team that manages the system? With what criteria?
How are changes communicated to all teams that depend on the system? How much in advance? With what documentation?
What happens when a team needs something that the system does not contemplate? Can you make an exception? Under what conditions? Who knows?
How does the system evolve when the brand or product changes? With what migration process for products that are already in production?
These questions are not answered in Figma. They are answered in a governance document that the team understands, accepts and respects — and in an organizational culture that enforces it.
The federation model
In large organizations where we have built or maintained design systems — banking groups, insurance companies, infrastructure operators — the model that works best is the federation model.
In the federated model, there is a central team that manages the system: defines standards, approves changes, communicates updates. But product teams have some autonomy to propose extensions to the system, to build specific components that the core system does not yet contemplate, and to adapt certain aspects to the needs of their product.
What they cannot do is simply bypass the system. If they need something different, there is a process to ask for it, justify it, and, if it makes sense, get it into the central system so everyone benefits.
That balance between centralization and autonomy is what makes the system useful for the product teams and manageable for the core team. Too much centralization and the system becomes a bottleneck. Too much autonomy and the system fragments into weeks.
Why this matters especially in banking and insurance
In highly regulated industries, design consistency is not just an aesthetic issue. It has implications for user trust and regulatory compliance.
An inconsistent onboarding flow in a banking app not only confuses the user — it can raise doubts about whether they are in the right place, whether the operation is secure, or whether the entity is trustworthy. In a context where digital fraud is an everyday reality, these doubts have consequences.
A well-governed design system ensures that consistency exists across all bank products, regardless of which team built them. And it ensures that when changes have to be made due to regulatory requirements — a new privacy notice, a new consent flow — that change is applied in a coordinated way everywhere it is necessary.
What we have learned
We have been building and maintaining design systems for large organizations for years. The most important lesson is not technical — it is organizational.
The design system that generates the most value is not the most complete, nor the most sophisticated, nor the most beautiful in Figma. It is the one that the organization actually uses. And the organization only uses the system that it understands, that it trusts, and that evolves with its needs without becoming obsolete or breaking every time someone proposes a change.
For that to happen, governance is needed. And for governance to work, someone in the organization needs to take it seriously from the beginning — not as a bureaucratic process, but as the infrastructure that makes it possible to design at scale.
