Surviving Day Zero: The Operating Model for Enterprise Design Systems

Building components is the easy part. Building an organization capable of keeping a design system useful is something else entirely.

It has never been easier to build a design system.

We have Figma, tokens, component libraries, Storybook, mature front-end frameworks, accessibility tooling, and better documentation platforms. Given enough time and competent people, most organizations can audit existing products, establish foundations, build reusable components, document them, and connect design to code.

Then they launch it.

That is where the harder work begins.

Figma is not the design system. Neither is Storybook, React, Sitecore, AEM, a documentation site, a brand guide, or a collection of design tokens. Those are implementations of the system.

The actual design system has to exist between them. More importantly, it has to exist between the people responsible for design, engineering, product, accessibility, procurement, vendors, and the business itself.

A component library can live in Figma. A design system has to live in the organization.

Launch Is Day Zero

The first phase is familiar: audit products, establish foundations, define tokens, create components, document patterns, align design and engineering, test accessibility, and release the libraries.

This work matters, but it still behaves like a project. There is a scope, a roadmap, a set of deliverables, and eventually everyone agrees to call it launch.

A functioning design system cannot operate that way.

zeroheight’s 2026 Design Systems Report shows the gap. Of the 147 practitioners surveyed, only 7% described their system as fully adopted across all teams, while another 31% reported wide adoption. Satisfaction with organizational buy-in fell to 32%, and adoption and awareness remained the leading challenge for the fifth consecutive year.

Building the components is no longer the hard part. The real question is whether the organization can use them consistently, maintain them, change them safely, and keep funding the work that keeps them useful.

Answering yes requires an organization around the design system. It does not have to be a new department, but it does need the properties that allow any internal product to survive: ownership, funding, governance, enablement, and a roadmap.

Without those things, the design system may have been delivered. It has not been established.

The Design System Is an Internal Product

At a multi-brand global company, I first worked on the design system as a consultant and was later brought onto the in-house team. Across both roles, we treated the design system as its own product.

It had product and project management. Designers and engineers worked on it. Architects participated in decisions. Accessibility was built into the process. We conducted research with the people using the system, because designers, developers, product teams, and other internal groups were its users.

When teams could not find a component, misunderstood one, worked around it, or discovered that something clean in Figma became painful in production, we treated that as product feedback rather than a training problem.

We also built scorecards for different parts of the organization to understand who was adopting the system, how it was being implemented, where teams were struggling, and where the system itself needed improvement.

Scorecards change the question. Instead of asking:

“Why isn’t this team following the design system?”

Ask:

“What is stopping the design system from working for this team?”

Sometimes the answer is poor documentation. Sometimes it is missing functionality, a legacy stack, slow governance, weak vendor onboarding, or a component that simply does not fit the problem.

Measurement should help find that answer, not become a compliance scoreboard.

The operating model looks less like a library and more like a network.

The system supports the organization, and the organization supports the system.

Governance Is Controlled Evolution

We ran a design-system governance committee every other week. Designers, architects, engineers, product and project managers, and other stakeholders participated depending on what was being considered.

Its job was to evaluate change before every local problem turned into another local component.

A product team might need something the system did not support. Accessibility might expose a defect. Engineering might discover that an interaction was expensive or fragile to maintain. Another team might propose a pattern that could benefit ten products instead of one.

Governance gave those decisions a place to go.

Centralized governance has a limit, though. A committee that works with ten teams becomes a bottleneck with one hundred. If every change waits on the same group of people, governance eventually creates the very behavior it is supposed to prevent: teams route around it.

We hit that limit ourselves. As adoption grew, the committee that had given decisions a place to go became the place they waited. The model below is the answer to that growth problem.

Central Rules. Federated Decisions.

At scale, governance has to become federated.

The central design-system team should own decisions that genuinely require enterprise consistency: foundations, tokens, core components, accessibility requirements, contribution and documentation standards, release architecture, and breaking changes.

Domain and product teams should be able to make lower-risk decisions inside those boundaries without waiting for central approval. Making that work requires an operating mechanism.

Major product domains can have designated design and engineering stewards. Those stewards use the same contribution checklist, acceptance criteria, accessibility requirements, and documentation standards as the central team. Low-risk changes stay local. Changes affecting shared components, foundations, multiple domains, or significant technical risk escalate.

The workflow can be enforced through the systems already used to deliver software: CODEOWNERS, pull-request templates, Jira workflows, automated accessibility checks, visual regression tests, and documented decision thresholds. The specific tooling matters less than the clarity of the operating rules: who can decide what, what evidence is required, and when escalation is mandatory.

Governance also needs service expectations. If a shared-component review routinely takes three weeks, the organization has created an incentive to bypass the system. Response and decision times should be visible like any other operational metric.

As adoption grows, governance should become more distributed. The guardrails stay; they move to the level where each decision is actually made.

Good governance does not protect the design system from the organization. It allows the organization to change the system without destroying it.

Adoption Is a Behavior Problem

People do not use a design system because somebody published a policy saying they should.

They use it because it helps them get work done.

If requesting a component takes six weeks while building one locally takes two days, the team will build locally. If documentation is unreliable, people stop trusting it. If the Figma component behaves differently from the production component, designers detach it. If every exception requires several meetings, people stop asking.

Every one of those responses is rational.

The same problem appears with vendors and new teams. If they are handed a documentation link and expected to understand a mature enterprise system on their own, they fill the gaps with whatever practices they already know.

The zeroheight data points the same way. Among teams whose systems are poorly adopted, the most-cited reasons were lack of a company mandate (73%), weak governance (55%), and incomplete components (45%). Yet teams with strong adoption credited component completeness (79%) and communication and community (59%) ahead of a mandate (55%).

Mandates matter, but mandates alone do not create adoption. The governed path has to be easier than the workaround.

Build Capability Into the System

Training and office hours help, but they do not scale as the primary adoption model. A central team cannot pair with every designer and engineer across dozens or hundreds of squads. If adoption depends on white-glove support, the design-system team becomes the bottleneck.

Enablement has to be designed into the system: a repeatable path from
New Team → Competent User → Local Stewardship
that does not require continuous central-team intervention.

A scalable model combines several mechanisms:

• self-service onboarding tied to real delivery tasks rather than generic documentation;
• domain stewards who provide peer-to-peer guidance close to the work;
• templates, starter repositories, CLI scaffolding, or equivalent tooling that creates compliant implementations by default;
• automated checks for tokens, accessibility, component usage, and visual regressions;
• contribution workflows embedded directly into pull requests and delivery tooling;
• short, targeted coaching when telemetry shows a team repeatedly struggling with the same issue.

The aim is to make correct use of the default path, catch failure early, and build enough capability inside product teams that most decisions no longer need the central team. Nobody has to learn everything about the system for that to work.

You can mandate compliance.

You cannot mandate trust.

Legacy Products Are Where Adoption Gets Expensive

Enterprise design systems rarely arrive on clean ground.

They arrive after years of product development: multiple frameworks, acquired companies, abandoned libraries, inaccessible components, and applications nobody wants to touch because they still generate revenue.

Publishing a new design system does not make any of that disappear. Migrating everything at once is usually just as unrealistic. Legacy migration needs its own strategy, funding, and visibility.

Start with risk and opportunity. High-traffic products, accessibility problems, frequently modified areas, high-maintenance components, and products already scheduled for significant work are often better migration candidates than stable applications nobody plans to touch for another three years.

Migration can also happen through normal product change. When a team substantially modifies a legacy area, that work becomes an opportunity to move the affected surface onto the current system instead of adding another layer of legacy code.

Some applications may never justify complete migration, and that can be a legitimate business decision.

What matters is knowing which state each product is in:

Without that visibility, an adoption percentage can mislead. A team maintaining a fifteen-year-old application and a team building a new product should not be judged as though they face the same problem.

Vendors Are Part of the Design System

Large organizations rarely build everything internally, so governance cannot stop at the employee directory.

If an agency or development partner can deliver a product without understanding the design system, the organization has created a sanctioned path around its own standards.

Procurement, legal, and vendor management therefore become part of the operating model. Where appropriate, design-system expectations should appear in RFPs, SOWs, or MSAs, onboarding materials, definitions of done, and technical acceptance criteria.

But contractual language is only the outer guardrail.

If noncompliance is discovered at final acceptance, governance has already failed. By then, the budget is mostly spent, the deadline is close, and the business has every incentive to ship the noncompliant work rather than rebuild it.

Vendor governance has to shift left into delivery.

Before the first sprint, external teams should have access to the relevant repositories, libraries, contribution rules, documentation, and automated checks used internally. During delivery, component usage, accessibility, tokens, visual regressions, and unsupported overrides can be checked through CI/CD. Domain stewards can review relevant pull requests and design changes while the work is still inexpensive to correct.

Compliance should be visible sprint by sprint.

Final acceptance should confirm that the controls worked. It should never be the first time anyone checks.

Every Design System Eventually Defends Its Budget

Treating the design system as a product has another consequence: it costs money.

The system needs people. Components require maintenance. Frameworks change. Accessibility requirements evolve. Products migrate. Research consumes capacity.

Eventually someone will ask what all of this is worth, and component counts will not answer the question.

Design-system metrics have to connect to work the organization already pays for: duplicate implementation, accessibility remediation, QA defects, vendor rework, and time-to-market.

The difficult part is measuring those things credibly.

Build the Telemetry Before You Need the ROI Story

You do not need a perfect enterprise analytics platform. You need enough connected evidence to establish patterns.

Design-tool analytics can show component usage in design. Repository scans or package analytics can show component usage in code. Jira or another delivery system can tag design-system work, migration, exceptions, and rework. Accessibility findings can distinguish defects inside shared components from defects introduced locally. Vendor records can show remediation and rejected work. A product inventory can show which lifecycle state each application is in.

Most organizations already have much of this data. What they lack is a connection between operational telemetry and business outcomes.

Avoided cost is especially difficult because it describes work that did not happen. Present it as an estimate, not a precise figure.

Sample comparable work. Measure how long a common pattern took before reusable components existed and how long comparable work takes now. Track how many duplicate implementations are retired. Measure remediation effort before and after accessibility defects are fixed at the component level. Compare vendor rework before and after automated controls and explicit contribution standards are introduced.

Over time, those observations become a defensible business case.

A design system’s value becomes demonstrable when reuse is measurable, deviation is visible, and the cost of both can be understood.

Measure Health, Not Just Activity

A scorecard should not contain every metric the organization could collect. It should tell leaders and practitioners whether the system is becoming healthier or weaker.

I separate the measures into four layers: leading indicators, adoption indicators, quality and risk, and business outcomes.

The first three layers help explain the fourth. If business outcomes deteriorate, you can work backward. Perhaps reuse is falling. Perhaps forks are increasing. Perhaps governance response time has doubled. Perhaps teams were never properly onboarded.

Measurement turns “people are not following the system” into something that can actually be investigated.

Design Systems Die Slowly

Design systems rarely die in a dramatic meeting. They decay through reasonable local decisions that accumulate faster than anyone manages them.

A team gets an exception, and nobody reviews it again. Another team copies the implementation. A vendor creates a different component because the system was absent from onboarding. Figma changes, but production does not. Documentation falls several releases behind. Accessibility defects appear in local variations. Governance slows because too many decisions have been centralized.

Legacy products remain outside the reporting model. A component is deprecated without a migration path. Product deadlines consume maintenance capacity. Research becomes sporadic. The scorecard stops being reviewed. Leadership reduces funding because nobody can explain what the system prevents or enables.

Nothing technically shuts down. The libraries still exist. Storybook still loads. Documentation is still online.

People simply stop trusting the system enough to depend on it.

Then local decision-making returns, one defensible exception at a time.

That is how a design system dies.

Guardrails Need Escape Hatches

More control will not fix this.

Large organizations contain acquisitions, legacy platforms, regional regulations, different technology stacks, security constraints, and legitimate product needs. No central system will predict every case.

Trying to eliminate every exception creates another kind of failure: teams stop engaging with governance entirely.

But an exception cannot become permanent simply because it was once approved.

Every exception needs an owner, a reason, a risk classification, and an expiration or review date. More importantly, approval should automatically trigger a second action: evaluating whether the exception represents a future capability the system needs. Generating a backlog item when the exception is approved can be enough.

The lifecycle becomes:

If several teams request the same exception, its priority should rise. If the pattern proves broadly useful, absorb it into the system as a new capability. If an existing component can be improved to cover the need, extend that component instead. If the need is still valid and nothing else fits, renew the exception with a new review date. If the original need disappears, retire it.

An exception is temporary debt against the system, and governance needs a mechanism for paying it back.

Otherwise the exception registry becomes an organized ledger of debt nobody is paying down.

The Organization Is Part of the Architecture

Conway’s Law, drawn from Melvin Conway’s 1968 paper [PDF], holds that organizations tend to produce systems that mirror their communication structures.

Design systems make that relationship unusually visible.

Design owns part of the system. Engineering owns part. Accessibility constrains behavior. Marketing and brand shape presentation. Content affects language and localization. Architecture constrains implementation. Legal and regulatory teams introduce requirements. Procurement determines what vendors must follow. Product management sets priorities. Project management determines when work happens. Leadership determines whether there is capacity to keep doing it.

The system breaks where those groups stop communicating. Communication is therefore more than change management around the design system; it is part of the system’s architecture.

If the organization is fragmented, eventually the design system will express that fragmentation.

The Work After the Work

Good foundations still matter. Good components matter. Accessibility, documentation, code quality, and design-code parity matter.

They are just not enough.

After launch, a design system has to survive budgets, deadlines, vendors, legacy products, leadership changes, and thousands of local decisions made when nobody from the design-system team is in the room.

Surviving all of that requires an organization around the system: one that can fund it, measure it, teach people to use it, research it, migrate toward it, govern it, and change its own rules when the evidence says those rules are wrong.

The goal is not to preserve the design system.

The goal is to preserve its usefulness.

Before adding another component, look at the organization around the system.

That is usually where the harder design problem is.

“Any organization that designs a system ... will produce a design whose structure is a copy of the organization's communication structure.”
-Melvin Conway

Key Takeaways

• Launch is day zero. The operating model after delivery determines whether the system survives.
• Treat the system as an internal product. Its users are designers, developers, and product teams, and their workarounds are product feedback.
• Governance has to federate. Centralize enterprise standards and high-risk decisions; distribute bounded decisions to trained domain stewards.
• Adoption is a behavior problem. Build enablement into the delivery system so teams can become competent without permanent central-team support.
• Legacy migration needs its own strategy. Track each product’s lifecycle state so adoption numbers mean something.
• Vendor governance must shift left. Contracts matter, but repository access, CI/CD checks, PR review, and sprint-level controls prevent expensive surprises.
• Measure causes before outcomes. Leading indicators, adoption indicators, and quality and risk signals help explain business results and make ROI more credible.
• Design systems usually die slowly. Exceptions, forks, stale documentation, weak telemetry, underfunding, and lost trust accumulate until the library remains but the system no longer does.
• Exceptions need a lifecycle. Every approved exception should be reviewed and end in one of four ways: absorbed into the system, resolved by extending an existing component, renewed with a new review date, or retired.
• The organization is part of the architecture. Where teams stop communicating, the system breaks.