From Figma to production with Claude or Cursor
A version of this workflow has been floating around design and engineering teams for years: build a design system in Figma, turn it into reusable components, design full pages, document the interactions, then hand it to a developer who translates it into code. The steps haven't changed since Claude Code and Cursor entered the picture — what changed is who's doing the translating, and how much of the ambiguity in the file becomes a bug instead of a Slack message.
Prepping the Figma file
None of this changes just because an agent is going to read the file instead of a person. If anything, it matters more, because an agent won't stop and ask a designer what a hover state is supposed to look like — it will guess, confidently, and move on.
1. Start with a design system, not a page
Define the color palette, type scale, spacing and layout grid, and tokens for things like shadows and border radius before designing a single screen. These are exactly what gets mapped into a Tailwind config later, so the cleaner they are in Figma, the less an agent has to infer.
2. Build components with every state
Buttons, inputs, cards, navigation, modals, dropdowns, tables, forms — each one designed with its hover, active, focus, disabled, loading, and error states included, not just the happy path. An agent generating a component from a single static frame will only build the state it can see.
3. Design complete pages
Home, about, services, contact, auth, error and empty states, each in mobile, tablet, and desktop layouts. A partial file forces the agent to invent the parts that are missing, and it won't invent them consistently across pages.
4. Document interactions explicitly
Clicking a profile opens a dropdown. Deleting something opens a confirmation modal. Mobile navigation slides in. Static screens can't carry this information — write it down, or better, prototype it in Figma, so the agent has something concrete to implement instead of a guess about what "feels right."
Turning it into code
This is the part that actually changed. With a well-prepared file, most of the manual translation work — reading a frame, guessing at spacing, eyeballing a hex code — can now be handed to an agent. The catch is that it only works as well as the file lets it.
1. Set up the foundation before asking for a single component
Next.js, Tailwind, shadcn/ui, and TypeScript is a reasonable default — it's what most of Kreets runs on. Map the Figma design system into the Tailwind config and CSS variables first: colors, typography, spacing, radius. Every component the agent generates afterward inherits these values instead of hallucinating its own.
2. Connect the agent directly to the Figma file
Both Claude Code and Cursor can talk to Figma directly through its MCP server rather than working from a pasted screenshot. That means pulling real design context — actual layout structure, spacing, and component hierarchy — straight from the file, and using Code Connect mappings so the agent knows a given frame corresponds to a component that already exists in the codebase, instead of generating a near-duplicate. A screenshot tells the agent what something looks like; the design context tells it what it actually is.
3. Build the shared layout before individual pages
Header, footer, navigation, and the responsive page shell go first, same order as the design system. Point the agent at the actual Figma frame for each piece and let it iterate against a screenshot comparison rather than a written description — it's a much shorter feedback loop than describing a layout in prose.
4. Review it like a pull request, not a demo
Once pages are built, close the loop the way you would with a human developer: compare the rendered page against the Figma frame side by side, check every breakpoint, and walk through the documented interactions one at a time. Ask for fixes to specific, named diffs rather than "make it match better" — agents respond to concrete instructions the same way people do. Accessibility and performance passes are worth their own explicit prompt at the end, not something to assume happens automatically along the way.
What actually changes
The steps are nearly identical to the pre-agent version of this workflow. What's different is speed — a clean design system plus a live connection to the Figma file means an agent can go from a documented frame to a working, on-brand component in minutes instead of a day. But that speed is entirely borrowed from the discipline in the prep work. The moment a file is inconsistent, a state is undocumented, or an interaction only exists in someone's head, the agent won't ask about it the way a developer would — it will fill the gap with its best guess and keep going. The workflow above was already the right way to prepare a handoff. With an agent doing the building, it stops being a nice-to-have and becomes the thing that decides whether the output is usable on the first pass or the fifth.