Ofofo Design System: Keeping Design Decisions Human While AI Handles the Volume

The Problem

As AI design tools became widely available, teams started generating UI with them: fast to produce, visually plausible, but almost never right. The generated screens did not follow the user flow. They had no brand consistency. They were built without the decisions that make a design actually work. That created a two-step rework cycle: designers had to go back and fix the AI-generated output to match the real product direction, and then developers had to rework their implementation once the designer's corrections came through. The tools meant to speed things up were adding a loop nobody wanted. The real problem was not the AI. It was the absence of a system telling the AI what it was allowed to decide.

The Design Approach

So I set one principle for the whole project: the designer owns every decision that shapes how the product feels, and AI handles the volume around those decisions. Brand, hierarchy, flow, the values in the token system, the states a component needs, all of that stayed with me. Repetitive scaffolding, variant generation, and code conversion went to Claude. The library is essentially that principle made enforceable: one token system, one source of truth, usable by designers in Figma and engineers via npm. Three design decisions made it hold. Tokens before components. I defined the token system first, colours, spacing, radius, typography, a z-index scale, so every later component was assembled from named decisions rather than ad-hoc values. Zero raw hex anywhere in component code. Dark mode and any future rebrand become configuration, not a refactor. Primitives before patterns. Every component starts as an atom: the smallest, most self-contained primitive with no dependencies on other components. Buttons before button groups, inputs before form layouts, avatars before avatar stacks. This is sound component architecture, and it also fences in the AI: given a strict primitive layer, Claude cannot reach for a component that does not exist yet or combine things inconsistently. Composed patterns were only built once the primitives they depend on were locked. Parity as a rule, not a hope. Every Figma component maps one-to-one to what the code exposes: same prop names, same states, same hierarchy. Designers and engineers read the same system from two different doors. Accessibility was a commitment from the start, not a retrofit. Radix UI primitives handle focus, keyboard navigation, and ARIA wiring under the hood, and every motion-bearing component accepts a reducedMotion prop so the library respects user preferences by default.

The Workflow, Phase by Phase

With the principles set, Claude Code became a collaborator at each stage while every visual and architectural call stayed with me. Figma with Claude. Rather than starting from a blank artboard, I used Claude to scaffold component variants in Figma from the token system, generating the repetitive structure (size variants, state variants, interaction layers) so I could spend my time on judgment: spacing, hover and focus states side by side, hierarchy across the full size range. The result was a 7-page Figma library covering Foundations, Buttons and Actions, Form Controls, Feedback and Display, Cards, Overlays, and Navigation and Layout. Figma to code. Once the library was stable, Claude Code converted the designs to React 19 and TypeScript (strict) components, with Tailwind CSS v4 for the token system and Radix primitives underneath. The motion system is spring-based and lives in hooks under src/lib/, not inline in JSX, which keeps components testable. The conversion runs at roughly 90% accuracy out of the box; the remaining 10% is always intentional, the motion tuning, accessibility edge cases, and composed-pattern logic that needs human judgment. Hosted docs. The library needed a live reference, so I built one with Vite and React on Cloudflare Workers. Each page renders the actual component, not a screenshot, and the docs surface is driven by a typed registry.ts so docs and code cannot drift: any change to a component's API forces a docs update. Live at ofofocomponents.ofofo.workers.dev. Publishing to npm. The final step was making it usable in any React project. Published as @ofofo/components, it ships ESM and CJS builds, full TypeScript types, and a Tailwind preset so consumers get the complete token system without copying anything.

Bash

npm install @ofofo/components

Tsx

import { Button, Input, Modal } from "@ofofo/components";
import "@ofofo/components/style.css";

What Shipped

146 base UI components covering every primitive: Button, Input, Textarea, Select, Checkbox, RadioGroup, Toggle, Alert, Avatar, Card, Modal, Tooltip, Popover, Accordion, Tabs, Table, DropdownMenu, Progress, Skeleton, Slider, and more. 120 composed patterns built on those primitives: DataTable with row selection and pagination, StatsCard with sparkline and ring variants, AppCard, ComplianceCard, SiteNavbar, FeatureCard, BlogCard, TestimonialCard, CtaBanner, FaqSection. Token system with 23 color variables across light and dark modes, 12 spacing and radius variables, a z-index scale from overlay to toast, and a 7-step type scale. Figma library with variants matching the React API exactly: Button (32 variants), Avatar (40), Label (30), StatsCard (6), AppCard (5), Modal (4), Toast (5). Generative UI components are now in active development: components that accept a data schema and render the appropriate UI layout without manual wiring. The goal is to let Claude generate full product screens from structured input, with the design library as the constraint that keeps output on-brand and consistent.

Platform Evolution

Jan 2026

Problem identified

Teams were using AI tools to generate UI screens: fast to produce but never right. Designers spent time correcting AI output, then developers reworked after. The tools meant to speed things up were creating extra loops. Decided to build a structured design library to change how AI fits into the workflow.

Feb 2026

Research and token planning

Audited existing UI across Ofofo's surfaces to identify inconsistencies. Defined the token system: colors, spacing, radius, typography, z-index scale, and shadow values. This became the foundation everything else would be built on.

Mar 2026

Figma library with Claude

Used Claude to scaffold initial component variants in Figma based on the token system, then refined each one directly, adjusting states, spacing, and hierarchy by hand. Built a 7-page library covering all core component categories.

Apr 2026

Figma to code via Claude Code

Claude Code converted Figma designs to React 19 and TypeScript components. Radix UI handles accessibility primitives. Tailwind v4 tokens map 1:1 with Figma variables. Motion system built as reusable hooks.

May 2026

Docs site and npm publish

Deployed a live docs site on Cloudflare Workers where every component renders for real. Published @ofofo/components to npm with ESM and CJS builds, full TypeScript types, and a Tailwind preset.

Now

v0.2.2 and generative UI

266 components across base UI and composed patterns. MIT licensed. Serving as the single source of truth across Ofofo's product surfaces. Generative UI components now in active development.

Expand generative UI layer

Build out a full generative UI component set: components that accept a data schema and render the right layout without manual wiring. Target is letting Claude generate complete product screens from structured input, constrained by the design library.

Lessons

A system, not a prompt, is what keeps AI on-brand The thing that fixed the rework loop was deciding what AI was allowed to touch. Tokens, primitives, and parity gave Claude a fence to work inside, and the output stayed consistent because the structure made inconsistency impossible.
Claude as a scaffolding tool, not a decision-maker The best use of AI here was generating repetitive structure: variants, prop scaffolding, boilerplate. Visual decisions, token values, and hierarchy stayed with me. AI handled the volume, I handled the judgment.
Token discipline saves time later Zero raw hex in component code from day one. Every color, spacing, and radius is a named token, so dark mode and rebrand work became configuration changes, not refactors.
Figma-code parity requires discipline, not just tooling Tools can speed it up, but parity only holds if you enforce it as a rule. Every change to a Figma component needs a matching code update and vice versa.
Docs that render the real component are worth the extra setup A docs site showing screenshots goes stale. One rendering the actual component cannot drift. The registry-driven approach paid back immediately when the first component API changed.
Radix under the hood is a cheat code for accessibility Focus trapping, keyboard navigation, and ARIA wiring are hard to get right and brittle to maintain by hand. Radix handles them correctly across every primitive, which freed the whole effort to focus on the visual layer.

FAQ

Keep human judgment on the decisions that shape how the product feels, and give AI the volume. Brand, hierarchy, flow, and token values stay with the designer; scaffolding, variants, and code conversion go to AI. The token-first, primitives-first structure is what makes that split enforceable rather than aspirational.

Two main things. In the Figma phase, it scaffolded component variants from the token system I had defined, handling size and state variants so I could focus on refinement. In the code phase, it converted Figma designs to React: generating structure, wiring Radix primitives, applying Tailwind tokens, and building the motion hooks. All visual and architectural decisions stayed with me.

Accessibility on interactive components (focus trapping in modals, keyboard navigation in dropdowns, ARIA roles on toggles) is complex and easy to get subtly wrong. Radix handles all of that correctly and is actively maintained. Building it from scratch would have taken months of ongoing work. Radix let me focus on the token system, motion, and visual layer instead.

Yes, by enforced rule. Any change to a component in code gets a matching update in Figma, and any structural change in Figma triggers a code review. Claude Code can generate a code update from a Figma diff quickly, which makes the habit easy to keep.

Yes, it is MIT licensed. Install with npm install @ofofo/components, import the stylesheet, and use any component directly. The Tailwind preset is optional but gives you the full token system if you want to write custom components that match the design language.

The primary target is expanding the generative UI layer: components that accept a data schema and render the appropriate UI without manual wiring. The aim is to let Claude generate full product screens from structured input, with the design library acting as the constraint that keeps everything on-brand. Beyond that, an interactive prop playground on the docs site and Code Connect wiring in Figma so developers can copy production-ready component code directly from inspect.