Building a unified component library across 3 product teams — 80+ components, 2 design languages unified, shipped in 6 months.
Three independent product teams — HMI, MRO, and Ground Operations — had each built their own design patterns over years of isolated development. Components were duplicated across codebases, inconsistent in behaviour and visual language, and poorly documented. Every new feature required developers to reinvent already-solved problems, while designers spent hours reconciling conflicting styles.
The mission was clear: unify everything under a single, tokenized, and rigorously documented design system. This meant not just consolidating visual assets, but establishing a shared governance model, contribution workflow, and semantic token architecture that all three teams could adopt and trust as a source of truth.
The central challenge was political as much as technical — three teams with different roadmaps, different tech stacks, and different levels of design maturity. Building the system itself was only half the job. Achieving real adoption required deep collaboration, clear communication, and a phased rollout strategy that minimised disruption to active sprints.
Before building anything, we needed to understand exactly what existed. A full component inventory audit across all three codebases revealed the true scale of fragmentation — and built the business case for investment.
340+ components catalogued across HMI (142), MRO (118), and Ground Operations (80). Taxonomy built in Figma to identify overlaps, near-duplicates, and gaps.
Identified 3 competing visual grammars: different type scales, unrelated spacing systems, and colour palettes with no shared primitive tokens.
8 frontend engineers interviewed on pain points. Key theme: component fragmentation was creating friction at every handoff, slowing delivery by an estimated 30%.
40% of components were near-duplicates with subtle but consequential differences — different hover states, different focus rings, different error styles for identical input types.
No shared colour tokens — colour inconsistencies found in 12 critical screens, including status indicators used in safety-relevant contexts with diverging meanings across teams.
Developers spent 30% of sprint time recreating components that already existed elsewhere — work that was entirely invisible to product managers because there was no shared inventory.
A design system succeeds or fails through its adoption — and adoption is a people problem. We mapped the three key stakeholder profiles across teams to understand their expectations, concerns, and the conditions for buy-in.
The foundation of the system is a three-tier token architecture. Primitive tokens define the raw values; semantic tokens assign meaning; component tokens bind semantic values to specific UI elements. This separation ensures that a single primitive change propagates consistently everywhere.
Each category has its own primitive-to-semantic mapping, documented in Tokens Studio and synced to the codebase via a CI pipeline.
62 primitive colours, 28 semantic aliases. Status colours (critical, warning, success, info) defined once and used everywhere — including safety-critical HMI screens.
Single type scale with 8 steps, 3 weights, and responsive fluid sizing. Display, body, label, and code variants — each mapped to semantic roles, not arbitrary px values.
4px base unit, 10 spacing steps. Semantic aliases for component padding, layout gaps, and section margins ensure spatial consistency without memorising numbers.
Duration and easing tokens for micro-interactions. Critical for aerospace contexts where unnecessary animation in safety UIs must be suppressed via a motion.reduced override.
5-level shadow scale with semantic aliases. Ensures z-axis hierarchy (overlays, dropdowns, modals) is consistent across products — critical for layered dashboard UIs.
Single icon set (324 icons) replacing 3 competing libraries. Consistent sizing scale, semantic naming, and SVG tokens for colour overrides tied to status tokens.
The library is structured around functional clusters rather than atomic categories. Each cluster is documented with usage guidelines, accessibility notes, and Storybook stories that serve as living specifications for developers.
3 variants (Primary, Secondary, Ghost), 4 sizes, 3 intent states (default, warning, destructive). Replaces 10 divergent button implementations. Supports icon-leading, icon-trailing, and loading states. Fully WCAG AA compliant contrast ratios at all sizes.
22 form components unified into a single system. Consistent focus ring behaviour, error states, and helper text patterns. Critical for MRO maintenance forms where field validation errors have operational consequences. All components keyboard navigable.
Replaces 3 custom table implementations across teams. Shared column configuration API, row selection patterns, inline editing, and status cell variants. Designed for dense aerospace data — up to 14 columns at 1280px without horizontal scrolling.
6 navigation patterns covering sidebar (collapsed/expanded), top bar, tab navigation, breadcrumbs, and contextual menus. Active state, permission-based item visibility, and responsive collapse behaviour baked in — not left to individual implementations.
Every component ships with: a usage guideline, an anatomy diagram, accessibility notes, do/don't examples, and a Storybook story. Documentation is mandatory — undocumented components are not merged.
Semantic versioning (major.minor.patch). Breaking changes require a 2-sprint deprecation notice with migration guide. A shared changelog Slack channel pings all three product teams on every release.
Any team can propose a new component via a structured RFC (Request for Component) template. The design system team reviews in weekly office hours, preventing bottlenecks while maintaining quality control.
A big-bang migration was not an option — it would have disrupted three active roadmaps simultaneously. We designed a phased adoption strategy that allowed each team to migrate at their own pace while immediately benefiting from shared tokens.
Token library published and adopted across all three design files. Designers begin using shared colour, typography, and spacing tokens in new work immediately. No component migration required yet — reducing the activation barrier to near zero. Parallel: first 20 foundational components built and documented in Storybook.
Teams migrate existing screens to shared components, starting with the highest-traffic surfaces. A dedicated migration sprint (1 week per team) was budgeted into each roadmap. The design system team provided direct support during migration — pairing with developers to resolve edge cases and capturing new component requirements that emerged from real usage.
Product managers were reluctant to budget migration sprints. We built a ROI calculator showing projected time saved per sprint post-adoption vs migration cost — making the business case in their language.
Three teams had three opinions on naming conventions. We held two structured workshops using a decision matrix and defaulted to the most self-documenting option — solving the political problem with a process.
The MRO team had complex table states (offline sync, partial-data rows) not covered by the baseline component. We introduced a formal RFC process to elevate edge cases into first-class component variants rather than one-off overrides.
Rather than a single A/B test, validation was continuous — embedded into the normal sprint cadence through structured design review sessions and a rapid iteration loop on component quality.
Each team's designers attended a shared 45-minute session every two weeks. Screens built with the system were reviewed for consistency. Deviations were catalogued: either fixed (incorrect usage), fed back as component improvements, or escalated to the RFC process for new variants.
Measured as the percentage of new UI surfaces built using design system components rather than custom solutions. Remaining 8% are documented edge cases awaiting RFC resolution — not defections. The system now handles 100% of new screen creation for all three teams.
| Metric | Week 1 | Week 4 | Week 6 |
|---|---|---|---|
| Component adoption rate | 34% | 71% | 92% |
| Active Figma library detaches | 47/week | 18/week | 4/week |
| Developer "where is X?" Slack questions | 22/week | 9/week | 2/week |
I would involve one embedded developer from each team from the very first week — not at the review stage. Having engineers co-own the token naming decisions from the start would have prevented several naming conflicts and made the Storybook integration significantly smoother. Designer-only workshops produce design-centric solutions; cross-functional workshops produce ones that actually get built.
Interested in building a design system together?
Get in touch