As Fringe’s first and only product designer, I built its first comprehensive product design system by working backward from the production product. I translated years of accumulated design and engineering decisions into documented foundations, components, patterns, and guidance that could support both people and AI-assisted workflows.
Role: Senior Product Designer — design systems, UX/UI, research, accessibility, documentation, AI workflows
The Challenge: Create a shared design foundation for a product that had evolved without a comprehensive system, while bringing design and production code into closer alignment.
The Outcome: A documented system of tokens, components, patterns, and guidance grounded in the production product—and structured so both people and AI-assisted tools could use the same source of design knowledge.
From production code to shared infrastructure
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.
Those decisions existed across production code, design files, and the accumulated knowledge of the people who built the product. The challenge was to uncover that structure, identify inconsistencies, and establish a shared foundation without losing what already worked.
I used Claude Code to analyze the production codebase, then translated those findings into foundations for visual design, interaction patterns, accessibility, product voice, and reusable components.
The goal wasn’t to replace what existed. It was to make the product’s underlying design decisions visible, consistent, and reusable.
partners: Frontend Engineering · QA / Accessibility · Product & Engineering
Timeline: 2026
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 better suited to 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.
Meanwhile, the existing product carried years of accumulated decisions: competing typography conventions, hand-picked colors, inconsistent spacing, multiple theming approaches, hardcoded behavior, and little documentation explaining the rationale behind how things worked.
An audit identified 165 production components, 156 of which were represented in Storybook.
Fringe didn’t need more components.
It 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 production codebase locally and set up a separate repository where I could develop design-system documentation without changing production code.
For the first time, I had a practical way to investigate the product using the same source engineering worked from.
I didn’t ask Claude to design a system for me.
I wrote the briefs based on my design-systems experience and research, provided 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 assembled into product experiences:
Foundations → Components → Patterns → Blueprints → Screens
That structure helped me understand how foundational decisions about color, typography, spacing, and other systems propagated upward into the patterns, structures, and product experiences 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
This 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 their 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 reasons things were different explicit.
FPDS adapts shared typography foundations to different product contexts, supporting expressive consumer experiences and denser administrative interfaces.
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.
Points History — FPDS in practice: The member-facing Points History dashboard brings account balances, transaction summaries, and detailed activity into a single experience. Reusable components and consistent visual hierarchy help members move between a quick overview of their points and the individual transactions behind those totals.
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.
My assumptions about existing color usage changed after I investigated where those colors were actually 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 wanted FPDS to help prevent accessibility issues, not check them 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 symptoms. A new design system gave us the opportunity to prevent those patterns from carrying forward.
The audit findings became requirements for FPDS and the product rewrite: semantic color relationships, explicit focus states, accessible icon buttons, required input labels, correct form grouping, and meaningful heading hierarchies. The documentation also identified issues that components alone couldn’t solve, such as accessibility requirements for vendor-supplied content.
Accessibility became infrastructure.
An accessibility audit of the FPDS color palette using the EightShapes Contrast Grid to evaluate foreground-background combinations against WCAG contrast requirements.
Then I gave the system back to AI
As FPDS evolved, I began thinking of it as something both people and machines would need to understand.
The design principles explicitly included AI agents in their audience, giving them a framework for evaluating design decisions at Fringe. FPDS also established a simple rule: 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 revealed something I hadn’t anticipated:
Claude Design was very good at showing me where FPDS was incomplete.
As teammates began prototyping, I could see decisions the system hadn’t adequately encoded.
Spacing needed more definition, so I built out the spacing system.
Motion varied without enough guidance, so I established motion principles, patterns, accessibility behavior, and distinct motion registers for Marketplace, achievement moments, and Practitioner experiences.
A left-rail navigation pattern I’d 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 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.
Illustrating how documented design decisions can inform AI-assisted implementation without requiring a separate Figma handoff.
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 how the team worked: Product ideas could move from exploration to engineering through a shared system of design decisions, without relying on me to translate every screen between tools.
FPDS connected foundations, semantic tokens, component behavior, and accessibility guidance into a shared design language.
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.
