In a large company, frontend work repeats itself with almost comic timing. One team builds a date picker. Another builds a more accessible one. A third has a use case nobody saw coming and solves it in a week, in a way that will work beautifully until the first round of maintenance. Then a rebrand lands, or an accessibility rule changes, and someone discovers that this small detail exists in twenty-seven versions.

That is not laziness. It is what growth looks like: different products, local priorities, changing technology, people joining and leaving. For a while, it works. Each product moves at its own pace and the cost of difference stays hidden in small delays, manual fixes, and conversations that begin again from scratch.

The problem becomes visible when changing a simple rule turns into an expedition. An error message, a keyboard behaviour, a spacing scale: the change is trivial in code. Carrying it across every product is not.

That is when frontend changes its nature. It stops being only the place where screens are built. It becomes an internal platform, used by product teams, with one clear promise: make the decisions worth taking once cheaper to take together.

A design system is necessary, but it is not enough

A design system is usually the first visible part of that shift: components, guidelines, design-tool libraries, documentation. It matters. A dependable catalogue keeps every team from starting with the button and leaves more attention for harder problems.

Reducing the whole thing to that catalogue, though, creates an expensive misunderstanding. Components are the result of decisions someone has already made: what contrast is acceptable, which states an input needs, when an action is destructive, how an interface explains an error. Design tokens have made that idea more concrete and more portable between tools. Their first stable specification describes them as a way of expressing design decisions independently of technology.1

Useful step. Not an organisational solution. A token file can carry a colour from a design tool into web code; it cannot decide who assesses an exception, who funds a migration, or how long compatibility should remain in place. The file does not attend the meeting. Thankfully.

Without those agreements, two understandable reactions appear. A central team tries to control everything and becomes the company’s most polite bottleneck. Product teams route around the system because waiting costs more than duplicating. The library then fills up with variants: some official, some preserved in repositories like rare plants.

A platform reduces the cost of coordination

Maturity is not perfect uniformity. A payment product, a support portal, and an admin console can share many rules without looking like the same application wearing three different logos. The consistency that matters is what customers experience as dependable behaviour: readability, accessibility, language, predictable actions.

Everything else deserves more care. A healthy platform separates at least three kinds of decisions.

Rules about security, accessibility, basic identity, and code quality should be shared and hard to bypass. Not because the group maintaining them is always right, but because renegotiating them from zero on every project wastes time and has real consequences for people using the product.

Recurring solutions should be offered as fast paths: well-documented components, working examples, tools that steer people toward the right answer without requiring a course in corporate archaeology. The experience of the team consuming the platform matters here. If adoption takes more energy than starting from scratch, the roadmap can be immaculate and uptake will remain a polite intention.

Then there are exceptions. There always are. An adult system does not pretend they are moral failures. It makes them visible, evaluates them against clear criteria, and keeps their rationale. Some remain local. Others reveal a gap in the system and deserve to become common capability.

This avoids two kinds of organisational childishness: the belief that everything must be standardised, and the opposite belief that every difference is inevitably special. Both postpone a decision.

The platform also ships rules for how it changes

A good design system has more than a catalogue. It has a front door.

Someone using a component needs a way to say it is not enough, explain the use case, know who decides, and receive an answer in reasonable time. Carbon, IBM’s design system, publishes a proposal and triage path for requests from its community of users.2 The interesting detail is not the form itself. It is the acknowledgement that a platform lives in friction with products, not safely away from them.

Changes need a grammar too. A breaking change is not just a release note; it is work someone else will have to pay for. The mature question is not whether to avoid every break, an ambition that eventually freezes everything. It is how to announce it, which migration to offer, how much time teams get, and when to check that the old path has actually disappeared.

That is governance, an unglamorous word for something concrete: knowing how to change your mind without handing the cost to whoever discovers the news in a pull request.

Workday’s account of its own system makes the same point. Evolution stops being the sole territory of the group that maintains the library and is also guided by the needs of the designers and developers using it.3 That is not direct democracy, thankfully. It is distributed responsibility with a recognisable decision point.

Three questions that matter more than a component count

When a company assesses its frontend practice, asking how many components are in the library produces easy numbers and poor answers. I prefer three less elegant questions.

Can a new team get moving quickly? This does not mean it must use the whole system. It means that for ordinary cases it finds a ready path, understands which rules are binding, and knows where to ask for help without already knowing the right people.

Does a shared change reach the end? When a rule changes, can you see which products use it, which migration path exists, and where exceptions remain open? Without that visibility, the platform distributes code rather than responsibility.

Does an exception improve the system, or remain a footnote? Every exception should leave a trace: why it exists, for how long, and what it would teach if it happened again. A frequent exception is not disobedience. It is user research that has found a way to make itself heard.

None of these questions is answered by buying a tool. Tools are necessary, and much more mature than they were a few years ago. The difficult work is still deciding what to centralise, who may diverge, and how the cost of change is shared. It is the least photogenic work a platform does.

In my work, that means holding together two instincts that often quarrel: building robust common ground and leaving products enough room that every exception does not become a permission request. The balance does not arrive once and for all. It is corrected by watching the real work, the part that happens after the demo and before anyone feels like updating a dependency.

Well-governed frontend does not make every product identical. It makes it less expensive for products to evolve together, when evolving together is the sensible thing to do. In a large company, that is already a considerable achievement.

Footnotes

  1. Design Tokens Community Group, Design Tokens Format Module 2025.10, 2025. The specification describes a technical format, not a governance model. ↩

  2. Carbon Design System, Getting started: design contributions, accessed 1 August 2026. ↩

  3. Workday, Productizing your design system, accessed 1 August 2026. This is an experience report, not comparative research. ↩