Users live in a paradox
PPC experts managing $10,000+/month budgets need automation to scale, and distrust it because it has burned them. They demand control because the platforms took it away.
AI built the components. Designers built the system.
Optmyzr's design language had fragmented as the product scaled. The usual fix, where designers spec in Figma and engineers rebuild it in code, needed the one resource the company had least of: engineering bandwidth. So we changed who builds. I turned the system into instructions Claude Code can follow, and four designers shipped the production component library themselves.
17 → 4Duplicate builds of 4 basic components, now one each
15 in 5 daysProduction patterns shipped by four designers
~3 daysDesign to production-ready code for smaller features and changes, down from weeks
30-second version
A codebase audit found 5 button components, our most-used dialog living in 303 files with no canonical spec, selects scattered across 500+ files, 6 date pickers, and 3 loading patterns: 17 different builds of the same 4 basic components. Engineering bandwidth was the scarcest resource in the company, so the usual handoff loop was the one fix we could not afford. I derived six design principles from business strategy, rebuilt the foundations as a WCAG-compliant token system, built ChromaCheck to enforce accessibility, and consolidated it all into ods.skill.md, instructions Claude Code follows on every task. Four designers then shipped 15 production patterns in one week. Engineering's only cost was code review, and smaller features now go from design to production-ready code in about three days instead of weeks.
Section 1 · Why this started with strategy, not components
A component library in search of a reason is how design systems die.
I did not want a prettier button. I wanted a system that could defend its decisions to designers, to engineers, and to founders deciding whether to fund it. So before drawing anything, I went through three business documents (market positioning, brand guidelines, customer strategy) looking for the truths that should shape an interface. Three kept surfacing.
Four roles, one system
The Doer needs dense bulk operations. The Planner, cross-account analytics. The Executive, overviews. The Owner, efficiency visible on a margin sheet.
40% Creator · 40% Ruler · 20% Hero
The brand's personality mix, in interface terms: not consumer software (too playful), not enterprise (too bland). Professional tools for experts who value craft.
From those tensions came six principles, each traceable to a documented pain point rather than an aesthetic preference:
01Clarity over decorationIn 200-row tables scanned for budget overruns, visual noise is financially dangerous.
02Transparency builds trustNever a black box: show calculations, reveal sources, acknowledge uncertainty.
03Users stay in controlEvery automated action is transparent, adjustable, reversible. Alert and suggest; never auto-apply.
04Dense but scannableMaximum relevant information, carried by hierarchy and grouping, not whitespace.
05Simple first, depth availableDefaults that work out of the box; power for those who want it.
06Accessible by defaultFoundational, not an add-on. Every component works for users of all abilities from day one.
Each principle ships with an audit of live product screens, marked follows / partially follows / violates, reasoning written out.
Section 2 · Foundations
The unglamorous 80%.
Colour took the longest, and the manual work was the point. AI can generate a palette in seconds; it cannot tell you which shade of red survives next to brand blue in a dense campaign table viewed by a deuteranopic user. Every token was tested against real screens until the entire palette was WCAG-compliant by default, not by exception.
Typography was a constraint decision, not a taste decision. We stayed on Roboto. It already covered our multilingual product, at zero migration cost. The leverage was in the scale: base size moved from 14px to 13px, a direct consequence of Dense but Scannable. Our users make financial decisions while scanning hundreds of rows, and that density is worth more to them than airiness.
Roboto stays14px → 13px baseSpacing · stroke · radius · opacity tokens
Then I made the accessibility principle enforceable. "Accessible by Default" is easy to write and easy to ignore, so I built ChromaCheck, a published Chrome extension that simulates eight types of colour-vision deficiency on any page and runs a full WCAG contrast audit. Click a failure and it jumps you to the offending element. It kept the ODS palette honest during foundation work, and it is now part of how the team ships every screen.
Section 3 · The bet, and the enabler
Change who builds.
With foundations committed, three decisions, made up front and taken to the founders, defined everything after.
Parallel-build
The MUI product keeps running, untouched. ODS is built fresh alongside it: no bridge code, no legacy compromises inherited.
Forward-only
Everything new is built on ODS from day one. No migration mandate for old pages. This is what made the project fundable: it asked engineering for nothing.
Code-first, no Figma layer
Every pattern folder holds the spec, the working component, and usage examples. The artifact engineers consume is the artifact designers produce. Nothing is lost in translation because there is no translation.
The bet, stated plainly: designers can own component production if the system itself teaches the AI how to build on-system.
The enabler is a single file: ods.skill.md. Six principles, naming conventions, the pattern format, and compliance checks, consolidated into instructions Claude Code follows on every task. Without it, four designers prompting independently produce plausible, generic, off-system output. With it, the default output is on-system: right tokens, right file structure, right accessibility baseline. Four designers read like one author.
One traced example, the Button. The audit had found five fragmented components:
ButtonOButtonIconButtonButtonWithTooltipButtonWithDropdown
I specified intent, not implementation
One canonical Button, six variants, each with an explicit job: Primary is "max one per view." Danger is "destructive confirmations only, reached via an explicit confirm step." Tooltip becomes a prop, not a wrapper component.
Claude Code produced the component
The .tsx, the docs, and the usage examples, in minutes rather than the days of hand-coding that kept component production out of a designer's reach in the first place. Because the skill file told it how, the draft arrived already on-token and in the pattern format. That is the whole trick: designer time goes to the one part AI cannot do, which is judgment.
I adjudicated what the model gets wrong by default
Focus ring on :focus-visible only, so keyboard users see it and mouse users don't. A real <button> element, so roles and focus come free. Icon-only buttons require aria-label, and since code alone can't enforce that, the compliance check flags it for human review.
Section 4 · The build week
Four designers, fifteen patterns, five days.
I proposed a focused week to the founders. The scope came straight from the audit: their priority list, plus seven foundations I argued for because everything else stands on them. Each designer owned a coherent slice, and audited the atoms their slice depended on before touching a pattern.
Slice 1 · Actions & overlays
The things users click.
The canonical Button and its six variant jobs, plus everything that sits on top of a screen.
ButtonTooltipDialogEmpty State
Slice 2 · Form inputs
The things users type into.
The select alone had been living in 500+ files; the date picker had six competing implementations with locale inconsistencies.
Text InputSelect, 3 variantsDate PickerLoading States
Slice 3 · Data display
The things users scan.
The heart of a data-dense product. The table system deliberately got extra room beyond the week.
TableStatCardMetricValueDataToolbar
Slice 4 · Structure
The frame everything sits in.
Layout, headers, and tabs, plus the demo screen that would face the founders mid-week.
Page LayoutPage HeaderTabsDemo screen
Two things kept the quality bar real. A definition of done with teeth: complete docs, a working component, two usage examples, zero raw hex codes, and a review by another designer, with an explicit rule that twelve finished patterns beat fifteen half-finished ones. And Thursday cross-review, where every designer reviewed two other slices. Catching drift on Thursday instead of in an engineering PR is the whole point of the ritual.
Demo screens built entirely in ODS went in front of the founders during the week itself and were live in about a day. Fifteen patterns landed, roughly 70% of the core coverage the audit called for, with the hardest one deliberately given a week of its own.
Section 5 · The table sizing model
The judgment showcase: a table professionals trust at 200 rows.
Optmyzr is a data-dense product for people managing real money. Tables are the product, and they are where design systems usually go to die. I owned this one deepest. The model: every column declares exactly one sizing role.
01FixedCheckboxes, action icons. Token width, never measured.
02DeterministicCurrency, dates, percentages, IDs. Width comes from a format mask like
$9,999,999.99, never from the current data.03ElasticThe one identity column per table. Grows with content, clamped, ellipsis + tooltip, never wraps.
04FlexibleNotes, URLs. Absorbs leftover space with a two-line clamp.
A two-pass algorithm resolves intrinsic widths, then reconciles them against the container. For engineers: zero pixel widths, zero width logic. Declare a type; sizing follows.
Claude Code implemented the engine. The rules it would never have insisted on are the ones I spent the week fighting for. Columns never re-measure on sort, filter, or page change, and skeleton rows render at final widths so nothing shifts when data lands. Tables that twitch feel broken. A truncated number is worse than a scrollbar: when the numbers are ad spend, clipping a digit is a financial hazard, so the table scrolls instead, identity pinned left, actions pinned right. And selecting a row never shifts a width.
The table ships with Storybook composition stories and an interactive playground: living documentation, and the manual regression surface for every state the sizing engine can produce.
Section 6 · What changed
The loop is gone, not shortened.
The clearest way to show it is to put the two pipelines side by side.
Five handoffs, weeks per screen
Figma mock → founder approval → engineering rebuilds it in code → design checks the pixels ("does the build match the mock?") → founder sign-off again. Every arrow is a queue, and every queue waits on engineering bandwidth.
One handoff, about three days
Design builds the screen in ODS → pushes a PR → engineering code-reviews it → live. The design and the build are the same artifact, so the pixel-QA pass has nothing to compare. It is gone, not shortened.
The duplicate components are gone too. The audit had found 17 different builds of the same four basics scattered through the codebase: five buttons, six date pickers, three loading spinners, three generations of table. Each collapsed into one:
5 buttons → 16 date pickers → 13 loading patterns → 13 table generations → 1
How designer-written code earns trust. Four gates, in the order they fire:
01The skill file checks at generationZero raw hex codes, the pattern format, the accessibility baseline. Built into the act of writing.
02Designer cross-reviewA designer from a different slice checks tokens, keyboard behaviour, and consistency with sibling patterns.
03StorybookEvery state on display. The living docs, and the manual regression pass.
04Engineering code review, the hard gateEngineers review every PR. Each recurring comment becomes a skill-file rule, so the next component doesn't repeat the mistake.
Keeping it coherent. The skill file has one owner, and edits to it go through the same PR review as components. Docs never trail code: a pattern change updates its pattern.md in the same PR. And forward-only means additive: a breaking change is a redesign, not a patch.
What this story does not claim. This is an internal velocity story, deliberately. The customer-facing payoffs (one visual language, WCAG by default) compound downstream, and I am not claiming them as measured outcomes yet.
What I'd do differently. Write the skill file first, not mid-stream. It was the highest-leverage artifact and should have been deliverable #1. Lock the demo screen with the founders on day zero. And pair forward-only with a migrate-on-touch rule, so old pages convert when they are edited instead of waiting for a bandwidth miracle.
Engineering now starts from working, reviewed code instead of a static mock. The design is the build.
The steady-state workflow, and the point of the whole thing