Building a Unified Design System for a Multi-Product Enterprise Platform

Context & Problem

The platform had grown through acquisition and parallel development. Five product lines, twelve teams, and no shared design language. Every team had built their own component patterns: buttons looked different, data tables behaved differently, navigation models clashed. Customers moving between products felt like they were using different companies.

The cost was visible everywhere: duplicated design effort, inconsistent accessibility, slow onboarding for new designers and developers, and a support burden driven by UI confusion. Leadership wanted a unified experience, but previous attempts at standardization had stalled because they were top-down mandates without real adoption strategy.

My Role & Scope

I was brought in as the design system lead, responsible for the component architecture, design-language definition, governance model, and cross-team adoption strategy. I reported to the Head of Product Design and worked directly with engineering leads, product managers, and individual contributors across all product lines.

Constraints & Stakeholders

• Legacy codebases: Three products ran on Vue, one on React, one on a custom framework. The system had to be framework-agnostic at the token level.
• Team autonomy: Product teams had strong ownership cultures. Mandating adoption would fail; the system had to earn trust through quality and utility.
• Accessibility requirements: Enterprise customers required WCAG 2.1 AA compliance. Every component needed to be accessible by default, not as an afterthought.
• No dedicated budget initially: The first six months were funded by borrowing capacity from product teams, which meant proving value fast.

Process & Key Decisions

1. Audit before architecture

I started with a comprehensive component audit across all five products. We cataloged every button, form element, modal, table, and navigation pattern. The result was a spreadsheet with 340+ unique component variants, many doing the same thing differently. This artifact became the business case: visible waste, visualized.

2. Token-first foundation

Instead of jumping to component design, I established design tokens first: color, typography, spacing, elevation, motion. This was deliberate: tokens could be adopted incrementally without rebuilding entire product UIs. Teams could start using the system before the component library was ready.

3. Component governance model

Every component went through a lifecycle: proposal, design review, accessibility audit, engineering review, documentation, release. I set up a contribution model where product teams could propose components, but the core team maintained quality gates. This balanced ownership with consistency.

4. Adoption through embedding

Rather than publishing the system and hoping teams would adopt it, I embedded with two product teams for their next major release cycles. Working alongside their designers and engineers, I migrated real product surfaces to the system, proving it worked in production, not just in Storybook demos.

5. Documentation as product

The documentation site was treated as a product, not an afterthought. Every component page included usage guidelines, do/don't examples, accessibility notes, and code snippets. We tracked documentation page views and search queries to understand what teams actually needed.

What Changed

Outcome & Impact

Within the first year of adoption:

• UI inconsistencies dropped significantly: customer support tickets related to "confusing interfaces" decreased as products converged on shared patterns.
• Design-to-engineering handoff accelerated: engineers could reference documented, production-ready components instead of interpreting one-off Figma mockups.
• New designer onboarding compressed: what previously took 4-6 weeks of "learning how we do things here" dropped to under 2 weeks with system documentation and established patterns.
• Cross-product feature development became feasible: shared components meant features could be designed once and deployed across multiple products without re-implementation.

Lessons Learned