One design system for 14 products
Four designers, ~30 developers, 14 individual products that each had their own colors, fonts, icons, buttons, and navigation - and the ongoing work of unifying them into a single, token-based system. (You're seeing the idea right now: this site runs on semantic tokens. Toggle the theme.)
The problem: 14 products, 14 visual languages
A UI audit across the portfolio surfaced the scale of fragmentation:
- Each product maintained its own colors, typography, and icon sets
- Core components - buttons, tables, headers, navigation - were rebuilt independently in every product, with different behavior and states
- Designers solved the same problems repeatedly; developers re-implemented the same components repeatedly
- Clients moving between products experienced what felt like different companies
The cost wasn't aesthetic - it was speed. Every new feature paid a tax of re-deciding solved problems.
Goals
- One visual language across the portfolio, built on design tokens
- Reusable components with defined variants and states, mapped 1:1 to code
- Documentation that lets anyone use a component correctly without asking
- Adoption - a system only counts if products actually migrate to it
Foundations: token architecture
We built the system on a two-layer token structure in Figma variables:
- Primitive tokens define raw values - the full color ramps, type scale, spacing scale, radii, elevation
- Semantic tokens map those values to meaning - text/primary, color/error, surface/elevated - so components reference intent, not hex codes
The architecture supports day and night modes from a single source: switching themes remaps semantic tokens to different primitives, with zero component rework. Every value a component uses traces back to a token.
Components: variants, states, and real complexity
The library covers the portfolio's actual needs: buttons, labels, table cells and full tables, headers, sidebars, navigation, widgets, drawers, modals, uploaders, and more - each with defined variants, sizes, and interaction states (default, hover, focus, active, disabled) plus system-feedback states (loading, success, error).
WealthTech UI is data-dense, so the hardest components are the honest test of the system: table cells alone carry configurable chips, status indicators, wealth-object types, icons, and nested instances - all controlled through Figma component properties so designers compose without detaching.
Header & navigation
The clearest unification story. Before: every product had its own header and navigation - different structures, different behaviors, different placement of the same functions. We designed a single app-layout pattern flexible enough for all 14 products' needs, and products are migrating to it one by one. For clients using multiple products, the portfolio finally behaves like one platform.
Before / after: uploader
Document upload exists across the portfolio (a WealthTech essential), and every product had solved it differently - different flows, states, and error handling. The unified Uploader standardized the entire interaction: file states, progress, validation, and error recovery - designed once, adopted everywhere it's needed.
Governance without a bottleneck
Our team deliberately avoids a "final vote" model. Every significant decision is reviewed by the whole design team - our lead designer reviews work with the rest of us, but decisions are made together, by argument rather than authority. In practice:
- Component proposals are presented to the team before entering the library
- Anyone can challenge a pattern; the standard is consistency with the system's principles, not seniority
- The lead's role is direction and quality, not veto
This keeps the system coherent without making one person the bottleneck for 14 products' worth of decisions.
Collaboration with development
A design system succeeds at the code boundary, not in Figma. Working with the ~30 developers consuming the system, we align naming conventions between Figma tokens and code variables, map components to Storybook to keep the coded and design libraries in sync, and document states, edge cases, and interaction logic in plain language - so implementation doesn't depend on interpreting a static mock.
Documentation
Every component ships with documentation covering usage, variants, interaction states, accessibility considerations, and do/don't guidelines with examples. The goal: a developer or designer who has never seen the component can use it correctly without a meeting.
Proven twice: the system I built solo
This isn't my first design system. At Globalcell (an eSIM/telecom company), I built one solo and from zero while designing the company's first digital products - a single component system serving the external website, the iOS and Android apps, and the internal CRM-style tools used by staff.
The constraint there was the opposite of my current work: no design team to review with, no dedicated system time - just the necessity of one designer shipping consistently across multiple surfaces. The system had to make me faster, or it wasn't worth building.
It's still in production today, used by the team that came after me - including the junior designer I recruited and mentored. For a design system, outliving its creator's tenure is the real test of whether the foundations, naming, and documentation were sound.
Together, the two systems cover both realities of this craft: building one alone out of necessity, and scaling one across a portfolio with a team and governance.
Learnings
- Semantic tokens are the system's contract. Primitives change; meanings don't. Theming cost almost nothing because components never referenced raw values.
- Adoption is the product. A beautiful library nobody migrates to is a portfolio piece, not a design system. Designing the migration path is as much design work as the components.
- Governance by argument scales better than governance by authority. Four designers reviewing together catches more than one lead approving alone.
- The hardest components prove the system. Buttons are easy; data-dense table cells with nested, configurable instances are where token architecture either works or collapses.