Design systems, Figma to production
A design system is only real once it ships. I build them across both halves: the Figma side — tokens, components, variants, documentation — and the production side — a typed, accessible React component library that consumes the same tokens. One source of truth, no drift between the design file and the code. When the design changes a token, every component picks it up; when an engineer extends a component, it stays on-system.
- Design tokens: colour, type, spacing, radius, motion — one source of truth
- Figma libraries: components, variants, auto-layout, documentation
- Typed React component library with stable, documented APIs
- Accessibility built into every primitive (WCAG AA)
- Token pipeline: Figma variables → CSS variables → Tailwind theme
- Developer handoff: annotated specs, usage docs, contribution rules
- Design consistency enforced by tokens, not by convention
- Versioning and safe evolution as the product grows
Shipped work for the same brief.
- 2023NextDoor — design system for handoffA component system built for direct engineering handoff, with the information architecture simplified from four navigation levels to two and trust signals systematised across the app.FigmaDesign SystemComponentsHandoff
- 2026himanshurawat.in — this siteToken-driven design system: CSS variables mapped to a Tailwind theme, server-first components, and design primitives that stay consistent across every page and route.Design TokensTailwindReacta11y
- 2024Webiosis — reusable component patternsIntroduced reusable React component patterns across product surfaces that cut duplication and made the design system coherent across teams.ReactComponent LibraryDesign System
A design system that lives in one file and a hundred components.
Most design systems die in the gap between Figma and code. The design file says --space-4 is 16px; the codebase hardcodes 16pxin forty places; six months later they've drifted and nobody trusts either. A real design system closes that gap with a single source of truth that both sides consume.
Tokens are the contract
Colour, type scale, spacing, radius, and motion live as tokens — Figma variables on the design side, CSS custom properties mapped into the Tailwind theme on the code side. A component doesn't know what “black” is; it knows what --foreground is. Change the token once, and the design file and every shipped component update together.
Components with typed, stable APIs
Each primitive ships as a typed React component with a documented API — discriminated-union props where a component has variants, no any, no prop that silently masks a missing value. The API is the same shape a designer reasons about in Figma, so the two representations stay legible to both audiences.
Accessibility per primitive
Accessibility is solved once, at the component level: focus rings via :focus-visible, correct ARIA roles, contrast that meets WCAG AA, and motion that honours prefers-reduced-motion. Every team that uses the system inherits accessible behaviour for free.
Handoff and evolution
The system ships with usage documentation, contribution rules, and annotated specs so the next engineer extends it without a rewrite. It's versioned to evolve safely as the product grows — the Figma-to-React workflow covers how individual screens get built on top of it.
The test of a design system isn't how it looks in Figma. It's whether the fiftieth component an engineer adds, months later, still looks like it belongs.
What founders ask before reaching out.
What does a design system include?
Design tokens (colour, type, spacing, radius, motion), a component library with documented APIs, accessibility built into each primitive, usage and contribution documentation, and a token pipeline that keeps Figma and code in sync. The goal is one source of truth both designers and engineers consume.
What are design tokens and why do they matter?
Design tokens are named values — like --space-4 or --foreground — that replace hardcoded numbers and colours. They matter because they're the contract between design and code: change a token once and every component updates, which is what prevents a design system from drifting out of sync over time.
Can you turn our existing Figma library into a real component library?
Yes. I map your Figma variables and components to a typed React library that consumes the same tokens, so the design file and the code share one source of truth. If the Figma side has gaps or inconsistencies, I flag and resolve them as part of the work.
How do you handle accessibility in a design system?
Accessibility is solved at the primitive level — focus-visible rings, correct ARIA, WCAG AA contrast, and reduced-motion support — so every product team that uses the system inherits accessible components by default instead of re-solving it per feature.
Do you build for handoff to our engineers?
Yes. The system ships with documented component APIs, usage examples, contribution rules, and annotated specs so your engineers can extend it without breaking consistency. The whole point is that it survives after I'm gone.
Which tools and stack do you use?
Figma (variables, components, auto-layout) on the design side; React, TypeScript, and Tailwind with CSS custom properties on the code side. The token pipeline maps Figma variables to CSS variables to the Tailwind theme so the two never diverge.
Let's see if it's a fit.
30-minute call. No pitch, no slides. Tell me what you're building, including the AI parts, and the constraints. I'll tell you if I can help, and who else to call if I can't.