Design systems at scale: lessons from Nestlé and AstraZeneca

Design systems at global enterprises are less about pixels and more about governance, adoption, and change management. At Nestlé and AstraZeneca I worked on design systems that had to serve dozens of brands, regions, and product teams simultaneously—each with their own brand guidelines, accessibility requirements, localization needs, and engineering stacks. The technical foundation matters: tokens, components, documentation, versioning. But the technical foundation is useless if teams don’t adopt it, if governance decisions take six weeks, or if the organization can’t agree on who owns what. Enterprise design systems fail more often from organizational failures than technical ones.

Why enterprise design systems are governance problems first

A design system for a five-person startup is primarily a technical problem: define the tokens, build the components, document the usage. The complexity is manageable, the stakeholders are few, and the system can evolve rapidly because the team is small and aligned.

A design system for a global enterprise is primarily a governance problem. The technical complexity is real, but it’s dwarfed by the organizational complexity: dozens of product teams with different priorities, multiple regional offices with different localization requirements, brand teams that have strong opinions about how their visual identity should translate to digital, engineering teams on different stacks who need the system to work in their context.

The governance questions that need answers before the first component is built:

• Who owns the design system? Is it a central team, a federated team, or a combination? Who has the final say on component API decisions, token naming, and deprecation policy?
• Who are the users? Just designers? Designers and engineers? Include content designers, accessibility specialists, brand managers? The answer determines documentation scope, tooling requirements, and support model.
• How do product teams get what they need? Can they request new components? Can they fork existing ones? Can they propose changes to the core? What’s the process and what’s the turnaround time?
• How does the system stay current? Who maintains it when the product evolves? Who reviews and merges contributions from product teams? How is it versioned?

Getting these answers—and documenting them in a governance charter that the organization has actually agreed to—is the prerequisite for building anything that will survive contact with enterprise reality.

What I learned about design system adoption at scale

The best-built design system in the world fails if product teams don’t use it. Adoption is a product problem applied to an internal audience, and it deserves the same rigor.

The adoption levers that actually worked at enterprise scale:

Make adoption the path of least resistance. The design system should be easier to use than not using it. If setting up the design system requires three days of environment configuration, teams will use something else. If the components don’t match what’s already in the codebase, teams will build their own. The system needs to be integrated into the tools teams already use—Figma for designers, npm/package managers for engineers—with clear, current installation documentation.

Embed ambassadors in product teams. The ambassador model is essential at enterprise scale. A central design system team can’t know the specific needs of forty product teams. Ambassadors—designers or engineers in each product team who have a relationship with the design system team—serve as the feedback channel in both directions: real-world needs flow to the core team, and updates and changes flow to the product teams through someone with context and credibility.

Treat the design system as a product with a roadmap. Product teams trust products they can plan around. A design system with a public roadmap, a versioned release schedule, and a clear migration path between versions earns trust from engineering teams who’ve been burned by internal tools that break without notice. At Nestlé and AstraZeneca, we maintained public roadmaps and held quarterly office hours where product teams could see what was coming and ask questions.

Document decisions, not just components. The documentation that builds trust isn’t the API docs—it’s the decision documentation. Why was this component built this way? What alternatives were considered and why were they rejected? What accessibility requirements does this component satisfy? Product teams who understand the reasoning behind the design system trust it more and fork it less.

Token strategy for multi-brand enterprise systems

Token architecture is where enterprise design system complexity is highest and where most systems eventually develop significant technical debt. The challenge: different brands within a global enterprise have different visual languages, but they share a digital infrastructure and a component library. The token system has to express both brand differentiation and component consistency simultaneously.

The architecture that works at scale is a three-tier token system:

Tier 1: Primitive tokens. Raw values with no semantic meaning. The specific hex colors, specific pixel values, specific font names and weights. These are the vocabulary of the visual language—every possible value that the system uses lives here.

color-blue-500: #2563EB
spacing-4: 16px
font-size-lg: 18px

Tier 2: Semantic tokens. Roles that map to primitive values. Color roles (surface-primary, text-primary, border-default), spacing roles (space-component-gap, space-layout-section), and type roles (text-body, text-heading-1). These are what components reference.

surface-primary: color-blue-500
text-primary: color-neutral-900
space-component-gap: spacing-4

Tier 3: Component tokens. Component-specific overrides, used when a component has a value that doesn’t cleanly map to a semantic token or needs a specific variant.

button-background: surface-primary
button-padding-horizontal: spacing-6

For multi-brand systems, the brand differentiation lives at Tier 2: each brand has its own semantic token mapping that points to different Tier 1 primitive values. The Nestlé brand’s surface-primary maps to Nestlé blue; the Nescafé brand’s surface-primary maps to Nescafé red. The components are identical—they reference surface-primary—but they look different because the semantic token values differ. This architecture lets you maintain one component library that serves multiple brands with no component duplication.

The implementation in code is typically a CSS custom property override at the brand scope: each brand has a CSS file that sets its semantic token values, applied at the root element for that brand’s properties. Switching brands is a class or data-attribute change at the HTML root. This is clean, testable, and maintainable.

How do you run design system governance without slowing down product teams?

Governance is the thing that kills design systems at enterprise scale. Too much governance and the system becomes a bureaucratic bottleneck that product teams route around. Too little governance and the system fragments into a collection of team-specific forks that share a name but not a standard.

The governance model I found most effective is the RACI for design system decisions:

• Responsible: the design system core team—the people who do the work of building and maintaining
• Accountable: the design system lead—the single person who has final sign-off on system decisions
• Consulted: product team ambassadors, brand team, accessibility team, legal (for regulated industries)
• Informed: all product teams, engineering leads, design leadership

With this model, most decisions move fast: the core team proposes, the design system lead approves, ambassadors get heads-up. Major decisions (breaking changes to existing components, significant governance policy changes, new component categories) go through the consulting layer. This prevents both the bottleneck of consensus-seeking and the fragmentation of ungoverned local decisions.

The versioning policy is where governance becomes most visible to product teams. The convention I recommend for enterprise systems:

• Patch versions (1.0.1): bug fixes, documentation improvements, no API changes. Auto-adoptable with no review required.
• Minor versions (1.1.0): new components, new variants, backward-compatible changes. Product teams get 2 weeks notice before release.
• Major versions (2.0.0): breaking changes to existing component APIs, token renames, structural changes. Product teams get a migration guide, a 6-week adoption window, and dedicated support from the core team.

This policy makes it safe for product teams to take automatic updates for patches while giving them control over when to absorb breaking changes. Trust in the versioning policy reduces the number of teams that pin to old versions and refuse to update.

What a mature enterprise design system looks like

After two to three years of deliberate development, a mature enterprise design system has:

• A versioned component library available in multiple frameworks (Web Components or a shared abstraction layer that generates React, Vue, and native implementations from the same source)
• A Figma library synchronized with the code library through a defined process—Figma components match code components in naming, props, and variants
• Documentation that covers: component usage, accessibility requirements, design rationale, migration guides for major versions, and a contribution guide for product teams
• A governance model with documented ownership, a public roadmap, and a regular cadence of ambassador syncs and all-hands design system updates
• Metrics: adoption rate across product teams, component usage by type, open issues and resolution time, Figma and npm download trends

None of this arrives at once. It’s built incrementally over years, prioritized by where the system is causing the most friction and where adoption is weakest. The work of building a design system never ends—it’s continuous maintenance and evolution, not a project with a ship date.

For how this connects to the token and branching discipline required at the engineering level, branching strategies for design-engineering collaboration covers the git-side practices that keep the design system synchronized between Figma and code.

Key Takeaways

• Enterprise design systems fail primarily on governance and adoption, not on technical quality: who owns what, how product teams access what they need, and how decisions get made are the critical questions
• The ambassador model—embedded representatives in each product team who have a relationship with the core design system team—is essential for managing the feedback loop at enterprise scale
• A three-tier token architecture (primitives → semantic → component) enables multi-brand systems where one component library serves multiple visual languages through semantic token overrides
• Versioning governance (patch/minor/major with defined adoption windows and migration guides) is what earns product teams’ trust and prevents version pinning
• Treat the design system as a product: public roadmap, regular releases, documented decisions, support model. Teams trust products they can plan around