Scaling the System: Productising Design

In an Enterprise setting like ours, with the demands of a Live Broadcast environment, scale and consistency are non-negotiable. Every second of performance counts, and every pixel must be intentional; any design debt is a high-stakes risk. A fully integrated design system is not a luxury; it is a strategic necessity for maintaining quality and speed.

However, the real product challenge is not the initial build; it is getting the system used and governing its evolution across dozens of product teams. This requires a shift in mindset: the design system itself must be treated as a product.

Making the System an Asset, Not a Tax

The design system fails the moment engineers perceive it as extra work or a creative constraint without clear payback. Our priority, therefore, became developer adoption, transforming the proposition from “look at these beautiful components” to “here is the component library that cuts your build time in half.”

The key step was frictionless integration. We needed to meet our engineers where they already worked. We treated the system as a primary dependency, distributing all components, tokens, and assets via our private NPM registry for immediate, tool-ready consumption. The documentation must also be written in the engineer’s language, offering clear code snippets, examples, and versioning. The value proposition is time and predictability; that is the only metric most engineers care about in this context.

We measure success not just by design adherence, but by consumption: how many projects reference the system, and what is the weekly reduction in newly logged UI-specific bugs?

Strategic Governance: Centralised Clarity, Federated Input

The biggest strategic risk is the design system becoming a rigid, unmaintained relic that product teams route around. Governance is how we manage its evolution. We settled on a centralised core, federated contribution model.

A small, dedicated team—the ‘core’—is essential. This team owns the repository, defines the core principles, manages major releases, and is responsible for the system’s overall health and documentation. Their mandate is not to police, but to enable.

Crucially, we empower feature teams—the ‘federated’ arm—to contribute back to the system. If a team develops a new pattern or component that solves a genuine, shared business problem, it goes through an agreed-upon analysis and approval cycle to be absorbed into the core. This structure keeps the system dynamic and fosters ownership across the entire product and engineering organisation.

I find that strategic constraint often fuels better output. The discipline of a self-imposed constraint, applied to any creative process, can sharpen focus on core efficiency. The design system works the same way; its constraints on typography, spacing, and colour force designers and engineers towards better, more efficient solutions for the user, rather than allowing for endless, costly variations.

The Design System as a Product Roadmap

Ultimately, a Design System is a product that serves other products. It requires a dedicated Product Leader’s mindset: defining the user (the engineer, the designer, the product owner), managing a feature roadmap, and constantly measuring its success. Governance is not about saying “no” to new ideas; it is about strategically managing the evolution of the single, authoritative source of truth to ensure we can build at scale, without sacrificing quality or performance. The immediate goal is to make it impossible to build without it.