Turning a production codebase into shared design infrastructure for designers, engineers, and AI
Fringe already had an established product and a large component library. What it didn’t have was a coherent system connecting the decisions underneath them.
I used Claude Code to help me understand the product as it existed in production, then built the Fringe Product Design System (FPDS): a shared foundation for visual design, interaction, accessibility, product voice, and AI-assisted prototyping.
As FPDS matured, it changed more than the interface. It changed how our team designed products.
My role: Product Designer · Design System Owner
Partners: Frontend Engineering · QA / Accessibility · Product & Engineering
Timeline: 2026
Scope: Design systems · AI-assisted design · Accessibility · Design infrastructure · Product design
We had components. We didn’t have a system.
When I joined Fringe, design and engineering had already begun looking for a UI framework that could give us a stronger shared foundation.
I was familiar with Tailwind through my previous design-system work, but our engineers wanted something that better supported their workflow. DaisyUI looked like a promising compromise: engineering liked working with it, and I believed I could build a design practice around the same foundation.
Once we adopted it, however, I discovered a problem. The design resources weren’t nearly as mature as the development framework.
Engineering could work with DaisyUI directly in the product. I had a much harder time understanding and representing the same system in design.
And underneath it, the existing product still carried years of accumulated decisions: competing typography conventions, hand-picked colors, ungoverned spacing, multiple theming approaches, hardcoded behavior, and little documentation explaining the design rationale behind how things worked.
The library itself wasn’t small. An audit found 165 production components, with 156 represented in Storybook. The problem wasn’t that Fringe needed more components.
The problem was turning what already existed into a system people could understand and trust.
Claude Code gave me a way into the real product
The breakthrough came during a Product & Engineering retreat.
I joined a group working with one of our frontend engineers to connect Claude Code to Fringe’s GitHub-hosted codebase. With her help, I cloned the existing product codebase locally and created a separate repository where I could develop design-system documentation safely without changing production code.
For the first time, I had a practical way to investigate the system from the same source engineering was actually using.
I didn’t ask Claude to design a system for me.
I wrote the briefs based on my own design-systems experience and research, supplied reference material that reflected the methodology I wanted to use, and directed Claude Code to investigate the existing implementation.
AI made it possible to inspect and organize the product at a scale that would have been impractical manually. I supplied the framework for evaluating what it found.
The first audits mapped Fringe at two levels: a detailed inventory of foundations and components, and a larger hierarchy showing how the system actually assembled into product experiences:
Foundations → Components → Patterns → Blueprints → Screens
That gave me a way to understand how foundational decisions in color, typography, spacing, and other systems propagated upward into the patterns, structures, and real product routes customers encountered.
I designed FPDS around decisions, not just components
The audit changed the question.
Instead of asking, “What components should be in our design system?” I could ask:
What does someone need to know to make a correct Fringe design decision?
FPDS grew around a three-layer architecture:
Primitives → Semantic tokens → Context overrides
Those decisions could then adapt across three dimensions:
Brand × Density × Appearance
That allowed one system to support very different product contexts.
The employee-facing Marketplace could remain warm, expressive, and spacious. The Practitioner experience could be denser, more restrained, and optimized for administrative work. Future partner brands could change visual expression without requiring us to fork the component system.
The goal wasn’t to make everything look the same.
It was to make the reason things were different explicit.
The system expanded beyond pixels
FPDS eventually governed much more than colors and components.
It included typography, spacing, radius, surface behavior, accessibility, interaction patterns, motion, voice and tone, product contexts, and detailed component specifications.
The documentation also distinguished between what existed in production, what FPDS defined as the target state, what had been deprecated, and what still required engineering decisions.
That distinction mattered.
For example, a Text Input specification could point to the actual production source, document the legacy implementation that still existed, define the intended DaisyUI-based behavior, identify accessibility requirements, and record implementation gaps instead of pretending the product had already caught up with the design system.
FPDS became less like a library of finished artifacts and more like a contract between design intent and implementation
Research was allowed to change the system
I didn’t want FPDS to turn existing assumptions into official rules simply because they already existed.
So I tested them.
A data-visualization palette I initially designed failed multiple color-vision simulations. I redistributed its lightness range and tested it again.
A typography weight I initially removed came back after testing real layouts showed that the remaining weight progression didn’t work.
Assumptions about existing color usage changed after I investigated where those colors were actually being used.
The decisions—and the corrections—stayed in the documentation.
That became part of the FPDS operating model: a documented decision could still be wrong. Evidence got to win.
Accessibility became a system problem
I also wanted accessibility to be something FPDS prevented, not something we checked after screens were designed.
I ran a WAVE audit across 14 Marketplace pages and three Practitioner/Admin pages, along with a separate audit of more than 300 semantic color combinations.
The most useful finding was that many accessibility problems weren’t really page problems.
They were system problems.
One Marketplace browse page, for example, contained 253 H1 elements—an unmistakable sign that heading semantics were being generated systematically rather than intentionally.
Fixing screens one by one would treat the symptom. A new system gave us the chance to prevent the pattern from carrying forward.
So the accessibility audit became a set of requirements for FPDS and the product rewrite: semantic color relationships, explicit focus states, accessible icon buttons, required input labels, correct form grouping, and a meaningful heading hierarchy.
Accessibility became infrastructure.
Then I gave the system back to AI
As FPDS evolved, I began thinking of it as something machines and people would both need to understand.
The design principles explicitly included AI agents in their audience, intending to give them a working understanding of design-decision evaluation at Fringe. FPDS also established the principle that an AI agent shouldn’t have to invent a value when the system could provide one.
Once enough of the system existed, I made FPDS available to Claude Design as shared product context.
That closed a loop:
I had used Claude Code to understand the product. Now Claude could use FPDS to understand how to design for the product.
Our team began using Claude Design for interactive product exploration: continuing the Practitioner Dashboard, refining its checklist, exploring an employee program builder, developing a Program Champion Kit and Full Fringe Sneak Peek, and refining the visual experience for our AI assistant, Frankie.
These weren’t generic prototypes prompted to “look like Fringe.” They could work from the same system I was using to evaluate them.
AI became another way to test the design system
The early prototypes also revealed something I hadn’t anticipated:
Claude Design was very good at showing me where FPDS was incomplete.
When teammates began prototyping, I could see decisions the system hadn’t adequately encoded.
FPDS spacing needed definition, so I built the spacing system.
Motion varied without enough guidance, so I defined motion principles, patterns, accessibility behavior, and different motion registers for Marketplace, achievement moments, and Practitioner experiences.
A left-rail navigation pattern I had designed kept changing whenever Claude generated it. Rather than correcting the rail in every prototype, I turned the pattern itself into reusable system guidance.
The feedback loop became:
Prototype → review → identify system gap → strengthen FPDS → prototype again
Instead of manually correcting every AI-generated screen, I could fix the source of the inconsistency.
Figma stopped being the required bridge to production
This changed my own workflow dramatically.
Traditionally, my product-design workflow translated ideas into Figma designs and interactive prototypes before engineering implemented them.
As FPDS and Claude Design matured, I spent less of my time producing screens in Figma. Figma increasingly became a place where I documented and refined the design system itself.
The team could explore an idea interactively in Claude Design. I could review the result against FPDS and provide design direction. Once I approved a direction, our frontend engineer could carry the work into production without waiting for me to recreate the prototype in Figma.
My role shifted toward system design, product direction, design approval, and QA.
I also taught the broader team how FPDS worked, how to prototype with it in Claude Design, and how to transfer work created in other AI prototyping environments back into our shared workflow.
The goal shifted from personally designing every screen.
The goal became making the system strong enough that I didn’t have to.
What FPDS changed
FPDS didn’t increase the number of production components. That was never the point.
It gave an existing product a governing system.
Design decisions became connected to production implementation. Accessibility requirements became part of the system instead of downstream remediation. Marketplace and Practitioner experiences could share infrastructure without being forced into the same visual expression. Decisions became versionable and inspectable in GitHub. And AI-assisted prototyping could work from real product context instead of inventing a plausible approximation of Fringe.
I don’t have a clean percentage for time saved or an adoption metric for the new workflow. We weren’t measuring the work that way.
The clearest outcome was visible in how the team worked:
Design intent no longer had to travel through a Figma file I personally created before it could reach production.
What I learned
The most important thing I learned wasn’t about tokens or AI tooling.
It was that a design system can encode much more than visual consistency.
It can encode judgment.
When the system captures not only which component to use, but why it exists, how it behaves, what context changes it, what accessibility constraints apply, what language it should use, and where its boundaries are, it becomes useful to more than designers.
Engineers can work from it.
Product teams can prototype from it.
AI can reason from it.
And the designer can spend less time translating the same decisions between artifacts—and more time improving the decisions themselves.
