How I Build.

Infrastructure first.
Components second.

Before touching Figma or writing a single token, I spend time understanding the organisation — its products, its pain points, and how design and engineering actually collaborate day-to-day.

Every system I build starts with a full UI audit. That means cataloguing every component, every colour, every spacing decision across every product surface. It's tedious, time-consuming work. It's also non-negotiable.

From there the process is sequential, not parallel. Foundation first, then components, then patterns, then documentation, then governance. Skipping steps creates debt that compounds.

Decisions as data,
not documents.

Tokens are the most important and least understood part of a design system. Most teams treat them as a colour palette. They're actually a decision layer — a machine-readable record of every visual contract in the system.

I use a three-tier model: Primitive → Semantic → Component. Primitives are raw values. Semantics are named decisions. Component tokens are scoped overrides.

This architecture means that a multi-brand product suite can be themed entirely by changing a small set of semantic tokens — without touching a single component.

Anatomy first.
Variants second.
States always.

Every component I build follows the same strict sequence: anatomy definition → default state → all interactive states → size variants → semantic variants → edge cases → dark mode → accessibility audit.

A checkbox has 24 meaningful states to account for: size, checked, indeterminate, disabled, focus, and error — in every combination. That's not perfectionism. That's what production-ready means.

A name is an API. Once engineers write variant="primary" across 400 files, that name is permanent. Every prop, every variant, every token gets named deliberately — with the component's entire future in mind.

Docs aren't a phase.
They're the product.

Nothing ships without complete documentation. That's not a policy — it's a quality bar. A component that isn't documented doesn't exist for the teams who need to use it.

Documentation is written by the person who built the component, not delegated downstream. It covers: usage guidelines, prop definitions, accessibility requirements, and every known edge case.

Every visual example reflects the actual production state of the system — not a screenshot taken on launch day and never updated. The doc site is live-linked to the component library.

A system without governance
is a museum.

The hardest part of building a design system isn't the components — it's the ongoing maintenance of trust between the DS team and the product teams using it. That trust lives or dies on governance.

I use a tiered ownership model: Core components owned exclusively by the DS team, Extended components owned by domain teams under DS review, and Experimental components that live in a contribution sandbox before promotion.

The RFC process is the most important governance tool. It's the public, searchable record of every structural decision — why a prop was named a certain way, why a pattern was deprecated, what the migration path is.

Opinionated about tools.
Flexible about process.

I have strong opinions about tools — not because I'm attached to them, but because the wrong tool creates friction that compounds over time. The right stack disappears.