Reference Architecture: Design System Platform
Product forces
Design systems optimize for consistent, accessible, evolvable UI across many product teams. The architecture is a platform, not a style guide.
Architecture sketch
Default decisions
| Area | Default |
|---|---|
| tokens | primitive tokens compile into semantic tokens by theme/brand/mode |
| components | primitives first, product components second |
| package model | versioned packages with compatibility and deprecation windows |
| accessibility | component-level contracts and regression checks |
| documentation | usage guidance, anti-patterns, migration notes, live examples |
| governance | API review, adoption metrics, RFC process for breaking changes |
Critical risks
- Component library without ownership, support, or migration policy.
- Tokens named by raw value instead of semantic intent.
- Product teams forking components because APIs are too rigid.
- Accessibility regressions hidden inside shared primitives.
- Breaking changes shipped without codemods or migration windows.
Review checklist
- Does each public component have an API, accessibility, theming, and compatibility contract?
- Are semantic tokens stable across brands and modes?
- Is deprecation documented before removal?
- Are adoption signals visible?
- Can teams extend without bypassing the system?
Exercises
- Design a token taxonomy for color, spacing, type, radius, and motion.
- Write a component API review for Button, Dialog, or Combobox.
- Create a deprecation plan for a component prop used by three teams.
Source lens
Pair this with Part VII design-system chapters and the enterprise design-system capstone.