Design Systems Architecture

Design Systems Architecture — Systematic Design at Scale

Design System Philosophy

"A design system is not a project. It is a product serving products." — Nathan Curtis

A design system is the single source of truth for how a product family looks, behaves, and communicates. It exists to multiply design and development efficiency while ensuring consistency across teams, platforms, and time. The system must be opinionated enough to ensure coherence yet flexible enough to serve diverse product needs.

Core Principles

1. Systematic over stylistic — define rules and relationships, not just visual recipes
2. Tokens are the foundation — design decisions encoded as data, not hardcoded values
3. Composition over inheritance — build complex components from simple, composable primitives
4. Document the why — every decision needs rationale to prevent future erosion
5. Adopt, then adapt — products adopt the system by default, request exceptions with justification

Design Token Architecture (W3C Design Tokens Standard)

Token Hierarchy

Tier 1: Global/Primitive Tokens (Raw Values) Define the complete value palette — all available options.

{
  "color": {
    "blue": {
      "50":  { "$value": "#eff6ff" },
      "100": { "$value": "#dbeafe" },
      "500": { "$value": "#3b82f6" },
      "900": { "$value": "#1e3a5a" }
    },
    "neutral": {
      "0":   { "$value": "#ffffff" },
      "50":  { "$value": "#fafafa" },
      "900": { "$value": "#171717" }
    }
  },
  "spacing": {
    "1": { "$value": "4px" },
    "2": { "$value": "8px" },
    "4": { "$value": "16px" },
    "8": { "$value": "32px" }
  }
}

Tier 2: Semantic/Alias Tokens (Contextual Meaning) Map raw values to design intent — what the value means.

{
  "color": {
    "bg": {
      "primary":   { "$value": "{color.neutral.0}" },
      "secondary": { "$value": "{color.neutral.50}" },
      "inverse":   { "$value": "{color.neutral.900}" }
    },
    "text": {
      "primary":   { "$value": "{color.neutral.900}" },
      "secondary": { "$value": "{color.neutral.500}" },
      "brand":     { "$value": "{color.blue.500}" }
    },
    "action": {
      "primary":   { "$value": "{color.blue.500}" },
      "primary-hover": { "$value": "{color.blue.600}" }
    }
  }
}

Tier 3: Component Tokens (Specific Application) Map semantic tokens to component properties — where the value is used.

{
  "button": {
    "primary": {
      "bg":    { "$value": "{color.action.primary}" },
      "text":  { "$value": "{color.neutral.0}" },
      "hover-bg": { "$value": "{color.action.primary-hover}" },
      "padding-x": { "$value": "{spacing.4}" },
      "padding-y": { "$value": "{spacing.2}" },
      "border-radius": { "$value": "{radius.md}" }
    }
  }
}

W3C Design Token Format (DTCG)

Follow the W3C Design Tokens Community Group specification:

• Use $value for token values
• Use $type to specify value type (color, dimension, fontFamily, fontWeight, duration, cubicBezier, shadow)
• Use $description for documentation
• Use {} syntax for references/aliases
• File extension: .tokens.json

Token Categories

Component Library Architecture

Component Anatomy

Every component has a defined structure:

Component
├── Props/API (inputs and configuration)
├── Variants (visual and behavioral variations)
├── States (default, hover, active, focused, disabled, loading, error)
├── Slots/Children (composition points for custom content)
├── Tokens (design token bindings)
├── Accessibility (ARIA, keyboard, screen reader behavior)
└── Documentation (usage guidelines, do/don't examples)

Component Maturity Model

Level 1 — Defined: Designed in Figma, documented in guidelines Level 2 — Implemented: Coded in component library, props API defined Level 3 — Tested: Unit tests, visual regression tests, accessibility tests pass Level 4 — Documented: Usage guidelines, API docs, examples, do/don't Level 5 — Governed: Change process established, versioning, deprecation path

Component API Design Principles

• Predictable props naming: Use consistent naming conventions across all components (size, variant, disabled, className)
• Enum over boolean: variant="primary" | "secondary" | "ghost" not isPrimary, isSecondary
• Composition over configuration: <Card><CardHeader /><CardBody /></Card> not <Card header={} body={} />
• Sensible defaults: Components work without props; customization is additive
• Type safety: Full TypeScript types for all props; no any types in public API
• Forward refs: All components forward refs for imperative access
• Polymorphic rendering: Support as prop for semantic HTML flexibility (<Button as="a" href="..." />)

Theming Architecture

Theme Structure

{
  "theme": {
    "light": {
      "color.bg.primary": "#ffffff",
      "color.bg.secondary": "#f5f5f5",
      "color.text.primary": "#171717",
      "color.text.secondary": "#737373",
      "color.action.primary": "#3b82f6"
    },
    "dark": {
      "color.bg.primary": "#171717",
      "color.bg.secondary": "#262626",
      "color.text.primary": "#f5f5f5",
      "color.text.secondary": "#a3a3a3",
      "color.action.primary": "#60a5fa"
    }
  }
}

Theming Implementation

• Use CSS custom properties (variables) as the runtime theming mechanism
• Apply theme by swapping custom property values at the root level
• Support system preference detection (prefers-color-scheme)
• Allow manual override with persistent user preference
• Component tokens reference semantic tokens, which resolve to theme-specific values

Multi-Brand Architecture

For organizations with multiple brands sharing a system:

• Shared foundation: Common component behavior, interaction patterns, accessibility
• Brand tokens: Each brand provides its own token set (colors, typography, spacing variations)
• Component override layer: Brand-specific component customizations when tokens alone are insufficient
• Theme matrix: Brand x Mode (e.g., BrandA-Light, BrandA-Dark, BrandB-Light, BrandB-Dark)

Governance and Scaling

Contribution Model

Centralized: Core team owns and builds all components

• Pros: High consistency, quality control
• Cons: Bottleneck, slow to address product-specific needs
• Best for: Small-medium organizations, early system maturity

Federated: Product teams contribute with core team review

• Pros: Faster growth, diverse input, shared ownership
• Cons: Consistency risk, review overhead
• Best for: Large organizations, mature systems

Hybrid (recommended): Core team owns primitives and governance; product teams contribute domain-specific patterns

• Core components (Button, Input, Card): centrally owned
• Domain components (DataGrid, FileUploader): contributed by domain teams, reviewed by core

Change Management Process

1. Proposal: RFC (Request for Comment) with use case, design, and API proposal
2. Review: Design review + code review + accessibility review
3. Build: Implementation with full test coverage
4. Document: Usage guidelines, migration guide if breaking
5. Release: Semantic versioning, changelog, migration support

Versioning Strategy

• Follow Semantic Versioning (SemVer): MAJOR.MINOR.PATCH
• MAJOR: Breaking changes to component API or visual appearance
• MINOR: New components, new props, backward-compatible enhancements
• PATCH: Bug fixes, accessibility improvements, documentation updates
• Deprecation: Mark deprecated with console warnings; maintain for 2 major versions
• Changelogs: Automated from conventional commits; include migration guidance

Design-to-Code Integration

Figma-to-Code Synchronization

• Figma component naming must match code component naming exactly
• Figma variants map to code component props
• Design tokens sync bidirectionally: Figma to tokens.json to code
• Use Token Studio (Figma plugin) for token management in design
• Automate token export with CI/CD pipeline (Style Dictionary, Token Transformer)

Code Generation

• Generate CSS/SCSS from design tokens using Style Dictionary
• Platform-specific output: CSS variables, iOS Swift constants, Android XML resources, React Native styles
• Generate TypeScript types from token schema
• Visual regression testing: compare Figma designs with rendered components

Routing

For running a system as a product — team models, the contribution workflow, the RFC template (motivation, detailed design, alternatives, migration, unresolved questions), and scaling: read references/governance-scaling.md.

For token architecture — the three-tier model, W3C DTCG naming, and the 2025 spec update: read references/design-token-architecture.md.

For maturity and multi-brand — the five-level model with team size, tooling, governance and promotion criteria per level, multi-brand token layering, white-label patterns, migration strategies and ROI measurement: read references/maturity-model-multi-brand.md.

For the token spec in implementation form: read references/design-token-implementation.md and references/token-specification-guide.md.

Cross-Referencing

• For visual design principles, reference ui-visual-design-system
• For accessibility component requirements, reference accessibility-inclusive-design
• For motion tokens and animation, reference interaction-motion-design
• For mobile component adaptations, reference mobile-ux-design

v3.0 Cross-References

The v3.0 upgrade introduces references that extend design system architecture into Figma MCP pipelines, maturity modeling, and modern CSS integration.

Figma MCP Design-to-Code Pipeline See figma-design-tool-workflows/references/figma-mcp-ai-flywheel.md for the Figma Model Context Protocol (MCP) server integration that enables AI-driven design-to-code workflows. This reference covers the MCP-powered flywheel where AI agents read Figma components, extract design tokens, generate production code, and validate output against the source design — creating a continuous synchronization loop between design and development that supersedes manual handoff processes.

Design System Maturity Model and Multi-Brand Token Architecture See references/maturity-model-multi-brand.md for the comprehensive 5-level design system maturity model (from Ad Hoc through Optimized), multi-brand token architecture patterns for organizations operating multiple product brands from a shared foundation, and the W3C Design Tokens 2025.10 $extensions specification. The $extensions property enables vendor-specific metadata (Figma constraints, platform overrides, deprecation flags) within standard token files, which is critical for tooling interoperability in mature multi-brand systems. This reference expands significantly on the Multi-Brand Architecture and Component Maturity Model sections above.

CSS @layer Integration with Token Architecture See component-patterns-code/references/css-modern-patterns.md for modern CSS @layer usage in design system token architecture. Cascade layers (@layer reset, tokens, components, utilities, overrides) provide deterministic specificity management for design systems at scale — eliminating the specificity wars that plague large component libraries. This reference covers how design tokens map to CSS custom properties within a layered cascade, enabling clean component-level theming without !important hacks or excessive nesting.

Token Implementation Deep-Dive See references/design-token-implementation.md for end-to-end token implementation: aliasing and referencing syntax, multi-theme architecture, the transformation pipeline, platform-specific outputs (web, iOS, Android), Figma integration, token documentation, versioning and migration strategy, governance, performance considerations, and token testing. Use it alongside references/token-specification-guide.md, which covers the W3C DTCG format and Style Dictionary configuration in spec detail.

Key Sources

• Curtis, N. "Design Systems" and Modular Web Design
• W3C Design Tokens Community Group specification
• Figma design systems documentation
• Material Design component guidelines
• Brad Frost "Atomic Design" methodology