Figma Specs for designers: the short answer

Figma Specs is a new place inside Figma to write down the intent behind a design: the problem, the rules, the data and the technical details, next to the canvas instead of in a separate doc. Figma announced it at Config India on 14 October 2026 and listed it in its release notes on 15 October as an open beta on paid plans. The Specs product page describes it as a container for context that can move into, out of and across Figma.

So what do Figma Specs change for designers? They turn the written part of design work into something agents read directly. A spec can feed the Figma agent while it builds code layers on the canvas, or go to an external coding tool through the Figma MCP server. That makes clear writing a design deliverable in its own right. The designer who can explain a flow precisely now steers what gets built, not just what gets drawn.

What Figma actually shipped

Kept to what Figma's own pages state.

Specs (open beta). In the Config India recap by Dylan Field, Figma calls Specs a native home for context. A spec can live on the design canvas or in its own space, and it can reference diagrams, code layers and designs already in your files. The product page says you can tag teammates, add data, connect external agents and pull in context from other tools through the Figma agent. Figma frames the output as structured Markdown that agents can follow from prototype to production. The recap says Specs is in open beta on web, desktop and mobile, on all paid plans.

Code layers (open beta). Code-backed, interactive prototypes on the canvas. You can create them by converting a design, uploading a local folder, importing from GitHub, bringing in a coded prototype via MCP or capturing a live website with the Chrome extension. The release notes say creating and editing code layers is free on paid plans through 4 November.

Guidelines and design systems. Guidelines attached to published libraries are in open beta on paid plans, so the agent follows your patterns. A centralized design system view, with a system map and system checks for gaps like missing descriptions or interactive states, is a preview only. Code sources, which import a GitHub repo or npm package so the agent uses your real components, start in closed beta.

MCP. The Figma MCP server can now work with specs and generate code layers from external AI tools, and Figma added 20 new MCP partners.

The old handoff vs the spec-first handoff

The fourth row is the honest one. Specs do not remove the old failure mode. They make it faster.

Hype vs reality

The hype says the PRD is dead and the design file now writes the code. Describe it, and the agent ships it.

What holds up: keeping intent physically connected to the work is a real improvement. Standalone Markdown files have no relationship to the project, and Figma says as much in its recap. A spec that references the actual frames, diagrams and code layers is harder to let drift. Sending that same spec to a coding agent through MCP means the engineer's tool and the designer's tool start from the same text. For teams that already use the Figma agent for designers and code layers, this closes an obvious gap.

What does not hold up: a spec is only as good as its author. Agents follow what is written, including the vague parts, so an unclear spec produces confident, wrong output. Specs is a beta on paid plans, centralized design systems are a preview, and code sources are a closed beta, so the full loop Figma describes on stage is not something most teams can run end to end today. And Figma has not published accuracy figures for how well agents follow specs, so treat any claim of "spec in, production code out" as a goal, not a result.

Verdict: Figma Specs is worth adopting now for teams already building with agents, as the single source of intent. It is not a reason to stop reviewing what agents build, and it will not rescue a team that never agreed on what it was building.

The four-block spec: a structure that agents and humans both follow

Figma does not prescribe a template, so here is a simple structure to start with. Call it the four-block spec.

1. Intent. One paragraph: who this is for, what problem it solves, what success looks like. No solution yet.

2. Rules. The constraints the agent must not break: which components and tokens to use, what is out of scope, accessibility requirements, tone of copy. Point to your library guidelines rather than repeating them.

3. States and edges. Empty, loading, error, partial data, long text, right-to-left languages, offline. Agents fail here most often, because nobody wrote these down.

4. Acceptance. How a reviewer decides the build is right. Concrete checks, not adjectives. "Matches the designs" is not a check. "Error state shows the retry action and keeps the user's input" is.

Reference the frames and code layers inside each block so the agent sees the visual and the words together. Keep each spec to one feature. A spec that tries to describe a whole product turns into the PRD nobody read.

How to try Figma Specs this week

Pick one small, real feature, ideally one with a few tricky states. Write its four-block spec on the canvas next to the existing frames. Ask the Figma agent to build a code layer from it, then review the result against your acceptance block, not against your memory of the design. Every gap you find is either a missing line in the spec or a missing rule in your library guidelines. Fix the text, not just the output.

If your team uses an external coding agent, send the same spec through the Figma MCP server and compare what comes back. Differences between the two builds usually point to ambiguity in the writing. Pair this with the library setup described in design systems for AI and the reusable instructions from Figma agent custom skills, and you have the full context stack: system, skills, spec.

Note the clock on code layers. They are free to create and edit on paid plans until 4 November, which makes this the cheapest window to test the workflow.

The fear: is writing specs now the designer's job?

Partly, yes. And that is closer to good news than it sounds.

The fear behind Figma Specs is familiar: if agents build from text, then the drawing part of the job shrinks, and designers become spec writers for machines. The honest answer is that the drawing part is shrinking for routine screens, and that has been true since generative UI tools arrived. What Specs makes visible is the part that was always the hard work: deciding what the product should do, for whom, and where it should refuse. That judgment does not come from the agent.

Designers who already write clear rationale, map edge cases and run design reviews will find their skills worth more in this setup. Designers who rely only on high-fidelity mockups to communicate are the ones at risk. The move is not to panic about prompting. It is to practise writing short, testable intent, and to learn enough about code layers to review them. The design engineer path is one direction; strong product thinking without code is another. Both survive.

Where this is going

Over the next one to three years, expect the spec to become the main artifact that design, product and engineering share, with screens hanging off it rather than the other way round. Design reviews will check the spec as much as the pixels. Teams will version specs like code, and the quality of a team's written context will show up directly in the quality of what its agents build. The tools will keep changing names. The habit of writing precise intent will not.

FAQ

What are Figma Specs?

Figma Specs is a beta feature that gives teams a place in Figma to write the intent, rules, data and technical details behind a design. A spec can sit on the canvas or in its own space, reference designs, diagrams and code layers, and be read by the Figma agent or sent to external coding agents through the Figma MCP server.

Are Figma Specs free?

No. According to Figma's Config India recap, Specs is in open beta on all paid plans, across web, desktop and mobile. Code layers, a related feature, are free to create and edit on paid plans until 4 November 2026, per Figma's release notes.

Will Figma Specs replace PRDs?

For many teams, yes, in practice. A spec covers what a PRD covered and stays linked to the designs and code it describes. It will not replace the thinking a good PRD required. A vague spec fails the same way a vague PRD did, only faster, because agents build from it directly.

Will AI agents building from specs replace UI designers?

Not the designers who own intent and quality. Agents can build routine screens from a clear spec, but someone still decides what the product does, writes the rules, maps the edge cases and judges whether the result is right. Designers who only produce mockups face more pressure; designers who can do that judgment work become more valuable.

Is Figma Specs overhyped?

The vision Figma presented, where intent flows from spec to production code, is ahead of what most teams can run today, because several pieces are in beta, closed beta or preview. The core idea, keeping written context next to the work and readable by agents, is useful right now. Adopt it for one feature, measure how much rework drops, then decide.

Getting help with spec-first product work

If your team wants to move to agent-assisted building without losing design quality, the work is mostly in the context: the library, the guidelines and the specs agents read. A UI/UX agency in Casablanca that works with clients globally can help set that up. DIGCY is a Dribbble Selected Agency with 50+ projects delivered, offering product design services and AI product development for teams building with agents.