The design system that made things worse.

A pattern that plays out in large organisations with uncomfortable regularity. The system exists. The adoption doesn't. And eighteen months of platform investment has somehow produced less consistency than the team had before.

Picture the situation. It will be familiar.

A mid-size product organisation inside a large financial services group. Four product teams. Somewhere between twenty and thirty designers depending on how you count contractors. Two years ago, the design leadership made the case for a design system. The business approved the investment. A platform team was assembled — three designers, a front-end engineer — and the work began.

Eighteen months later, the system has a component library with solid coverage, a Figma workspace that is genuinely well-organised, and documentation that would not embarrass anyone. It has also, somehow, produced a product estate that is measurably less consistent than it was before the system existed.

Three of the four product teams are using the system selectively. One has forked it. Two are maintaining parallel local component sets for the things the system 'doesn't quite cover'. The platform team is backlogged responding to requests that are each individually reasonable and collectively irresolvable. And the design leader is having a conversation they did not anticipate having — explaining to the product director why the thing that was supposed to reduce inconsistency has produced more of it.

This is not a story about a badly built design system. The components are good. The documentation is thorough. The tooling decisions were reasonable.

It is a story about a design system that was built without governance. And without governance, even a well-built system degrades — predictably, structurally, and fast.

Why governance is always the last thing anyone thinks about

Design system projects in large organisations almost always begin as craft problems. The design estate is inconsistent. Components are being recreated from scratch across product teams. There is no shared language between design and engineering. The case for a system is made in terms of quality, efficiency, and delivery speed — and it is a sound case.

The investment gets approved. The platform team gets stood up. And the work begins on the thing that feels most like progress: building components.

Governance — the question of how the system will be owned, maintained, contributed to, adopted, and enforced over time — is treated as something to figure out later. After the library is built. After adoption has started. After there is something real to govern.

By the time later arrives, the patterns that will eventually require governance are already established. Product teams have developed workarounds. Local component forks exist. The platform team has implicit norms that were never made explicit. Changing any of it now requires dismantling things that people have built their workflows around.

A design system without governance is not infrastructure. It is technical debt with better naming conventions.

The organisations that build design systems that actually work — that genuinely reduce inconsistency and delivery cost over time — are the ones that treat governance as a design problem from day one, not an operational afterthought once the library is live.

What governance actually means in practice

Governance is not bureaucracy. It is not a committee that approves component additions. It is not a lengthy review process that slows down product teams. Those are the pathologies of governance done badly.

Governance done well is a set of explicit answers to the questions that will otherwise be answered implicitly — and inconsistently — by different people making different decisions under different pressures.

Who owns the system? Not in an honorary sense, but operationally — who has the authority and accountability to make decisions about what goes in, what comes out, and what the standards are? In many organisations this is genuinely unclear, which means nobody has it, which means nobody enforces it.

How does contribution work? When a product team needs something the system doesn't have, what is the path? Build locally and never contribute back? Raise a request and wait six weeks? There needs to be a defined contribution model, or the system will permanently lag behind the needs of the teams supposed to be using it.

What is the adoption expectation? Is using the system mandatory, strongly encouraged, or optional? In most organisations this is never stated explicitly, which means each product team interprets it differently. And the teams that interpret it as optional — usually the ones under the most delivery pressure — are the ones that fork first.

How is the system measured? Not in terms of component count or Figma coverage, but in terms of actual adoption rate, contribution velocity, and whether using the system is reducing or adding to the cost of design and development decisions. If nobody is measuring this, nobody can tell whether the system is working.

The fork problem

A forked design system is a governance failure that has become visible. By the time a product team is maintaining a parallel component set, they have already made a series of smaller decisions — to deviate from a component, to extend it locally, to not raise a contribution request — that were each individually understandable and collectively catastrophic.

The fork is not the problem. The fork is the symptom. The problem is that the conditions under which forking made sense were never addressed — the system moved too slowly, the contribution process was too unclear, the adoption expectation was never enforced.

Reversing a fork once it is established is significantly harder than preventing it. It requires the product team to accept rework, the platform team to acknowledge the gap their system failed to fill, and both sides to agree on a path that serves neither of their immediate interests particularly well.

Most organisations do not reverse forks. They manage the divergence, add it to the list of known inconsistencies, and carry the maintenance cost indefinitely.

The audit before the rebuild

When design system initiatives stall or degrade in large organisations, the instinct is usually to rebuild. New tooling. New component architecture. A fresh start with lessons learned.

The rebuild rarely fixes the underlying problem, because the underlying problem is almost never the components. It is the ownership model, the contribution process, the adoption expectation, and the measurement framework — the governance layer that the original investment never properly addressed.

Before any design system initiative is restructured or rebuilt, the right first step is an honest diagnostic of the governance reality: how decisions are actually being made, who is actually accountable for what, where adoption is failing and why, and what the system is actually costing the organisation to maintain versus what it is saving.

That diagnostic is unglamorous work. It requires conversations that are uncomfortable, documentation of things that have never been written down, and conclusions that reflect poorly on decisions that were made with good intentions.

It is also the only path to a design system that works over time rather than just on the day it launches.

There is a structured framework for doing this work — for auditing governance health, diagnosing adoption failure, and building the ownership model that makes a system sustainable rather than just functional. It is the kind of rigour that turns a design system from a platform team's responsibility into an organisational capability.

And it is work that most organisations skip entirely. Which is precisely why the pattern at the beginning of this article plays out as often as it does.

→  A governance-first framework for design systems that work in enterprise organisations — not just on launch day.

Playbook 05: Design Systems — available July 2026  ·  culwickstudio.com