Case Study:Design System to Product Pipeline PoC

If the demo doesn't load, try refreshing the page. You can also open the project directly in StackBlitz.

Overview

After immersing myself in the study of AI-assisted design and development and their impact on design systems, I took the opportunity to embark on large scale learning exercise to get hands on and apply my learnings to a realistic DS-to-Product pipeline workflow. To demonstrate this process, I rebuilt parts of the enterprise design system (AXIOM) I helped build at Edward Jones from the ground up, taking the opportunity to make changes I had wanted to implement: a robust set of design token-based density themes to replace an incomplete set of density-variable components driven by props, and an architecture that favored flexibility and composability over strict governance.

To serve as the end consuming product in this proof of concept, I imported the completed tokens and DS components and built out a functioning prototype of a product enhancement proposal I had designed as part of a different role at Edward Jones.

Reimagining and Enhancing Design Tokens

Driving design elements from a three-tiered design token suite authored in the Design Token Community Group (DTCG) format was a direction we had already pursued in AXIOM. The biggest change I wanted to make was expanding the semantic token layer with the addition of a set of fixed and dynamic sizing and spacing scales, which would enable density themes.

The original DS had a small number of mostly form element components that rendered "condensed" versions based on prop configuration. With the new density aware sizing and spacing scales, I could offer sweeping, token-driven "roomy" and "condensed" themes across intercomponent surfaces and page level layout surfaces.

In addition to the fully realized density themes, I also set up a small "dark" token collection I could use for high contrast page sections. These created the scaffolding for expanding to a full-fledged Dark Mode theme in the future, something we never got to implement in the original.

Other Enhancements

Taking a cue from the existing "response" color collections, I added similar intent-based token collections for primary actions, disabled states and more, and used these to remap to other semantic collections and to component-level tokens.

Finally, I wanted to make at least some use of the DTCG format's "description" field, to provide instructional guidance to AI agents as well as any human readers.

I created the tokens using Token Studio Pro and exported them into Figma as variable collections. Separately, the full token suite JSON collection was set up as an input to Style Dictionary, which converted the tokens to CSS custom properties and plain JavaScript object properties for web, and Swift and Kotlin tokens for iOS and Android.

Rebuilding the UI kit Using Native Figma Slots

Having seen firsthand how an overly-strict and prescriptive component set can negatively impact system adoption, I was particularly excited to re-architect our components to be flexible and composable by default. This would theoretically have the added benefit of reducing or eliminating the need for a designer to detach a DS component, which would aid in accurately tracking adoption and usage metrics.

After rebuilding the component shells complete with density-theme-aware tokens, I took the opportunity to make use of a newer feature offered in Figma - component Slots. Using Slots, I could set up quick access to Preferred Instances of atomic or subcomponents or assets, giving designers the ability to design extended versions of the preconfigured and documented example components.

Composable-by-Default React Components

With the newly composable Figma components created, the next step was building the actual code components. Knowing that large parts of the developer community were familiar with and enthusiastic about the shadcn composable component library, I chose to build the components on top of the Radix library, the unstyled base layer for shadcn. This would give our React / TypeScript components out-of-the-box accessibility features, controlled and uncontrolled options for state management, and built in asChild support to enable applying our components' eventual styles to a passed in element if needed.

I chose TailwindCSS for our styling layer for its ubiquity across the developer community, similar to how I chose Radix via the shadcn connection. I also bet that that ubiquity and the exceptional documentation of both Tailwind and Radix would make them more easily digested and reasoned about by AI Agents, which I hoped to eventually prove at the end product level.

Building React TypeScript components with Claude Code and Figma MCP

To build the components, I set up a Figma Model Context Protocol (MCP) connection in Claude Code in the component library repo and pair programmed with Claude to build the component collection. While this greatly accelerated my development time, it came with many rounds of iteration and required frequent pushback to build and style the components correctly.

Claude wanted to heavily leverage React's forwardRef API, despite my repeated corrections that as of version 19, it was unnecessary and will eventually be deprecated. Similar repeated corrections were needed for layout styling issues, where Claude needed frequent guidance to prefer CSS Grid over Flexbox to achieve certain layouts.

Another interesting lesson learned surfaced in Claude choosing improper design tokens when applying styles. Having intuitively assumed that Figma was sending token names/ids in its MCP payload, I was surprised at how frequently Claude was choosing primitive layer tokens and applying them at the component level. Eventually, I learned that Figma was only sending token values, and that Claude was essentially searching the token-generated CSS for the first token custom property that matched that value which, at scale, would effectively undermine the cross-tier token mappings established upstream.

Continuous Integration, Unit and Browser Testing, and Storybook Documentation

To ensure all new work passed quality standards, I set up a continuous integration process. Every push and pull request to main runs a GitHub Actions design system pipeline that:

• checks code formatting.
• validates the design-token source (structure, mode parity, alias resolution).
• performs typechecks.
• runs unit tests (Vitest)
• verifies the Tailwind theme compiles.
• runs the Storybook stories as real-Chromium browser tests via Playwright.

Branch protection blocks merging until it passes.

Making the Design System AI Agent Ready

A major part of this effort was centered around expanding the consumer base of the original design system to include AI agents. To achieve this, I took care to start at the token level with intentional token naming and employing the DTCG "description" fields to provide guidance at a granular level.

On top of this, I created component spec files incorporating the original design system's component usage guidelines colocated with the respective component files in the repository. Claude Code could leverage these spec files when creating screens and extended components in the destination product test case.

To complete the circle, I added the spec file URLs to the corresponding component configuration descriptions in Figma, which allowed design agents to amass proper context when designing with the components.

A custom team-level skill in Figma helped the Figma Canvas AI Design agent prioritize and properly use the asset and component libraries, while persistent memory entries, CLAUDE.md guidelines and repository planning document decision tracking entries helped steer Claude Code in the right direction.

Consuming the Design System in a Product Feature Enhancement Proposal Prototype

Once the design system build was finished, I used it as the base layer to build out a functioning prototype of a largely complete existing design I had created for a feature enhancement proposal for the financial advisor locator experience on edwardjones.com. I worked with the Figma Canvas Design agent to finish up some loose design ends and to design a couple outstanding items, with varying degrees of success.

Where the system really shone, however, was in Claude Code, which demonstrated extremely high levels of fidelity when using design system components. This was in stark contrast to the non-DS elements in the feature enhancement proposal, which required multiple rounds of iteration similar to the initial build of the design system components, and proved that the agent-readiness steps in place worked as intended.

Up Next

Having completed the full design-system-to-product pipeline, I next plan on exploring how creating shareable plugins to deliver custom skills, subagents, documentation and more and push regular updates can help agents to get the details right and minimize drift.