Claude Code to Figma: The Full Agency Workflow Guide

The Claude Code to Figma integration exists. Most agencies have heard of it. Very few have a repeatable workflow built around it. This is the guide we wished existed when we set it up.

What you need before you start

The Figma MCP server connects Claude Code to Figma's design canvas. Before anything works, four things need to be in place: Claude Code installed via npm, the Figma Desktop app (the web version does not support the MCP server), a Dev or Full seat on a paid Figma plan, and either Claude Pro or Claude Max for Claude Code access.

There are two connection methods. The remote MCP server connects directly to Figma's hosted endpoint at https://mcp.figma.com/mcp. The desktop MCP server runs locally through the Figma Desktop app at http://127.0.0.1:3845/sse. The desktop version burns fewer tokens and works well for selection-based workflows. The remote version is better for pushing entire interfaces back to Figma from Claude Code.

The four-phase workflow

Phase 1: Prototype in code

Before Figma opens, Claude Code builds the working product. Brief goes in. Working interface comes out. For a standard SaaS product, this means the core user flows: onboarding, the primary dashboard, key action screens. This is not polished. It is real and interactive, and that matters.

The common mistake here is trying to get the UI pixel-perfect in Claude Code before pushing to Figma. That is not the job of this phase. The job is to get something the client can interact with. Polish comes after feedback, not before it.

Phase 2: Push to Figma canvas

Once the working interface exists, Claude Code captures the screens and converts them into editable Figma frames. Not screenshots. Each frame has editable layers that a designer can work with natively. The sequence for multi-screen flows gets preserved, so the review makes sense as a journey rather than isolated frames.

The capture step is straightforward in Claude Code. Select the frames you want, run the capture command, and the Figma MCP server handles the conversion. The result lands in whatever Figma file you point it at.

Phase 3: Client review and design refinement

This is where Figma does its real work. The client opens the file, adds comments directly on the live frames, and the design team works through the feedback in their native environment. Side-by-side comparisons of variants, annotation layers, and the full Figma component system are all available at this stage because the interface is already in the canvas.

There is a meaningful difference between reviewing a Figma wireframe of what a screen might look like and reviewing an editable version of a screen that already exists and works. Clients catch different things. The feedback is more specific. Fewer cycles get wasted on misunderstandings that only become visible when something is built.

Phase 4: Update cycle

After Figma review, changes go back to the codebase. This step still requires human engineering judgment. The MCP connection helps carry design context from Figma into Claude Code, but it does not automatically regenerate business logic, state management, or event handlers. Treat this as informed iteration, not automated export.

Where the workflow breaks down

Three failure points show up consistently in the first attempt at this workflow.

The MCP server does not appear in Claude Code. MCP connections initialize at startup. If you added the Figma server while Claude Code was already running, restart it completely. The server will not appear mid-session.

Multi-frame flows lose sequence context. Capturing a multi-screen flow like onboarding requires capturing each frame individually and prompting Claude Code to assemble them in order. Each step uses tokens and requires coordination. Plan for this overhead when scoping sprint timelines.

Expecting bidirectional sync without understanding its limits. Code goes to Figma cleanly. Figma edits back to production code still require manual work. Business logic does not survive the round trip. Design tokens and visual changes carry over; application logic does not.

How Elux Space rolled this out to the team

We introduced the workflow to our team over two weeks, starting with a single component rather than a full product. One button, one card, one form field. Get the connection working on something small before using it on a client project.

Rasya, our UI designer, adapted fastest because the Figma side of the workflow is identical to what she already does. The change was upstream, not in her tools. Lintang took an orientation session on Claude Code's terminal workflow before the first sprint. We documented the setup in our internal SOP so new team members do not spend two hours on configuration that has already been solved.

What clients notice

The most consistent client reaction when they first see the workflow in action is not about the technology. It is about what they get on day one. A working product they can click through, rather than a document explaining what a product might feel like.

That shift in what "delivery" means changes the entire dynamic of an engagement. Feedback gets specific immediately. Scope problems surface early. The project moves faster because there is less time between idea and reality.

The workflow is not magic. It is a tighter feedback loop made possible by tools that did not exist two years ago. Whether agencies take advantage of it is still a choice. Most haven't made it yet.