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:
type ButtonVariant = "primary" | "secondary" | "outline" | "ghost"
type ButtonSize = "sm" | "md" | "lg"
<Button variant="primary" size="md">...</Button>
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
- Dcrayons glossary: content-modelling, jamstack, edge-runtime
- Dcrayons 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.
