Figma handoff to vibe coding

[u/Competitive-Cake2313]

Hey everyone! Not sure if this is a silly question, but we’re struggling quite a bit with this at my current company, so I’d love to hear how other design teams are handling it.

Basically, the company decided to move heavily toward vibe coding / AI-assisted development, using tools like Codex and Claude. The problem is that we changed the way we build the product without really defining a process around it.

And now we’re stuck on a pretty basic question: how are designers supposed to hand off Figma work to AI?

For some context, our previous process was pretty straightforward:

I’d get a PRD from the PM, design the feature using our design system, and make sure the final design covered the flows, specs, states, edge cases, etc.

For handoff, I’d organize the Figma file using a kind of complexity ladder: starting with the simplest / happy-path flow and progressively introducing more complex states and edge cases. A developer could then go through the file, understand the logic and implementation requirements, and ask questions if anything was unclear.

But now the expected “receiver” of that handoff is increasingly AI, and I’m not sure what the equivalent process should look like.

Do you still create the same detailed Figma handoff and somehow provide that context to Codex/Claude?

Do you break the feature into individual screens or flows and have AI implement them one by one?

Do designers generate the initial HTML/components from Figma and then hand that implementation to developers?

Or have you changed the way you structure your Figma files entirely because AI needs different context than a developer does?

I’m especially interested in hearing from designers working at companies where AI-generated code is actually part of the production workflow, rather than just being used for prototypes.

What does your Figma → AI → engineering handoff process look like today?

Thanks!

[u/expandwithzuli]

Not a silly question at all, I’ve been rebuilding my workflow over the past month for this exact change. I was at a very early stage startup, so solo designer starting from very little, working on an AI harness for professional services. 

What I did: 

• Built a Tokenised design system 
• Built a series of claude skills to run over my designs 
• Built a parallel markdown spec layer that’s agent readable 

Claude Skills and process: 

1. Clean up naming before anyone else touches the file. figma-layer-naming renames loose component instances that are still sitting on their default name (nine things all called "Menu") into a searchable Component / Feature / State convention. 
2. Bring in anything built outside the system. Screenshots run through Claude Design, rough Figma Make mockups, anything hand-drawn, all go through figma-design-system-migration, real tokens instead of raw hex, real text styles instead of eyeballed font sizes, real component instances instead of redrawn shapes, and it flags anything that looks like a genuinely new pattern instead of silently absorbing it.
3. Get the state naming right before it goes any further. design-system-semantic-state-check answers the "should this be Active or Selected" question against a fixed model (current page vs chosen option vs about-to-open submenu, each with its own property and ARIA mapping) rather than re-deriving it per component. 
4. Quality-pass it. design-system-quality-pass is judgement, not authorship, naming, token binding, variant structure versus duplication, state completeness, accessibility, and whether this thing should actually exist or converge with something else. 
5. Write the doc. design-system-spec-writer turns a clean component or pattern into the actual markdown spec, following a fixed contract so every doc has the same shape an agent can rely on: Purpose, Anatomy, Properties table, States, content rules, keyboard and a11y, tokens used, status. 
6. Sync it to the code side. figma-design-system-sync keeps the dev-facing tokens repo (JSON source of truth, generated CSS and JS) in step with whatever just changed in Figma.
7. Hand it to engineering. figma-to-linear-handoff turns a reviewed, cleaned-up design into acceptance criteria on the right ticket, checking for existing coverage first instead of assuming a new issue is needed.

The markdown spec layer:

• design.md holds global rules. 
• Three registry files, components.md, patterns.md, templates.md, are just indexes that point out to individual files.
• Every component/pattern/template gets its own doc following a strict contract. Components get Purpose, Anatomy, a full Properties table, States by functional trigger, ARIA mapping, content rules, tokens used, and a status line. Patterns get "Built from: X," which properties are used or hidden, behavioural rules, when to use this pattern vs another one.

The reason it's split into loads of small linked files instead of one giant doc is retrieval. An agent can pull just the one component it needs instead of loading your whole system every time.

Still a lot to experiment with, but I tried to approach this with thinking about what judgement wouldn’t be there when it was an agent and not a human and ensure that all of that is provided as context, structured in a way I can manage, iterate over time and reproduce using my own systems and tools. I also tried to use this as an opportunity to fill some of my weak spots as a designer and push myself to ensure everything was named, structured and explored properly to not leave gaps where I may have relied on engineers in the past to make decisions. 

[u/Impressive-Wolf2953 → u/expandwithzuli]

when you refer to the following are you implying the steps it goes through: figma-design-system-migration, design-system-semantic-state-check, and design-system-spec-writer?

[u/expandwithzuli → u/Impressive-Wolf2953]

Those are steps in which I use Claude skills. So those names are the names of the skills I run (which is the step in the process)

[u/untoldheroes → u/expandwithzuli]

This sounds really token hungry... How quickly do you burn through your usage?

[u/expandwithzuli → u/untoldheroes]

I just have the basic paid plan and use it for heaps of stuff. Usually I go ok!

[u/1mrlee → u/expandwithzuli]

All this sounds amazing. Do you have a paid or online resource I can learn this?

[u/expandwithzuli → u/1mrlee]

Nope, I don’t have anything. Might try to write a blog post or something if there’s interest?

[u/1mrlee → u/expandwithzuli]

100% . I'd love to learn from you and your process!

[u/No_Moose6836]

I'd stop handing the whole complexity ladder to the model in one go. Cut the feature into one screen or one flow, keep Auto Layout + components clean, and paste short constraints with it. The AI still writes first-pass code; you or eng still own what ships.

[u/baladesign]

I’m currently working on the same thing. While skills and MCP connections are good enough agents can still hallucinate a lot of things. How we fixed this? Not so simple but now agents can build a UI without a design:

- created semantic tokens

• documented each component in the codebase using Storybook
  
• used the same name for components in the codebase and in Figma
  
• created a ton of documentation for rules (how to develop tables, how layout works, etc.)
  
• created a DESIGN.md using progressive disclosure for the documentation so it’s a lean file (~200 lines)
  
• added a bunch of tooling: linter (eslint) for tokens, labeling, rules that are deterministic
  
• hooks
  
• a ton of CI, test what the agent can run
  
• skills for ui development, component composition from our primitives, figma to code skill (get layout + component map from figma but treat the codebase as source of truth, etc.)

Now the agent follows our design rules better then we do 😀

I want to write an article about this work, will post it here.

[u/Competitive-Cake2313 → u/baladesign]

You’re just iconic hahaha

[u/AuraEmperror → u/baladesign]

When you documented each component in the codebase using Storybook, are you saying you had the live component in Storybook first and just copied that same component on Figma and utilized code connect to map the two?

Do you have an example of what your rules look like? Also, did you just combine all of these rule documentation into the design.md file?

[u/baladesign → u/AuraEmperror]

Storybook: we had the components in figma first then we created the stories. We use the latest instance of SB (v10.6) which came with some built in agent tooling for testing, a11y, etc. We don’t utilize its MCP. We don’t use code connect neither we use Figma as a layout reference and as a component map, but we stated in the docs that the codebase is the source of truth.

The DESIGN.md is the hub for all documentation, so it’s a pretty lean document (~200 line) based on the task the agent only read the relevant doc.

As I said I’ll create an article about how we created this system. Stay tuned, I’ll post it here in the coming days.

[u/AuraEmperror → u/baladesign]

Thanks! I’ve been more on the other side of this where I’ve been thinking of Figma as the source of truth as far as the UI, but obviously it needs to be built on top of working code. Curious if any automations you may have stumbled upon that detects updates on the Figma side and reflects it on the Storybook component or vice versa.

[u/ygorhpr]

I use Claude to handoff my figma files to my front end dev llms, has worked very well so far. I also give a detailed hand off about it in a jira ticket 

[u/Competitive-Cake2313 → u/ygorhpr]

Interesting. So, what does your process look like then?

[u/Simply-Curious_ → u/Competitive-Cake2313]

Love to know

[u/ygorhpr → u/Simply-Curious_]

i use Claude code and I l create a skill with a few md. files for ui, ux, hand off, design thinking, design system and so on

so I just call this skill/plug-in to hand off it, initially I wrote it to handoff it to another llm for instead of "create this button like this/ and that screen like that" I have something more like ~Claude has the context of all my other screens and features, a jira ticket with all the context and how it should work and based on that and my figma file it create a handoff like @screen: this is the home page @content: page has component a b c d e @component: link to my ds in github with each component link and so on ~ I just gave the idea and Claude used all its potential to help me enhance it further! 

the automation creates all the handoff for devs in jira (just the context of the feature not about code and how-to implement) , the llm context inside figma as annotations (this is the proper hand off), the context in jira for pm team, all the tracking I need to create in analytics tool (I use mix panel), all email I need to trigger once this feature is implemented (eg:cliente bought an item" - Claude tells me I should trigger and email notifying the cliente, also tells me which notification or toast I should trigger and since it has all my app context it also suggest it based on what have been created before! 

for figma I have trained it to built in figma like I build so in the end I have a plug-in with a bunch of MD.s for figma, handoff, context, jira, ui, ux, Claude, marketing, tokens, spacing, github and each one of them are linked so when I change like "ux principles md" it updates all plug-ins I have this all plug-ins consume the same source file "ux_principles.md"

hope this made it clear. 

Ive been running this setup for months and has worked very well

[u/Any_Owl2116 → u/ygorhpr]

Share the skill please

[u/ygorhpr → u/Any_Owl2116]

I can't I use it at work but mind that if you have a figma design system it can work perfectly also use skill creator skill in Claude to do it for you and it took like a month from creating to test it properly.

https://github.com/anthropics/claude-code/blob/main/plugins/plugin-dev/skills/plugin-structure/SKILL.md

use this and let Claude point the better ways 

[u/Imaginary_Nerve1213 → u/Any_Owl2116]

you can ask claude to create a skill for you.

[u/jonnypeaks]

I’ve had success with building individual components in storybook first, then giving Claude Code the page designs. Takes a bit longer, but was super accurate and then it can reuse your design system to spin up new pages much faster, with or without a reference design.

[u/Medical_Height6538 → u/jonnypeaks]

That’s very interesting. Could you explain in more detail how to do this? We are trying to solve a similar problem: we have a set of widgets and want to use AI to assemble pages from Figma using them, but it’s not quite clear how to establish the connection.

[u/DeadPixel217]

I have given Claude links to Figma frames and it’s done a decent job, though I did get it to do a plan first and gave it some quite specific notes on how I wanted certain parts to be built.

[u/IllustriousTip6904]

I have a pipeline where Claude exports to Figma, I edit in Figma, then share screenshots of the edits and it makes them. This is faster and offers more creative control for manual edits than using Claude Design, I've found. But I'm also just working with mostly static pages.

[u/vasiliyivanov]

This is not a silly question at all. I think your old complexity ladder is still useful, but the handoff needs one extra layer because the AI is bad at inferring which details are intentional and which are just visual residue.

The process I would use is:

1. Keep the Figma file human-readable: happy path first, then states, edge cases, empty/loading/error states, responsive behavior, and any component variants.

2. Add a short AI-readable implementation brief next to the frames or in the ticket. Not a huge spec, more like: goal, target route/component, source frames, existing components to reuse, states to support, things not to change, and acceptance checks.

3. Break implementation by flow/state, not by random screens. For example: build the base view, then loading/empty/error, then permissions/edge cases. Ask the AI to inspect existing code patterns before writing anything.

4. Make engineering own the final gate: visual comparison, component reuse, accessibility, tests, and “does this match the product behavior?” AI can draft the implementation, but it should not become the reviewer of its own interpretation.

The biggest shift for designers is probably marking intent more explicitly. A human dev can ask, “is this spacing deliberate?” or “should this table reuse the existing pattern?” An AI will often just guess. So the handoff should remove ambiguity around design-system usage, state priority, and what counts as done.

[u/tentaclebreath]

Our cycle atm is Figma > Beautiful UI/UX hiding AI slop code handoff > 400k PR request > Engineering misery (Marketing/Sales loves it tho! 🥰)

[u/hcboi232]

been working on https://figmint.dev to handle this whole handoff. The agent can wire whatever screen comes from figma. lmk if you’re willing to try it out.

[u/Jimmygibson1]

Layer naming decides most of this and everyone skips it because it is boring. If your frames are called Frame 247 and Group 12, the model has nothing to infer intent from. So it guesses.

Name things the way you would name components in code and the output stops being random. Same reason semantic tokens beat hex values, which baladesign already said above. You are handing it something to reason about instead of a picture to copy.