Custom Design System
A from-scratch design system — foundations, components, and a Figma → Storybook handoff
Overview
A fully custom design system built from the ground up to unify product design, brand, and engineering under a single source of truth. I led the system end-to-end — from foundational tokens (colour, type, spacing, radius, motion) to a full component library with dark mode, accessibility annotations, and a working Figma-to-Storybook handoff pipeline. The system shipped as the visual and behavioural backbone of every product surface — web, mobile, and back-office.
The Problem
The team was rebuilding the same patterns — buttons, inputs, toggles, toasters, menus — independently across mobile, web, and admin surfaces. The same primary button existed in 6 visual variants. Designers were duplicating Figma libraries; engineers were re-implementing CSS that already lived elsewhere. There was no shared language between design intent and engineering implementation, which meant every product update reopened the same conversations.
The Goal
Build one design system that absorbs every existing pattern, enforces consistency through tokens rather than rulebooks, ships with a working Figma library + Storybook, and reduces design-to-engineering handoff to a copy-paste workflow.
Design Screens
Key interfaces
Design Process
How I approached it
Audit & Foundations
Catalogued every UI pattern across the product surface — buttons, inputs, navigation, feedback states, modals — and mapped them against intent and usage. Defined the brand foundations next: typography scale (H1–H4 + body + caption), an 11-step neutral ramp, semantic colour roles (action, info, success, warning, danger), 4-pixel spacing scale, 6-step radius, motion easing, and 5 elevation shadows.
Token Architecture
Built a 3-tier token system in Figma Variables — global tokens (raw values), semantic tokens (intent), and component tokens (per-component overrides). Light and dark mode were modelled as a single semantic layer with swappable global maps, so every component automatically respects theme without per-component variants.
Component Library
Designed the full component set — Button (6 variants × 4 sizes × 4 states), Input, Checkbox, Radio, Toggle, Toaster (4 intent types), Left-hand navigation, Modals, Dropdowns, Tabs, and Empty/Loading states. Every component shipped with documented props, interactive variants in Figma, and matching accessibility annotations (focus order, ARIA roles, keyboard map).
Engineering Handoff
Worked side-by-side with engineering to build the matching React + Tailwind component library and a Storybook instance documenting every variant. Tokens were exported from Figma Variables to CSS custom properties via a small script, keeping design and code aligned without a build step in between.
Research Findings
Key insights
A design system isn't a Figma library — it's a contract between design and engineering. Naming tokens by intent (`color-action-primary`) instead of appearance (`blue-500`) was the single biggest lever for long-term maintainability.
Dark mode through a semantic layer (not per-component variants) means components 'just work' when theme changes. We never had to maintain two component sets.
Toasters and empty states were the most-skipped foundational work — but the moment they shipped, every product flow felt 30% more polished without anyone redesigning anything.
Adoption is a function of friction. Once Storybook went live with copy-paste React snippets, engineering pull requests started referencing it unprompted within two weeks.
Outcome
The result
Shipped a complete custom design system covering foundations, 30+ components, dark mode, accessibility annotations, a working Figma library, and a matching Storybook instance. The system became the default visual + behavioural language across every new product feature — design-to-engineering handoff conversations collapsed from hours of spec review to a Storybook link.