DESIGN SYSTEMS AND UI KITS
One set of decisions, applied everywhere, documented once.
A design system is not a page of swatches. It is the set of decisions you stop re-making: the type scale, the spacing step, how many greys exist and what each one is for, what a disabled button looks like, what happens at 360 pixels. When those are written down, four people build screens that look like one product. When they are not, every new screen is a negotiation.
I deliver the system as CSS custom properties or Tailwind theme config plus real React components, not a Figma file nobody can compile. Every component ships with its states — default, hover, focus-visible, active, disabled, loading, error, empty — because the states are where handovers fall apart. Dark mode is defined as token overrides, so a new colour is one line, not a hunt.
Accessibility is part of the spec rather than a later audit: 4.5:1 contrast on body text, a visible focus ring that survives the reset, keyboard order that matches reading order, labels tied to inputs. I write the documentation at the same time as the components, so the kit arrives with a page per component explaining what it is for and when not to reach for it.
WHAT I DO
- Token set — colour roles, type scale with line heights, spacing step, radii, shadows, a z-index ladder, motion durations and easings
- React component library with every state built, not only the happy path screenshot
- Light and dark themes as token overrides on one root, defaulting to the system preference and overridable by an explicit choice
- Accessibility built into the components: contrast ratios, focus-visible styling, label association, sane keyboard order
- A living kit page rendered from the real components, so documentation cannot rot separately from the code
- Naming and contribution rules — what a new component must have before it is allowed into the set
- Migration notes for the screens that already exist and do not match the system yet
HOW I WORK
- 01
INVENTORY
Screenshot every existing screen and count the variants — the eleven button styles and nine greys are the argument for doing this at all.
- 02
TOKENS
Collapse that inventory into one decision per axis, defined as custom properties, with the dark-theme overrides written in the same pass.
- 03
BUILD
Build the components against the tokens, each with its full state set and its keyboard and contrast behaviour checked as it goes in.
- 04
DOCUMENT
Publish the kit page, write the per-component usage and do-not-use notes, then rebuild two real screens with it to prove the set is complete.
BEST FOR
- Products where more than one person builds screens and those screens are visibly drifting apart
- A brand with fresh identity work that now has to be expressed as actual interface decisions
- Sites about to add a dozen pages, where a kit first prevents a redesign later
- A codebase where dark mode was bolted on and now every new colour means three edits
NOT THIS
- Not brand identity. Logo, naming and positioning are brand solutions work; this takes an identity that already exists and makes it buildable.
- Not a finished website. A kit is parts — the assembled thing is the marketing sites and landing pages page or the platforms page.
- Not ongoing design-ops. I will work from your Figma and I document in code, but keeping a Figma library in permanent lockstep is a role, not a deliverable.
THE PROOF
Published case studies from digital experience work. Each one names the client and shows what was delivered.
STRAIGHT ANSWERS
REST OF DIGITAL EXPERIENCE
MAKE A
WISH.
Tell me what you're building. I'll tell you how loud it can get.
- /01
YOU WRITE
Tell me what you're building and what's in the way. Two lines is enough.
- /02
WE TALK
A 30-minute call, booked within 7 days. Real questions, no pitch theatre.
- /03
YOU GET A PLAN
Scope, timeline and an honest number, usually within a week.