Scalable design systems: lessons from 10 years of product.

Why design systems fail (and why they sometimes fail when they succeed).

There’s a scene I’ve seen repeat itself in almost every company I’ve worked at. A product team has a deadline, the system component doesn’t quite fit what they need, and someone says: “we’ll do a custom one this time, we’ll align it later.” That “later” never arrives. Six months on, there are fourteen button variants in production, the system has 60% coverage on paper, and the team maintaining it discovers that users are actually seeing something else.

Most design systems don’t fail for lack of components, but for lack of governance, purpose and alignment with the business. Across more than a decade building digital products, I’ve watched systems born with enthusiasm, well documented, visually consistent, lose relevance within eighteen months.

A design system isn’t a library. It’s living infrastructure.

But there’s a second kind of failure nobody talks about much: the system that does get adopted, but does so thoroughly enough to homogenise products that needed their own voice. When everything looks the same, the system has stopped serving the product and started serving itself. Uniformity isn’t the goal; intentional coherence is.

The adoption problem.

A design system only has value if it gets used. And for it to get used, it has to integrate naturally into the workflow of designers and developers. It can’t be an extra layer of friction, or a source of rigid rules that slow people down.

Teams adopt systems that save them real time, reduce ambiguity in decisions, make design-development collaboration easier, and integrate with their existing tools (code, repositories, pipelines). When that doesn’t happen, the system feels like an imposition, not a help. And here’s the honest test: if the system disappeared tomorrow, would teams miss it or breathe a sigh of relief?

Start with the problem, not with the solution.

One of the most common mistakes is building components before understanding the problem. I’ve done it myself on systems that ended up fully redrawn two years later.

An effective design system is born from observing UI inconsistencies that create friction, scalability problems in the code, constant rework between teams, and lack of clarity in interaction patterns. Without this diagnosis, the system will be aesthetic but not functional. And an aesthetic system nobody uses is more expensive to maintain than having no system at all.

Beyond design: systems as product.

A design system has to be managed as a product in its own right. That means having clear objectives (adoption, efficiency, consistency), measuring impact, prioritising evolution based on real usage, and actively listening to internal users. It’s not a deliverable. It’s a continuous service.

Metrics that actually matter.

The classic metrics people recommend are useful but misleading. “Percentage of components used vs. existing” rewards pruning the system, not growing it: you improve the number by deleting legitimate components that serve real cases. These are the indicators that, in my experience, better reflect the health of the system:

Coverage weighted by traffic. It’s not the same that 80% of components are used as that 80% of traffic passes through system components. The second measures real impact on users; the first measures team effort. In products with extreme Pareto distributions (where 5% of screens get 90% of traffic), these two metrics can differ by more than thirty points.

Time-to-first-component. How long it takes a new team member (designer or developer) to use the system productively. It’s a direct indicator of documentation, discoverability and onboarding friction. If it’s more than a week, the system has a problem.

Divergence rate. How many custom components get built outside the system, per quarter. It’s not a metric to punish teams; it’s an early signal that something isn’t covering real needs and that the system’s roadmap is out of date. A healthy system has low but non-zero divergence: if it’s zero, teams are probably self-censoring.

Accumulated design debt. Number of screens in production built with obsolete versions of the system, or that never migrated. It’s the least visible and most dangerous metric: it grows silently and explodes at the next refoundation.

Incoming contributions. Not just how many, but from how many different teams. A system with ten contributions a quarter from the same team is dead; one with ten contributions from eight different teams is alive.

Accessibility incidents. Under the current European regulatory framework, this metric moves from nice-to-have to legal risk indicator. We’ll come back to this.

Without metrics like these, the system evolves by intuition, not by evidence. And without evidence, decisions get made by whoever shouts loudest in the meeting.

Governance: the critical factor.

Governance is what separates a sustainable system from one that collapses. It’s not about centralised control, but about the balance between autonomy and coherence.

Governance models.

There are several known approaches: centralised (a core team controls everything: more consistency, less scalability), federated (teams contribute under clear rules: more flexible, requires discipline) and hybrid (stable core plus extensions by domain, the most common in complex products).

The key isn’t the model, but clarity on who decides, how people contribute, how things get validated and how change gets communicated.

What nobody talks about: the funding model.

In my experience, the factor that most determines the sustainability of a design system isn’t its governance model, but its funding model. It’s the most uncomfortable conversation and the most decisive one.

A system funded by a single product will always end up serving that product and neglecting the rest. When the funding product enters a roadmap crisis, the system will freeze with it. A system funded by “voluntary spare time from all teams” has no owner: everyone contributes when they can, nobody is accountable, quality drops and commitments quietly break.

The systems that survive have their own budget, a dedicated team with its own OKRs, and accountability to multiple stakeholders. Treating the system as a product also means treating it as an explicit cost (or value) centre in the organisation. If nobody signs the cheque, nobody signs the outcome.

Minimum necessary processes.

A mature system defines a clear contribution flow (proposal, validation, implementation), explicit versioning (breaking changes, releases), living documentation and feedback channels. Without this, the system fragments quickly.

One mechanism that has proven to work particularly well in federated systems is the RFC (Request for Comments): short written proposals, asynchronous public review, documented decision. It’s a lightweight process that does three things at once:

Forces the proposer to think before building.
Gives voice to teams who aren’t in the meeting but will be affected.
Leaves a historical trail of the why behind each decision, invaluable when someone asks two years later “why did we do this this way?”.

The RFC isn’t bureaucracy. It’s institutional memory.

Principles that work.

After multiple iterations, these principles have proven effective.

1. Documentation alongside code.

Separating design and development creates inconsistencies. Documentation has to live where the code lives: Storybook or equivalent, real usage examples, edge cases documented. This reduces ambiguity and speeds up adoption. And, increasingly, it’s the source of truth that feeds the AI agents that generate UI: if your documentation is out of sync with your code, your AI generates obsolete screens.

2. Semantic tokens from the start, in three layers.

The classic mistake is designing with absolute values (#FF5733, 16px). The next level is designing with semantics (color-primary, spacing-md). But in 2026 the mature standard is a three-layer architecture:

Primitive tokens. The raw vocabulary: blue-500, size-16, font-weight-600. They have no product meaning; they’re the raw palette.

Semantic tokens. Meaning in context: color-action-primary, spacing-stack-md, font-weight-emphasis. This is where design starts making decisions.

Component tokens. Specific application: button-primary-background-hover, input-error-border. They allow fine-tuning without touching semantics.

This separation is what lets the system survive the third brand, the first enterprise client asking for white-label, dark mode, the high-contrast mode required by accessibility, and the next round of rebranding. Without it, any systemic change forces you to touch every component, and that doesn’t scale.

3. Continuous evolution, not big launches.

Systems that wait for “the perfect version” never get adopted. Better to iterate fast, ship small versions and learn from real usage. A design system has to evolve at the pace of the product, not at the pace of an isolated roadmap.

4. Designing for dismantling.

This principle sounds counterintuitive, but it’s what separates a living system from a museum of past decisions. The best systems have a deprecation strategy from day one.

That means defining from the start:

How a component gets marked as obsolete (visually in the documentation, with console warnings, with linters in CI).
How long the old version coexists with the new one (at least one major cycle, ideally two).
How change gets communicated (changelogs, dedicated channels, migration sessions).
How migration happens (codemod scripts where possible, not asking the team to hand-do what can be automated).

A system that doesn’t know how to retire components accumulates weight until it becomes impossible to maintain. Ironically, the ability to say “no more of this” is what allows continued growth.

The design system as a compliance layer.

For years, accessibility and AI transparency were best practices. In Europe, since 2025 and with critical milestones in 2026, they no longer are: they’re legal obligations. This shift reconfigures what a design system is.

The European Accessibility Act (EAA).

Since 28 June 2025, digital services operating in the European Union within the scope of the EAA must comply with the technical standard EN 301 549, which incorporates WCAG 2.2 level AA. The scope is broad: e-commerce, electronic banking, transport, audiovisual media services, e-books, and in general any digital service offered to consumers in the EU. The law also applies to non-European companies operating or selling in the European market.

For a design system, this means every base component has to comply with concrete WCAG 2.2 criteria: minimum size of interactive targets, clearly visible focus indicators, alternatives to drag gestures, sufficient contrast, complete keyboard navigation, compatibility with assistive technologies. A system that doesn’t include these requirements by default isn’t protecting the product; it’s exposing it legally.

The EU AI Act.

The EU AI Act entered into force on 1 August 2024 and will be fully applicable from 2 August 2026. That date, a few months away, activates the most consequential obligations: technical documentation, human oversight, traceability, risk assessment for systems classified as high-risk, and transparency obligations for limited-risk systems.

For limited-risk systems (chatbots, content generators, deepfakes), the main obligation is transparency: users must know when they’re interacting with an AI. This is, directly, a design system responsibility: the visual and semantic pattern that signals “this was AI-generated” or “you’re talking to an automated assistant” has to exist, be consistent, and not be optional.

The system as compliance infrastructure.

The conceptual shift matters. For years we treated the design system as a layer of consistency and efficiency. Now it’s also the layer where compliance either materialises or gets lost.

A <Button> component without an accessible focus indicator multiplies non-compliance across every screen where it appears. An <AIResponse> component without a clear indicator that the content is generated replicates opacity across the whole product. A <FormField> component that doesn’t properly associate label with input turns every form in the product into a barrier for people using screen readers.

The practical conclusion is that accessibility and transparency rules can’t live in a separate guideline that teams are free to forget. They have to be codified in the system: as component defaults, as required props (<Image> without alt that fails the build), as CI linters, as automated tests that block merges if they fall below a threshold.

The design system is where ethics stops being a declaration and becomes executable code.

Design systems in the age of AI: from library to generative infrastructure.

The incorporation of AI is transforming what it means to design and build interfaces. But there’s a counterintuitive thesis I think is worth making explicit: AI isn’t going to replace design systems, it’s going to make them indispensable.

Plausible chaos.

When an AI system generates an interface without a solid design system underneath, the result is what I call plausible chaos: screens that look fine at first glance but, on a second look, have irregular contrasts, invented spacings, inconsistent hierarchies between equivalent views, and unpredictable behaviours. AI amplifies what it finds underneath. If the foundation is inconsistent, the output will be exponentially so.

Put another way: a mature design system is what allows generative UI to stop being an impressive demo and become reliable product. AI doesn’t invent components from scratch; it composes them from an existing library following constraints. The system defines the space of what’s possible.

From rigid components to flexible patterns.

Traditional design systems define static components. With AI, we need systems that contemplate interfaces dynamically assembled by context, content personalised in real time, and adaptive variations by user, intention or behaviour.

A concrete example: a travel app with generative UI detects that the user is at the boarding gate and reorders the screen. The “Book flight” button disappears; the boarding pass QR code moves to occupy the main area; a map to the nearest café appears. All built with the same system components, recombined by context. It’s not a redesign; it’s a rule-driven reassembly.

This requires moving from rigid components to flexible patterns, and that requires new formalisms in the system.

Component contracts.

Each system component stops exposing only visual props (variant, size, color) and starts exposing semantic intent as well: purpose="confirm-destructive-action", role="primary-navigation", urgency="critical". AI doesn’t decide what a “delete account” button looks like; it queries the system for which component is authorised to represent an irreversible destructive action, and gets back a response with visual, confirmation and accessibility constraints already integrated.

This contract concept is what lets AI be deterministic where it matters while being flexible on the surface.

Systemic guardrails.

The system defines rules that AI cannot violate, whatever happens. Minimum contrasts. Keyboard focus hierarchy. Brand language and tone. Mandatory presence of “AI-generated” labels on any non-curated content. Limits on how many interactive elements can appear in a single view. These aren’t suggestions: they’re system invariants, validated at render time.

These guardrails are, in practice, how the design system protects the product from the unpredictable behaviour of generative models. Without them, every call to the model is a roulette wheel.

Conversational state machines.

For products with agents or conversational interfaces, the design system gains a new responsibility: defining the valid states of the conversation. Thinking, responding, waiting for user confirmation, error from detected hallucination, escalating to human, token limit reached, source cited, source unverifiable. Each state needs its visual representation, its microcopy, its keyboard behaviour, its accessibility.

Just as the system used to define button states (default, hover, active, disabled, loading), it now defines the states of a conversation with an AI. The complexity is higher, but the nature of the problem is the same: components with clear states and valid transitions.

New system artifacts.

Alongside visual components and tokens, a set of artifacts that didn’t exist before starts to form part of the system:

Structured prompts with typed variables, versioned and tested like code.
Tone and language guidelines operationalised as rules the AI queries, not as a PDF nobody reads.
Content generation rules: what the AI can generate, what needs human review, what should never be generated.
Confidence and provenance indicators: components that show where each piece of generated information comes from, whether it was verified, when it was generated.

The system stops being only visual and becomes cognitive. That doesn’t mean it writes itself; it means it now also governs how the product thinks.

Dimensions the system can’t ignore.

Beyond components and tokens, there are five dimensions that, if they don’t live in the system from the start, end up being paid for dearly.

Content as part of the system.

Tone of voice, microcopy, error messages, confirmations. They’re as much part of the system as colours. A system that solves the visual part but lets each team write their own error messages produces visually consistent and linguistically chaotic products. In AI-powered products this is even more critical: the model needs voice guidelines as explicit as the component needs tokens.

Internationalisation from design, not as an added layer.

Pluralisation, directionality (RTL for Arabic or Hebrew), variable lengths (German expands around 30% over English), typefaces by script, date, number and currency formats. A system that didn’t think about this from the start breaks in the first market that demands it, and the rewrite costs several times what doing it right from the beginning would have cost.

Performance as a design constraint.

Bundle budget, component tree-shaking, lazy loading for rarely used variants, SSR/CSR strategies. In 2026, with Core Web Vitals consolidated as a competitive factor and mid-range device experience being the global norm, the system is also responsible for the performance the product inherits. A “pretty” 80KB component is worse than an “ugly” 8KB one on a mid-range phone on a 3G connection, which is the everyday reality for hundreds of millions of users.

Automated testing as a condition of existence.

Visual regression tests (Chromatic, Percy or equivalents), automated accessibility tests (axe-core integrated in CI), verifiable component contracts. Without automation, “living documentation” is a wish and “accessibility by default” a good intention. A change that lowers the contrast of a primary token should fail the build, not reach production and get discovered three months later when a user complains.

Multi-brand and multi-product.

The most interesting long-term challenge is architecting a system that serves several products or brands without becoming the aesthetic lowest common denominator. The solution isn’t “one system per brand”, which multiplies effort. It’s a shared core (primitives, behaviours, accessibility, logic) with interchangeable brand layers (semantic and component tokens). Well designed, adding a new brand means changing a layer of tokens, not rewriting components.

Ethics and responsibility: from declaration to component requirement.

When systems scale, so do their impacts. A design system can amplify good practices or bad decisions. The difference between an ethical system and one that isn’t lies not in the guideline it publishes, but in what it enables or prevents its components from doing.

Four concrete risks, not abstract ones.

Systematised dark patterns. The most common case today is consent banners where “Accept all” is a prominent primary button and “Reject all” is hidden as a tertiary link. If the system defines button-primary and button-tertiary with that visual asymmetry, and lets each team decide which to use, the system is complicit in the dark pattern that gets reproduced thousands of times a day. The same applies to friction asymmetry: signing up in one click, cancelling the subscription in seven.

Bias in AI-generated content. If the system allows an autocomplete or content-generation component to be used without review mechanisms or labelling, the model’s biases propagate silently across the whole product. The system has to offer, by default, a wrapper that makes the content’s origin visible and makes it easy for the user to correct.

Lack of accessibility in base components. A <Modal> component that traps focus but doesn’t release it on close, a <Dropdown> that can’t be operated by keyboard, a <DataTable> that doesn’t announce changes to screen readers. Each of these defects, multiplied by the number of screens where the component appears, is a barrier at scale and, since 2025 in Europe, also legal exposure.

Opaque automated decisions. Components that display “You don’t qualify for this service” or “Your request has been denied” without explanation, without a review path or human contact. Under the AI Act, in high-risk systems, deployers are obliged to allow human oversight and provide appropriate levels of accuracy, robustness and traceability. A system component that represents an automated decision without mandatory slots for explanation and appeal is, literally, coding non-compliance.

Ethics as a structural requirement.

The operational proposal is clear: ethics is not an additional layer, it’s a set of verifiable component requirements. In practice, this translates into things as concrete as:

A system linter that fails if a cancellation flow uses button-tertiary for “cancel” and button-primary for “keep”.
Mandatory props on sensitive components: <AutomatedDecision> can’t render without reason, reviewChannel and humanContact.
Accessibility tests that fail the build below a severity threshold.
Defaults that protect: <AIGenerated> includes the visible indicator by default, and removing it requires an explicit flag (reviewable in code review).
Periodic dark pattern audits on the most used product flows.

Turning ethics into lint rules is more effective than writing a guideline nobody reads. And in the European regulatory context, it’s no longer optional: it’s the only realistic way to scale compliance.

Conclusion: the question that remains open.

A design system isn’t a collection of components. It’s a strategic tool that connects design, technology, business and user experience. But in 2026, with the EAA in force, the AI Act activating, and generative UI moving from demo to product, the system’s role is more critical than ever.

The system is no longer just the layer that makes products consistent and efficient. It’s:

The infrastructure where regulatory compliance gets codified.
The foundation that enables (or prevents) reliable generative UI.
The place where ethics stops being intention and becomes a technical invariant.
The institutional memory of decisions that, otherwise, would get repeated every two years.

Its success no longer depends on how complete it is, but on what problems it solves, how easy it is to use, how it evolves with the product and, increasingly, how responsible it is in its systemic impact.

The question I leave you with, if you lead or work on a digital product today, isn’t whether your system is well documented or well tokenised. It’s this: is your design system ready to be the layer where your legal obligations get met, where your next generation of AI is anchored, and where your ethical principles become inviolable by default?

If the honest answer is no, the problem isn’t aesthetic. It’s structural. And the cost of fixing it grows every month that passes.

Building a scalable design system means designing not just interfaces, but decision systems. And that, in essence, is product design done with responsibility.