Enterprise Design System Architecture: Tokens and Components

A design system in 2018 was a Sketch file + a styleguide PDF. In 2022 it was a Figma library + a Storybook page. In 2026 it's a federated architecture spanning design tokens (the atomic source), a component library (the implementation), a distribution layer (npm packages or hosted services), and a governance pattern that lets it evolve across products + brands.

This is the design system architecture we apply on enterprise + multi-brand engagements. It covers token design, component patterns, distribution mechanics, multi-brand theming, and the governance that lets the system actually get used.

What a design system is for (the boring honest version)

Three things, in order of priority:

Function | What it provides | Who benefits
Visual consistency | Buttons look like buttons across products + pages | Customers + brand teams
Development velocity | Engineers don't rebuild the same components | Engineering teams
Brand evolution | One source of truth that updates everywhere | Design + brand leadership

Design systems get built for "consistency" but the actual ROI is "speed". A well-designed system reduces front-end build time 30-60 percent on greenfield features + dramatically reduces visual-bug rate.

If your team isn't getting either of those benefits, you don't have a design system; you have a documentation site.

The four layers

A production design system is a stack:

Layer 1: design tokens

The atomic primitives. Colours, spacings, font sizes, shadows, border radii. Stored as platform-agnostic data + rebuilt into per-platform formats (CSS variables for web, Swift constants for iOS, XML for Android).

{ "color": { "brand": { "primary": { "value": "#152131" }, "olive": { "value": "#697416" } }, "neutral": { "100": { "value": "#F5F5F5" }, "900": { "value": "#171717" } } }, "spacing": { "1": { "value": "4px" }, "4": { "value": "16px" }, "8": { "value": "32px" } } }

Tooling: Style Dictionary (Amazon), Tokens Studio (Figma plugin + ecosystem), Specify (commercial), Theo (Salesforce, legacy).

The transformation: token JSON → CSS variables + Tailwind config + Swift constants + Android XML. One source, many outputs.

Layer 2: primitive components

The base building blocks. Button, Input, Select, Checkbox, Card, Avatar, Badge, Tooltip, Modal, Drawer. ~20-40 components depending on product complexity.

Each component: - Built on top of design tokens (no hardcoded colours or spacings) - Accessible (ARIA roles, keyboard navigation, screen-reader support) - Composable (children, slots, render props) - Themeable (light + dark mode at minimum; multi-brand for federated programmes)

Layer 3: composite components

Built from primitives. Navigation header, footer, search bar, product card, pricing table, testimonial section, hero block. ~40-80 composite components for a mature D2C site.

These are the "page building blocks" content + marketing teams compose with. Engineers build them once; everyone uses them.

Layer 4: page templates + layouts

Pre-assembled compositions of composite components. Landing page template, blog post template, product page template. ~10-20 templates.

The CMS uses these as the section catalog editors pick from. New page = pick a template, fill in the content, ship.

Tokens that survive: naming + semantics

The single highest-impact decision in a design system is token naming. Get it wrong + every component update fights the naming.

Pattern that works: semantic tokens layered over primitive tokens

Primitive tokens (raw values):

color-neutral-100: #F5F5F5 color-neutral-900: #171717 color-blue-500: #3B82F6 color-red-500: #EF4444
Semantic tokens (purpose-based, mapped to primitives):
color-background-default: color-neutral-100 color-text-default: color-neutral-900 color-action-primary: color-blue-500 color-status-error: color-red-500
Component-specific tokens (used in actual components):
button-primary-background: color-action-primary button-primary-text: color-neutral-100 input-border-error: color-status-error

The layering means: changing the brand from blue to olive requires updating the primitive layer. The component layer keeps working. The semantic layer keeps working. Theming becomes possible.

Pattern that breaks: direct colour-name tokens

button-blue: #3B82F6 input-blue-border: #3B82F6 text-blue-link: #3B82F6

Now the brand changes to olive + you have 47 references to "blue" across components. You either rename everything (touching 47 places) or you have "button-blue" with an olive value (semantically incoherent forever).

Component patterns that work

Pattern 1: compound components

Instead of one component with 30 props, expose a compound API:

<Card> <Card.Image src={...} /> <Card.Title>...</Card.Title> <Card.Body>...</Card.Body> <Card.Footer> <Button variant="primary">...</Button> </Card.Footer> </Card>

Compound components compose flexibly + read clearly. Single mega-component APIs become unwieldy as the design system matures.

Pattern 2: slot-based composition

For layouts + complex containers:

<PageHeader start={<Logo />} center={<Navigation />} end={<UserMenu />} />

The component handles the layout; consumers provide the contents.

Pattern 3: render props for behaviour-rich components

For components that need consumer-controlled behaviour (data tables, infinite scrolls, virtualised lists):

<DataTable data={users} columns={columns} renderRow={(user) => <Row user={user} />} renderEmpty={() => <EmptyState />} />

Pattern 4: variant prop with strict schemas

For visual variants, use TypeScript-enforced enums:

Variant + size are validated at compile time. The component handles styling for each combination.

Multi-brand theming: the federation pattern

For agencies + holding companies running multiple brands, the design system needs to support multi-brand without forking.

The theming architecture

Layer | Brand A | Brand B | Brand C
Primitive tokens | Brand-A colour palette | Brand-B colour palette | Brand-C colour palette
Semantic tokens | Same naming, different values | Same naming, different values | Same naming, different values
Components | Same code, no brand-specific logic | Same code | Same code
Composites | Mostly same; brand-specific exceptions clearly marked | Mostly same | Mostly same

The brand-switching happens at the token layer. Components don't know which brand they're rendering for; they consume semantic tokens that resolve to brand-specific primitives.

When this breaks down

Brand-specific component variants. Brand A's button shape is different from Brand B's. Two options: parameterise the component (border-radius is a token) OR maintain brand-specific component variants.
Brand-specific layouts. Brand A's homepage looks fundamentally different from Brand B's. The compositional layer (templates) becomes brand-specific.
Brand-specific behaviours. Brand A has a unique animation; Brand B doesn't. Behaviour-level customisation needs careful component design.

For most multi-brand agencies + holding companies, the discipline is: keep the primitive + semantic + component layers shared; let the composite + template layers diverge.

Distribution: how the system reaches consumers

A design system that exists in Figma but not in code isn't a design system; it's a style guide. Distribution is where the value compounds.

Web (React)

Publish as an npm package (@yourorg/ui)
Versioned via semver
Tree-shakeable (consumers import only what they use)
Source-mapped + TypeScript-typed
Storybook for documentation + visual regression testing

Native (iOS + Android)

iOS: Swift Package Manager (SPM) or CocoaPods
Android: Maven Central or your own repository
Both consume the same design tokens; different component implementations per platform

Designers (Figma)

Figma library with token sync via Tokens Studio or similar
Components in Figma match component API in code
Variants in Figma match variant props in code
Designers don't need to write code; their library mirrors the production library

CMS / no-code

Token + component metadata exposed to the CMS
CMS section catalog matches the code component library
Editors compose pages from the same components engineers build with

Governance: how the system evolves

A design system without governance becomes either:

Stagnant (no one updates it; engineers fork + diverge)
Chaotic (every team adds components; no consistency)

The component-addition workflow

Step | Owner | Outcome
1. Proposal | Engineer or designer | RFC documenting the need, the proposed API, examples of usage
2. Review | Design system team + design lead | Approve / iterate / reject
3. Build | Component author | Implementation + tests + Storybook + Figma component
4. Documentation | Component author | Usage docs + Do's + Don'ts + accessibility notes
5. Release | Design system team | Versioned release + changelog + migration notes if breaking
6. Adoption | Consuming teams | Use the new component in their products

The component-deprecation workflow

Step | Owner | Outcome
1. Decision | Design system team | Component is being replaced or retired
2. Replacement | Design system team | New component published + migration guide written
3. Deprecation warning | Design system team | Old component emits deprecation warning in dev
4. Migration support | Design system team | Help consuming teams migrate
5. Removal | Design system team | After 1-2 major versions, remove the deprecated component

Quarterly governance review

Components added + adopted
Components proposed + rejected (and why)
Components used heavily but not yet in the system (suggests addition)
Consumption metrics: which teams use which components
Roadmap for the next quarter

What does this look like in practice?

A real-world snapshot of an Indian D2C agency with 4 brand engagements using one shared design system:

Primitive tokens: 320 colour + spacing + typography + shadow + radius
Semantic tokens: 180 (4 brands x 45 semantic categories)
Primitive components: 32
Composite components: 64
Page templates: 14
Figma library: 2,400+ components + variants
npm package versions per quarter: 6-8 releases
Consuming product teams: 4 brand front-ends + 2 internal tools
Design system team: 1 lead + 2 designers + 2 engineers

Engineering velocity on new pages: typical landing page goes from spec to shipped in 2-3 days instead of 8-12.

Production checklist

For an enterprise design system at the Rs 25 crore+ ARR brand-portfolio scale:

Design tokens defined: primitive + semantic + component-specific layers
Token transformation pipeline (Style Dictionary or equivalent)
Primitive component library (20-40 components, all accessible)
Composite component library (40-80 components, brand-themed)
Page templates / section catalog (10-20)
Multi-brand theming if applicable (federation pattern)
Distribution: npm package + Figma library + (iOS + Android packages if multi-platform)
Storybook for documentation + visual regression testing
Component-addition + deprecation workflows documented
Quarterly governance review with consuming teams
Adoption tracking + consuming-team support
Accessibility audit on every release (WCAG AA at minimum)

References + linked context

Dcrayon glossary: content-modelling, jamstack, edge-runtime
Dcrayon reference architectures: Enterprise Contentful + Next.js, Enterprise Sitecore XM Cloud + Vercel, Edge Personalisation on Vercel
Related: How to Pick a Frontend Framework in 2026, How to Pick a Headless CMS

Design systems are the engineering infrastructure under brand consistency + product velocity. If your team is building one + needs the architectural lock + the governance model, reach out via the contact form for a 30-minute review.