A single system, four products

Why the system had to exist

Every product team was solving the same visual problem from scratch. Buttons with five different border radii. Three interpretations of the same status badge. Design inconsistency was slowing shipping velocity and eroding user trust.

So I built a token-first design system from scratch alongside shipping product. No dedicated systems team - just ruthless prioritisation, a shared Figma library, and the discipline to treat consistency as a feature.

Role

Lead Product Designer

Duration

Nov 2025 - Jan 2026

Scope

0 → 1 system

Tools

Figma

Three challenges that forced the system

• Consistency. Products started looking inconsistent - five different button radii, three interpretations of the same status badge.
• Collaboration. Constant back-and-forth between designers and developers. No single source of truth meant every handoff needed renegotiating.
• Ease of use. Teams built custom solutions for patterns that should have been reusable. Effort spent reinventing, not building.

The constraint was the brief: no dedicated systems team, no runway to pause product work. The system had to be designed in the gaps, documented enough to survive handoff, opinionated enough to actually reduce decisions.

Approach

• Token-first. Every colour, spacing step and shadow is a named token. Swap the token, update every instance.
• Component contracts. Each component ships with defined props, states and usage rules. No ambiguity in handoff.
• Built while shipping. Tokens and components introduced incrementally alongside real features - not in a silo.
• Documentation as design. The Figma file is the doc. Annotations live inside frames, not in a Notion page nobody reads.

Foundations

A modular, atomic approach that breaks interfaces into reusable pieces: design tokens, then atoms, molecules, organisms, templates and finally screens assembled with real content.

• Color system. Semantic tokens and palettes - neutral, brand, error, success and warning - for scalable themes and clear visual hierarchy.
• Typography. Lato in bold, semi bold and regular, with text styles defined as tokens and predefined roles for titles and body text.
• Spacing and radius. A consistent scale, every value a reusable token, so layouts stay balanced and predictable.
• Iconography. A unified icon library at a single stroke weight. Mixing icon styles is the fastest way to make a UI feel cheap.

Tokens in three tiers

Colour tokens are split into primitive, semantic and component tiers. Raw hex values live in the primitive layer and are never used directly in components. Semantic tokens name the intent: color.action.primary means the primary action colour, regardless of what hex it resolves to.

Component tokens bind to semantic ones. Button.bg references color.action.primary, so updating the brand colour cascades automatically - a full brand theme can be swapped by updating one primitive token.

Components

Smart components adapt to states, themes and content, reducing manual work and keeping every screen consistent.

• Buttons. Four variants: primary, secondary, tertiary, ghost. Every state documented. No one-off styles.
• Input fields. Seven states, three sizes. Error and helper text are baked in - not detached text layers.
• Checkbox, radio and toggle. Indeterminate state explicitly handled - a gap most teams discover in production.
• Dropdown and select. Multi-select, single-select, searchable. Inherits input anatomy: same tokens, same spacing.
• Tabs and navigation. Line and pill variants. Active state uses the accent token - swap the theme and every tab updates.
• Date and time picker. Travel-critical. Range selection, blocked-date states, time picker.

“Handoff gaps live in the unstated. If hover is not designed, engineering invents it. If loading is not specified, it gets cut.”

What changed

Zero to v1 took three weeks, while shipping product.

What I learned

• Adoption beats perfection. A system no one uses is a system that does not exist. Ship an imperfect v1 fast, iterate based on real usage - not theoretical completeness.
• Tokens are the real leverage. Components can be rebuilt. Tokens are load-bearing. Getting naming conventions right early saved weeks of migration work later.

Building a design system is mostly invisible work - until it isn’t.