Building a design system at scale

The hardest part of a design system is not building it. It is convincing an organization that it needs one before the cost of not having one becomes obvious.

At a large university, that cost was already visible by the time I arrived. Dozens of sites were built independently, each with its own interpretation of the brand. Not because teams were careless, most were doing exactly what they had been asked to do, but because there was no shared foundation. No tokens. No components. No contract between what design decided and what engineering shipped. Every site was a bespoke negotiation between whoever happened to be in the room.

The symptoms were predictable. Designers could not trust that their work would survive contact with implementation. Developers rebuilt the same patterns repeatedly without realizing parallel versions already existed. Brand governance was aspirational. Every new site started from zero, and inherited every previous mistake.

The technical problems were straightforward. The organizational ones were not.

Building the token pipeline was the right first move, not because tokens are architecturally novel, but because they make design decisions legible to engineers without requiring a meeting. A color stops being "the blue for primary actions" and becomes a named value with a defined role that can propagate from Figma into downstream applications.

That single change, formalizing what had previously been undocumented convention, reduced misinterpretation more than any individual component I shipped.

Component architecture followed the token model. Primitives consumed tokens. Base components composed primitives. Editorial components in the CMS composed base components. Each layer held a stable contract with the one below it. That stability mattered because it let components evolve independently without forcing synchronized migrations across multiple teams.

The federated distribution layer is where organizational complexity became a technical problem. Not every team used React. Not every site lived in the monorepo. Vendor-built sites, legacy stacks, and standalone projects still needed system components without adopting the full internal architecture.

Web components and NPM distribution solved access. They did not solve governance. A component consumed outside your control is a component you cannot confidently update.

That tension, between making the system accessible and keeping it coherent, is the central design-system problem at institutional scale. The farther a component travels from the monorepo, the harder it is to know which version is running, whether it is used correctly, and what breaks when you change behavior. Federated consumption expands capability, but it also creates a maintenance surface you cannot fully see.

Documentation compounds the same issue. A Storybook that accurately reflects component behavior is not a one-time deliverable. It is an ongoing investment. Props drift, edge cases accumulate, and real usage patterns emerge in production that no workbench scenario predicted.

The gap between documented behavior and actual behavior widens quietly, and it widens fastest in the components that get used most.

What became clear is where design systems usually fail. Not in token architecture. Not in component layering. They fail at the boundary between the system and the organization: in assumptions about consumption, in governance models that do not scale with adoption, and in documentation that stops being true before anyone notices.

A design system is not a deliverable. It is an ongoing negotiation between what an organization wants to keep consistent and what it is actually willing to maintain.