02 · Case Study
Claude to Figma Design System
Claude is the source of truth for the Helixintel design system. Tokens, components, and patterns live there as structured data. From that single source, four things stay current automatically: a live Design Guide that makes the system visible, a Prototype Playground with functional HTML prototypes of real product flows, Figma frames for cross-functional review (and changes made there flow back), and the implementation spec engineering actually wants. One source. Four surfaces. Nothing drifts.
The problem
Most design systems break in the same way. The Figma file drifts from production. The spec doc goes stale. Prototypes get hand-built and never updated. Engineers ask clarifying questions in Slack because none of the artifacts answer them anymore. At Helixintel we needed something different. One source of truth for the whole system. Documentation that updates itself. Prototypes that are real, not just pictures of real.
The solution
Claude holds the design system as structured data. Tokens. Components. Patterns. Empty states. Every behavior the product might need. From that single source, four surfaces generate automatically and stay current.
The Design Guide renders the source visible. Every token, every component, every modal scenario, every empty state, live on a single HTML page the team can search, link to, and copy code from. The Prototype Playground proves the source is real. Functional HTML prototypes of actual Helixintel pages, built directly from the documented components. Click into one and you’re in a working approximation of the production app.
Figma stays as the collaboration surface. The latest components push to Figma frames for review. Designers iterate there. PMs and engineers comment there. Changes flow back into Claude. The team keeps working in the tool they already know; the source of truth stays current underneath them. Engineering gets the implementation spec they actually want. Tokens, classnames, conditional rules, accessibility requirements, all auto-generated alongside the prototype. The Figma frame shows design fidelity. The generated spec shows exact implementation. Both are always current because both come from the same source.
Claude as source
Every token, component, and pattern lives in Claude as structured data. Variants, states, accessibility rules, conditional logic, change history. Everything that defines the system is in one place. Queryable. Version-controlled. Durable. The spec isn’t a doc that drifts from the design. It is the design.
The Design Guide
Generated directly from Claude. The team opens one URL and finds every decision documented: colors with hex values, typography scales, every button variant, modal scroll scenarios with live demos, notification components with empty states, form field patterns. Each component is rendered live on the page, paired with the code that produces it. No searching across files. No wondering if the doc is current.
The Prototype Playground
Generated from the same source. Functional HTML prototypes of real Helixintel pages: Properties, Work Orders, Vendors, the Record Page. Click any prototype and you’re in a working version of the page with the exact patterns from the Design Guide. When a component updates in the system, every prototype using it updates with it. Prototypes that test like production.
Bidirectional Figma sync
Designers, PMs, and engineers collaborate in Figma. The system pushes the latest components into Figma frames for review. A designer iterates on a state. A PM flags a padding issue. An engineer notes a contrast failure. Those changes flow back to Claude automatically. The system doesn’t care where the change originated. It only cares that everything stays consistent. The collaboration tool stays where the team already works. The source of truth stays where it can do its job.
Engineering handoff
Engineering gets two surfaces side by side. The Figma frame shows the design fidelity they need to implement. The auto-generated markdown spec from Claude shows the exact tokens, classnames, conditional rules, and accessibility requirements. Both are always current because both come from the same source. The Slack questions stopped. Engineers stopped asking the design team for missing detail because the detail was already in the spec.
Research & approach
- 01 Identified the four artifacts that designers, PMs, and engineers all needed and that always went out of sync: the spec doc, the Figma library, the prototypes, the engineering handoff. The constraint was real. The way most teams handled it (manual reconciliation across all four) wasn’t scaling.
- 02 Built the design system inside Claude as structured component definitions. Tokens. Variants. States. Accessibility requirements. Implementation guidelines. Every decision captured as data, not narrative.
- 03 Generated the first visible surface: the Design Guide. A single HTML page that documents the whole system, with live component renders, code samples, and full search. The source of truth, made readable.
- 04 Generated the second surface: the Prototype Playground. Functional HTML prototypes of real Helixintel pages, built from the same component definitions. Clickable, navigable, real. The source of truth, made testable.
- 05 Wired Figma as the bidirectional collaboration layer and auto-generated the engineering spec. Components push to Figma frames; changes there flow back to Claude. The implementation spec generates alongside every prototype. Designers, PMs, and engineers stopped translating between artifacts.
Team & leadership impact
- Led
- Lead Product Designer at Helixintel, owned the system end-to-end
- Partnered with
- Engineering on the prototype rendering layer. Product on which prototypes to ship first. The broader design team on adoption and contribution patterns.
The handoff bottleneck closed. Engineers stopped pinging the design team in Slack days after a design shipped, asking for missing detail. They opened the prototype, opened the Design Guide, and got both context and code at once. Designers stopped maintaining the same spec in three places. The system became the spec.
What I’d do differently
We built the Design Guide first and treated the Prototype Playground as phase two. The team adopted the Design Guide quickly, but the conversation about what to prototype, how, and for whom didn’t start until much later. The prototype patterns we shipped (Properties, Work Orders, Vendors, Record Page) are the right ones now, but we got there by trial. Running it back I’d ship a single rough prototype the same week as the first Design Guide version, even with most of the system unfinished, just to anchor the second surface in real product context from day one.
Engineers stopped asking the design team where a token lived. The Slack questions about which version was current stopped. The system stopped being something we maintained on the side — it just regenerates whenever the source changes.