Figma and Anthropic announced a two-way integration. The marketing copy promises you'll "escape tunnel vision," "start anywhere," and end up with "editable frames."
But Reddit’s reaction was less polished. One user called it “a nightmare.” Another warned: “Be ready to waste one sextillion tokens.”

Both sides are right. That's the honest answer.
At Eleken, we’ve been actively experimenting with Claude Code workflows in real SaaS product environments. We’ve tested where the integration speeds up product design, where it breaks down, and what patterns consistently produce better results.
This guide breaks the workflow down clearly, explains which use cases are worth your time, and shares practical lessons from our Lead UX/Product Designer, who has been testing the Figma ↔ Claude loop on client work.
If you're already exploring UX AI tools or AI-assisted design workflows, this integration deserves a serious look. But first, it’s important to understand what it does.
How to connect Claude Code to Figma: setup in 4 steps
To connect Claude Code to Figma, you need Figma's MCP server. It lets Claude Code access your Figma designs, read frame details, and use that information when generating code.
The setup takes just a few minutes. You'll need Claude Code installed and a Figma account with access to the design file. Following Figma's official MCP setup documentation and Help Center guidelines, here's how to set it up in four steps.
- Step 1. Add the Figma MCP server
You have two options:
1. Install the official Figma plugin (recommended).
Run this command in your terminal:
The plugin includes the MCP configuration and Figma's Agent Skills, which help Claude Code work with Figma designs.
2. Add the MCP server manually.
If you prefer to configure the connection yourself, run:
To make the connection available across all your Claude Code projects, add --scope user:
Choose only one installation method.
- Step 2. Authenticate your Figma account
If Claude Code is already running, restart it to load the new MCP configuration.
Then type /mcp in Claude Code, select figma, and choose Authenticate.
- Step 3. Allow access to Figma
Your browser will open Figma's authorization page. Click Allow Access to approve the connection, then return to Claude Code.
- Step 4. Verify the connection
Run /mcp again. If the Figma server shows as connected, you're ready to go.
Now open your Figma file, copy a link to the frame you want to work with, and paste it into Claude Code along with your prompt.
What about Figma's desktop MCP server?
Figma also offers a local MCP server that runs through its desktop app. You can connect it using:
For most workflows, Figma recommends the remote server because it doesn't require the desktop app to be running.
How to send a Figma design to Claude Code
Once you've connected Claude Code to Figma through MCP, you can share any Figma frame with Claude Code using a link. Claude Code reads the design details and uses them to generate code.
Here's how it works:
- Select a frame in Figma. Start with a single screen or component rather than an entire page. This gives Claude Code a more focused task.
- Copy the frame link. Right-click the selected frame and choose Copy/Paste as → Copy link to selection.
- Paste the link into Claude Code with a prompt. Explain what you want to build, which framework you're using, and whether Claude should reuse existing components.
For example:
Implement this Figma frame as a React component using the existing components in src/components and design tokens in tokens.css. [Figma link] - Review the result in your browser. Run the generated code locally and compare it with the original Figma design. Ask Claude Code to fix any differences in layout, spacing, typography, or component behavior.
Can you use Claude Code with Figma without MCP? Yes. Simply share a screenshot of your design or copy CSS properties from Figma's Dev Mode into Claude Code.
However, screenshots don't provide the structured design information available through MCP, such as component properties, layout settings, and design variables. This means Claude Code may need more guidance to reproduce the design accurately.
For better results, use MCP to provide design context and Dev Mode to inspect specific styling details when needed.
Claude Code to Figma integration: two directions
Most people assume this is one thing, but it includes two directions:
- Figma → Claude Code (design to code): Claude reads your Figma design file through MCP and generates code from it, making design to code with Claude one of the most practical AI-assisted workflows currently available for rapid prototyping and UI iteration. This is the older, more established direction. It's where most of the real, repeatable value lives today, and it marks a meaningful shift in the designer-developer relationship.
- Claude Code → Figma (code to canvas): You build a UI in Claude Code and send it back into Figma as editable frames, creating a much more collaborative code-to-design workflow than traditional handoff processes. Announced in February 2026, this direction is real, just still maturing. The interaction model is essentially conversational UI: you describe what you want, and Claude builds it.
Together, they form a loop: design → code → Figma canvas → refine → back to code.

But that doesn't mean every team needs to complete the entire loop.
One of our clients described an internal discussion about whether Figma still needs to be the middle step. Their goal was to move directly from Claude to code while making sure AI used their existing Vue components and Storybook library.
That's an important distinction. For teams with established frontend components, the most useful workflow may be Claude Code → working prototype → engineering review, without returning to Figma after every iteration.
Before you go further, there's one thing you need to understand. MCP gives Claude structured data: component names, layout properties, spacing tokens. But the quality of that information depends on how the Figma file is built. If components aren't properly structured or tokens aren't available, Claude has less reliable context to work with.
And even with well-organized design files, the generated code still needs review.
Figma Make vs Claude Code
Both Figma Make and Claude Code can turn design ideas into working interfaces, but they serve different purposes.
Figma Make is an AI-powered tool for generating interactive prototypes and web apps from prompts or existing designs. It's useful for quickly exploring ideas without setting up a codebase.
Claude Code is Anthropic's coding agent that can work directly in your existing codebase. When connected to Figma through MCP, it can use your designs as references while building interfaces with your actual components and design system.
Here's how they compare:
At Eleken, our designers increasingly start directly in Claude Code instead of creating every initial concept in Figma.
As Maksym, our design expert, explains, it's often faster to describe an idea to Claude, generate a working interface, and iterate on it than to build the same concept manually in Figma.
We use Claude to explore product flows, test interactions, and refine UI elements. When we need more precise visual adjustments, we can bring Figma into the workflow through MCP.
For clients with an existing React or Vue component library, Claude Code is particularly useful because designers can work with the same components developers use, reducing the gap between design and implementation.
With that said, choose Figma Make when you need a quick, standalone prototype. Choose Claude Code when you want to iterate in a real codebase and move closer to production.
Use cases: what Figma to Claude Code is good for
Figma with Claude Code is the more mature direction right now. Claude Code → Figma is real, but it's still secondary. If you go in expecting a seamless two-way loop, you'll be disappointed. But if you understand the strengths of each direction, the workflow becomes much more useful.
Here are the most common use cases where Eleken designers are already seeing value.
Use case 1: Rapid interactive prototyping
One of the biggest advantages of connecting Figma to Claude Code is how quickly you can turn a design or rough idea into a working prototype. Instead of spending hours manually connecting screens, you can generate interactive interfaces, test different flows, and show stakeholders how the product works before development begins.
As Maksym, Head of Design at Eleken, explains: "You can show this to customers, let them play with it. You can make a mock demo with fake data that you can demonstrate in presentations to show how it will work."
This makes it easier to validate ideas early, collect feedback, and refine the experience without waiting for developers.
Of course, you don't always need Claude Code to create an interactive prototype. Figma itself is useful for testing user flows and demonstrating how a product should work. Here's an example of an interactive Figma prototype created by our team:
The difference is that Claude Code can take prototyping further by generating working interfaces with more realistic interactions, dynamic behavior, and sample data.
If you want to learn how to create interactive prototypes directly in Figma, watch our video:
For teams exploring AI tools for product design, this is one of the most practical ways to speed up early product validation.
Use case 2: A/B testing new features
You've designed a new feature and built a quick prototype through Claude Code. Now you want to test two variants with real users before committing development resources to either.
This workflow makes it fast and inexpensive. Instead of waiting for engineering cycles to build out both variants, you can have them ready in a day. For product decisions that hinge on user behavior, speed matters. This is a case where we identified pain points and improved usability.
The example below is this kind of case. Eleken designers used AI-assisted prototyping to explore different onboarding and search interaction patterns, identify usability pain points, and test which experience felt more intuitive before moving deeper.
Use case 3: Redesigning an existing product
This is the more advanced case and the more token-expensive one. The idea is to launch an existing product in developer mode, then start editing it like a designer, through code. It's a particularly strong fit for AI in SaaS products where design systems sprawl across dozens of screens and global changes are otherwise painful.
The workflow typically looks like this:
- Claude analyzes the existing UI;
- extracts baseline design patterns;
- identifies reusable components;
- helps standardize inconsistent styling;
- applies changes across the product.
Maksym describes it this way: "You change the building blocks the interface is made of. Then you take a page and say: “Our primary button was blue, now it's purple, change it everywhere."
That’s where the real leverage appears. Instead of manually updating dozens of screens, teams can iterate on the underlying system itself.
Our designers can review the codebase, identify reusable components and design tokens, and prototype changes within the actual frontend environment. Instead of generating an isolated redesign, we can work with the components the product already uses.
This can be valuable for established SaaS products, where a new feature needs to fit the existing design system rather than introduce another set of inconsistent UI patterns.
The example below is a prototype Maksym created while experimenting with redesign workflows for an existing SaaS interface. The goal was to test how quickly large-scale UI consistency changes could be applied across a complex product environment.
One important caveat: This workflow burns through design tokens quickly.
It’s realistic and genuinely powerful, but teams should go in with clear expectations and a budget in mind.
Use case 4: UI quality control
This one hasn't fully landed yet, but it points somewhere interesting. The concept: designers catch frontend implementation drift and fix it directly in code. You open the shipped product, spot the 3px misalignment, create a branch, fix it in code, and hand it back to the developer for sign-off.
No more "can you just nudge that button?" Slack messages.
Our Head of Design hasn't tested this pattern with clients yet, and that is worth keeping. But the underlying capability is real: "It's easy to fix things in code — 'raise this button 3 pixels.' You just go to the code and say raise it, lower it, remove this, do this thing here."
This also points to a broader change in how designers and engineers can collaborate.
Instead of documenting every visual correction in Figma and waiting for engineering to reproduce it, designers can potentially prepare changes directly in a separate branch.
At Eleken, when the client's setup allows it, approved changes can be submitted as Pull Requests. Engineers review the code, request adjustments, and decide whether to merge it. That makes the design-to-development process more direct.
The one case where Figma designs stays essential
Across all of these workflows, Figma stays what Maksym calls the "Polar Star", the static source of truth you always return to. Even when you're building directly in Claude, you lose the blueprint if you don't have static screens to reference. The canvas keeps the team anchored.

When it struggles:
- You're working on an existing codebase, and changes mean regenerating rather than editing.
- You expect pixel-perfect output from complex, multi-frame designs.
- You're on a budget: heavy iteration burns tokens on both Claude and Figma's API.
- You're on Windows/WSL using the Desktop MCP.
- Your Figma file has no design system. Claude defaults to generic-looking output.
Once you understand where this workflow succeeds and breaks, the next step is seeing how the loop works.
The workflow in practice
Here's how the loop runs, step by step.
Phase 1: Figma → Code
This is where most teams start, and where realistic expectations and a structured workflow make the biggest difference:
- Connect Claude Code to Figma through MCP.
- Paste a Figma frame link into Claude Code.
- Generate the first implementation.
- Run it locally.
- Refine the UI iteratively.
One rule makes a massive difference: Don’t start with full pages.
Full-page generation gives Claude too many degrees of freedom, and the output becomes inconsistent fast. The teams getting reliable results almost always start small:
- one component;
- one section;
- one interaction pattern.
Get the workflow working on something contained before scaling up. Once Claude generates the first pass, run it on localhost immediately. That first output is rarely final; it’s a starting point.
The refinement loop
This is where most tutorials stop and where the actual method begins.

From Maksym: "I select the element in the preview in inspect mode through Chrome, say I need to fix this element, and tell Claude how to fix it, right there in Claude."
The key principle: reference Figma only when a whole component has been fundamentally misinterpreted. Not for minor spacing or color fixes. Handle those in the inspect loop. Iterate until the screen is right.
Phase 2: Code → Canvas
When you have a working UI state worth sharing, type “Send this to Figma.” This allows teams to generate UI design in Figma from Claude while keeping layouts editable for review, iteration, and alignment.
What you get back: real editable layers, editable text, and auto-layout. However, you don't get business logic, event handlers, or state management.
Use this alongside your other collaboration tools for team alignment, side-by-side variant comparison, and multi-screen flow review. The design canvas is for diverging and aligning, not a handoff artifact.

Phase 3: Back to Code
Once the team reviews and annotates the UI in Figma, share the updated frame link back with Claude and continue iterating from there.
This is where the workflow becomes collaborative instead of linear. Designers can comment on flows, compare variants, refine interactions, and align on direction before more implementation design work happens.
The loop usually looks like this:

That round-trip comes with a cost: multiple design tools, repeated context switching, and ongoing iteration. For simple solo work, it can feel excessive.
But for complex features, multi-screen flows, stakeholder reviews, and collaborative product decisions, the alignment benefits often outweigh the friction.
How to give Claude Code the right design context
The teams getting the best results usually have one thing in common: they give Claude far more structure and context than beginners expect. Here’s how to do that.
- Write a CLAUDE.md file.
Think of it as onboarding Claude to your product and design system. Ask:
- Where are the actual components?
- Which naming conventions matter?
- What are the source-of-truth examples?
The more structured context Claude has, the better the output tends to be.
Experienced teams often combine MCP with:
- reusable components;
- style guides;
- design system documentation;
- project instruction files like CLAUDE.md;
- existing code and front-end code references.
The goal is simple: reduce how much Claude has to “imagine.”
As one Reddit user explained, they got much better results once Claude had clear instructions on where to find components, coding patterns, and reusable UI examples. Plus, “... Having a style guide as static code, where Claude can learn the necessary patterns—this means Claude doesn't have to “imagine” too much to create the appropriate components.“

- Start with one component, not a page.
Every practitioner who gets reliable results starts small. Everyone who gets frustrated starts with a full screen.
Large multi-frame generations give Claude too many degrees of freedom, which quickly leads to inconsistent layouts and messy hierarchy.
Interestingly, experienced Reddit users experimenting with Figma MCP workflows report the same pattern: better results come from “... giving Claude individual components and sections vs entire pages…”, then refining iteratively with specific assets and visual references when needed.

- Combine MCP data with dev mode CSS.
MCP gives Claude the structural information behind your design: component hierarchy, spacing values, layout rules, and tokens. But it still doesn’t fully understand how the interface should visually feel.
That’s where Dev Mode CSS helps.
By combining MCP data for structure and Dev Mode CSS for visual styling, you give Claude a much clearer picture of the intended UI.
Many teams experimenting with Figma MCP server workflows have found that combining MCP data with component CSS gives Claude much more accurate and consistent UI output: “What actually helps: if you can grab the component's CSS from dev mode and paste it in the prompt alongside the MCP data, Claude has both the structural data AND the visual intent. Still not pixel-perfect, but dramatically closer than MCP alone.“

It’s still not truly pixel-perfect, but it’s one of the most effective ways to get closer to the original design without endless refinement loops.
However, CSS alone won't solve problems caused by an inconsistent design system.
If the Figma file doesn't use structured components or reusable tokens, Claude may still produce one-off values that don't match the product's existing UI.
Where possible, connect the workflow to the actual design tokens and frontend components instead of relying entirely on generated CSS.
- Use Figma for diverging, code for converging.
The most effective workflows usually separate exploration from implementation.
Use Figma to explore ideas, compare variants, review flows, and align with stakeholders. Use Claude Code session to build, refine, and iterate on the implementation itself.
Teams often start running into problems when they try to fully design and fully implement within the same conversational session. That’s usually where context gets messy, and the workflow becomes frustrating.
A smoother pattern is:

- Batch your Figma API calls.
If you’re on a limited plan, repeated MCP requests can become expensive surprisingly fast.
A better approach is to gather most of the design context at the beginning of a session, including existing components, assets, spacing rules, typography, and layout references, and then continue refining locally instead of constantly sending Claude back to Figma. This usually leads to fewer token-heavy round trips, faster iteration, and more consistent output.
- Keep your design system as the source of truth.
Maksym's primary fix for cross-screen consistency: a document listing all your color palette, typography, and spacing rules, with instructions telling Claude to always reference it.
If you also use ChatGPT for UX research, the same principle applies: AI tools need explicit context to stay consistent. It sounds simple, but it works.
Taken together, these practices point to a bigger shift: the workflow is no longer just “design, handoff, develop,” but a continuous, conversational, and much more iterative process.
Where this leaves us
The old workflow was linear: design in Figma, Figma handoff, code. The new one is a loop, and it changes what design-driven development can look like in practice.
For some teams, this integration removes the biggest friction point in the design-to-code pipeline. For others, it adds steps to a process that was already working fine. There's no universal answer here.
However, you can always test: try it on one component, not a page or a full project. You'll know in 20 minutes whether it fits how you work, and that's worth more than any setup guide.
At Eleken, we work with SaaS teams actively exploring AI-assisted UX workflows, rapid prototyping, and modern design-to-code collaboration.
We don’t see tools like Claude Code as replacements for designers or engineers. We use them to help teams move from idea to usable product faster and with less friction.
If your team is experimenting with AI-powered product design workflows and wants experienced product designers who understand both UX and modern AI tooling, Eleken can help.




.webp)







