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.

Yellow Flower

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.

Create a free website with Framer, the website builder loved by startups, designers and agencies.