Process & Approach
How I Build.
Design systems aren't deliverables. They're infrastructure — and infrastructure requires a different kind of rigour than product design. Here's how I think about the work.
Audit before architecture
Never design a system before you understand the chaos it's replacing.
Tokens before components
The token layer is the contract between design and engineering.
Docs are a deliverable
A component without documentation is a time bomb.
Governance enables contribution
A system that teams can't contribute to will be ignored or forked.
Infrastructure first.
Components second.
Before opening Figma or creating tokens, I first study the organisation—what the system will touch: products, users, needs, and daily design-engineering collaboration.
Each system starts with a clear, shared understanding. Agree on tech stacks, tools, scopes—all informed by a UI audit (if there’s a product) and team or user needs. This is non-negotiable.
After the audit, I follow a strict sequence: tokens, components, patterns, documentation, governance. Skipping steps leads to debt and conflicts.
Discovery & Audit
Stakeholder interviews, UI audit across all surfaces, inventory of existing tokens and components.
Foundation
Token architecture, colour system, typography scale, spacing system, grid.
Components
Core components built in sequence, documented inline, shipped with working code.
Governance
Contribution workflows, RFC process, tier model, adoption metrics.
Decisions as data,
not documents.
Tokens are the most important, least understood part. Most see them only as a colour palette. But they’re also a machine-readable record of visual decisions.
Depending on the size of the project, I use a two or three-tier model: Primitive → Semantic → Component. Primitives are raw values. Semantics are named decisions. Component tokens are scoped overrides specific to each component or element.
This setup lets a multi-brand product suite be themed by changing only semantic tokens—no components touched.
Primitive
↓ referenced by
Semantic
↓ referenced by
Component
Anatomy first.
Variants second.
States always.
Every component follows the same steps: anatomy, default state, interactive states, size and semantic variants, edge cases, dark mode, and accessibility audit. Defining all states isn’t perfectionism; it means production-ready.
A name is like an API. When engineers write variant="primary" in 400 files, that name becomes permanent. Name every prop, variant, and token deliberately, with the component’s whole future in mind. Early communication with engineers is key!
Icon slot
Optional leading icon. 16×16px. Inherits button color. Never decorative — always meaningful.
Label
Required. Display font. Sentence case. Max 3 words in primary context.
Trailing element
Optional caret or status indicator. Muted colour. Never replaces icon slot.
Default
Hover
Focus
Disabled
Loading
Docs aren't a phase.
They're the product.
Nothing ships without complete documentation. That’s a quality bar, not just a policy. If a component isn’t documented, it doesn’t exist for teams. The author writes docs—never delegated. Documentation covers usage, props, accessibility, and edge cases.
Every example matches the real system, not old screenshots. The docs site includes live links to the component library.
Foundations
Colour
Typography
Spacing
Components
Button
Checkbox
Input
Modal
Button
Prop
Type
Description
variant
string
"primary" | "secondary" | "ghost"
size
string
"sm" | "md" | "lg". Default: "md"
disabled
boolean
Prevents interaction. Does not hide.
loading
boolean
Replaces content with shimmer state.
A system without governance
is a museum.
The hardest part isn’t components; it’s maintaining trust between DS and product teams. Governance builds that trust. Ownership is tiered: Core by DS, Extended by domains under DS review, and Experimental in the sandbox before promotion.
RFCs are the key governance tool: a public, searchable record of every decision—why props, patterns, and migrations happen.
Core
Owned exclusively by the DS team. Versioned, tested, fully documented. Button, Input, Modal, Toast.
Extended
Domain-team owned, DS-reviewed. Must meet contribution standards before merging.
Experimental
Sandbox for new patterns. No SLA. Can be broken. Can be promoted to Extended after two production uses.
Opinionated about tools.
Flexible about process.
I’m opinionated about tools—not out of attachment, but because the wrong tool creates compounding friction. The right stack is invisible.
Figma
Component library, token management with Variables, auto-layout, and Code Connect for Storybook parity.
Storybook
Component documentation, visual regression and interaction testing, code parity verification.
GitHub
RFC process, contribution workflows, changelog, and public record for all architectural decisions.
Claude Code
An agentic system is one that not only enables quick prototyping but also ensures the integrity and health of the system.