Design Engineering
AI-Assisted Design Systems
Legacy components had drifted across Optmyzr's product — inconsistent props, hardcoded values, no shared system. Each new component is audited, spec'd, built, and validated in Storybook using Claude Code, with every visual value traced back to a foundation token.

Team
4 Designers, 1 Engineer
My Role
UX Designer
Duration
2 months
Tools
Storybook, Claude Code, Github, Figma
Overview
Challenge
For years, the same component could look and behave differently depending on which page it lived on — small fixes piling up instead of one shared standard, across 20+ pages of the product.
Inconsistent components: The same kind of component looked and behaved a little differently on every page it appeared on, as small fixes piled up over time instead of following one shared standard.
Outdated docs: What the system's documentation said existed and what had actually been built didn't always match — so knowing what was really there meant checking the code, not the docs.
Limited design library: Figma only had a small set of components to draw from — so when a designer needed something new, they'd build it directly into the feature file instead of adding it back to the shared library. Nothing kept everyone in sync.
Guesswork at handoff: Without an exact spec to build from, engineers often had to guess at spacing, color, and behavior when turning a design into code — so small inconsistencies crept in every time.
Solution
A token-only, spec-first workflow with Claude Code. Every component starts with an audit of how it's actually used, gets written up as a simple spec, then built and checked in Storybook before it ever reaches engineering. Handoff gets easier too — engineers can pick up the component's code directly from Storybook, with controls for each use case already built in, so they can wire it up without guessing.
The Workflow
Design and engineering used to build the same component twice — once in Figma, once in code — with a lot getting lost in between. Bringing Claude Code into the process changed that: instead of a spec disappearing into a handoff document, design could work directly inside the same codebase engineering builds from, going straight from spec to a working, validated component. Here's how that happened, step by step.
1. Setup
The design team sat down with an engineer to understand the codebase, who then connected GitHub to Claude Code — giving it full visibility into the same React codebase engineering builds from. One file, CLAUDE.md, kept in the repo, carried the project's permanent coding rules. A second file, pasted at the start of every session, gave Claude Code the fuller context of the design system itself. Together, Claude Code understood the codebase almost as well as the engineers who built it.
2. Divide the work
A 4-designer team split the components and foundations among themselves, each working in their own branch off one shared base — so four people could build in parallel without stepping on each other's work. Twice a week, the team synced on a call — each designer presenting their component while the other three reviewed and gave feedback.
3. Audit & Spec
Before anything gets built, the legacy version is checked against real usage — not just the code, but where and how it actually appears across the product. That gets written up as a full spec — what the component supports, what it drops, and why — before any prompt asks Claude Code to build it.


4. Build
Each designer prompts Claude Code directly, describing what the component should do and how — Claude Code then builds and updates the component from that spec. If a value it needs doesn't exist yet — a color, a spacing rule — that gets added to the shared foundation first, as its own commit.

5. Review, Merge & PR
Each component is checked in Storybook — across backgrounds, states, and placements — then committed before merging into the shared branch, with a note in Slack so the team knows it's ready. Once everyone's work was in, the shared branch went up as a single pull request for engineering review.

Components Rebuilt Glimpse
ATOM
Tooltip
Previously a single dark-background style regardless of the page it sat on, sometimes without even a pointer to show which element it belonged to.
Rebuilt with surface-aware variants (light/dark) and defined use cases — informational, error, success, and link-based — so users always know what triggered the tooltip and what it's telling them.

ORGANISM
Date Picker
Previously a nested dropdown menu — Day, Week, Month, Business, each opening its own submenu — with custom ranges typed into a separate modal with no visible calendar.
Rebuilt as one unified component with the calendar always visible alongside start/end fields, cutting a multi-click menu chain down to one direct interaction.

PATTERN
Filter Left Panel
As the team's first component, Filter panel still began in Figma before the process moved fully into Claude Code — proving a Figma-designed component could translate directly into a Storybook-ready build. The rebuilt panel adds fuzzy search and grouping across Campaign, Networks, and Devices views.

Storybook Glimpse ↓

Outcomes
34+ design system components built and updated via dedicated branches, connecting Storybook to Claude Code with GitHub access for review.
Design-to-dev handoff time cut by 64% — components arrive validated in Storybook, ready for engineers to pick up directly.
Usage per session on the Filter panel rose 35% after the rebuild, as fuzzy search and grouping replaced scrolling through a long list.



