self initiated
Nucleus — Design System
Architecting a Token-Based Single Source of Truth for Multi-Product Enterprise SaaS
- Role
- Design System Architect — Token Architecture, Component API Design, Documentation Engine, Contribution Model, and Team Onboarding.
- Scope
- Design token architecture (color, spacing, typography, elevation), 120+ production-ready components with variants, a documentation site with usage examples, contribution guidelines, onboarding materials for new designers, and migration checklists for each existing product.
- Timeline
- 16 weeks
- Category
- Design System
Overview
A company running four SaaS products had grown from one design team to four — but without shared foundations. Each team had invented its own button styles, spacing scales, and color palettes. The inconsistency was visible to customers and costly to maintain.
Challenge
Every new feature was designed from scratch because there was no shared component library. This meant duplicated effort, inconsistent user experiences across products, and a growing gap between what design delivered and what engineering built.
Objective
Create a single, adoptable source of truth — tokens, components, and documentation — that all four product teams can use without sacrificing the speed or autonomy they need to ship independently. Unify 4 independent SaaS product UI libraries into 1 design system Reduce design-to-development handoff time by 50% Eliminate 100% of visual consistency bugs across products
Approach
Mapped the repeated component patterns across the hypothetical product set, then built the token layer first so that alignment on fundamentals would not have to wait for a full component library. Documented each component with usage rules and edge cases, since a system nobody can read is a system nobody adopts.
Selected decisions
Chose tokens-first over components-first. Teams that weren't ready to adopt full components could still align on spacing, color, and typography through shared tokens — lowering the adoption barrier. Documentation was treated as a product: searchable, versioned, and maintained with the same rigor as the components themselves.
Responsibilities
Cross-Product Component Audit Design Token Schema (Color, Spacing, Typography, Elevation) 120+ Production Variants in Figma Documentation Site & Adoption Workshops
Deliverables
A Figma component library with 120+ components and variant documentation, design token definitions exportable to CSS/JS, a documentation site with usage guidelines and code snippets, contribution workflow documentation, migration checklists per product, and onboarding materials for new team members.
Outcome
The exercise ended with a token layer, 120+ documented components with variants, a component taxonomy, and a written argument for tokens-first over components-first. Nothing was adopted, because there was no product team to adopt it.
Reflection
The hardest part of a design system isn't building components — it's building trust. Teams adopt systems they helped shape. The workshops and migration support ended up being more valuable than the Figma library itself, because they turned skeptics into contributors.