How We Set Up Claude Desktop with Figma MCP for a Remote Design Team

The documentation for Claude Desktop and Figma MCP is good for individual setup. It does not address what changes when multiple people are working in the same Figma files, pushing interfaces from different machines, and reviewing each other's Claude Code output. This is the gap we had to figure out ourselves.

The problem we were solving

Before setting up a unified workflow, design and AI context lived in separate places. Rasya, our UI designer, worked in Figma. Prototype builds happened in Claude Code on separate machines with separate Figma connections. When something was pushed to Figma, context about why it was built that way, what constraints were imposed, and what the client had specifically asked for did not travel with it.

The goal was a shared environment where Claude Code output landed in a predictable place in the Figma file, with enough naming and structural context that anyone on the team could pick up where someone else left off without a sync call.

The setup that works for a remote team

Each team member installs Claude Code independently and connects to the Figma MCP server using their own Figma credentials. The remote MCP server (at https://mcp.figma.com/mcp) is the right choice for team use because it does not depend on any individual's local machine being online. The desktop server runs locally and creates inconsistency when different team members push from different machines.

The critical coordination layer that makes this work: a shared Figma file structure with consistent frame naming conventions. We use a tiered naming system: Project / Feature / Screen Name / State. Claude Code references frames by name when pushing interfaces. Without consistent naming, frames land in wrong locations or overwrite content they should not touch.

We also maintain a shared CLAUDE.md file in each project repository. This file documents the design system context: token naming conventions, component structure, interaction patterns, and any client-specific constraints. Claude Code reads this file and uses it as context for every generation request. New team members copy this file from the previous project as a starting point and update it for the new client's specifics.

What changed after one month

The biggest change was not in speed, though that improved. It was in handoff quality within the team. When Rasya reviews a Claude Code build that was produced following the CLAUDE.md conventions and the Figma naming structure, she understands what she is looking at without needing a call to explain it. The context travels with the work because the conventions encode it.

The second change: client review sessions became more focused. When clients review Figma frames, they are looking at an organized file that reflects the structure of the product rather than a collection of frames with ambiguous labels. They give better feedback because they can orient themselves in the file.

Limitations we found in month one

Two constraints that the documentation does not mention clearly. First: pushing large multi-screen flows from Claude Code to Figma in one session is slower than pushing individual screens. For flows longer than six screens, we push in batches of three and assemble the sequence in Figma afterward.

Second: the Figma MCP server requires the Figma Desktop app to be running on the machine initiating the capture. For fully remote workflows where team members sometimes use Figma in the browser, this creates a gap. We resolved it by establishing that any Claude Code to Figma push is initiated from a machine with the Desktop app installed, not from the browser session.

Those are solvable problems. The convention overhead to maintain consistent naming adds maybe 15 minutes per sprint. The value it returns in reduced sync calls and faster onboarding is significantly larger than that.