AI can look at a design and produce something that seems convincing in seconds.
That is also the problem.
A generated interface can have the right buttons, the right layout, and even the right brand colors while quietly breaking the rules that make a product feel consistent. Maybe the spacing is wrong. Maybe a destructive action is styled like a secondary action. Maybe the mobile behavior was never defined. Or perhaps the AI simply invented a component that already exists in the design system.
The missing ingredient is usually not another screenshot.
It is context.
That is the problem Figma is trying to address with Figma Specs, introduced at Config India on October 15, 2026. Specs gives teams a Markdown-based place to capture written intent, requirements, decisions, technical details, and other context alongside their visual work. Figma’s MCP ecosystem can then make that context available to AI agents working across design and code.
The interesting part is not that Figma added another documentation feature.
It is that design rules are starting to become something an AI agent can actually read and work from.
Key Points
- Figma Specs is a native Markdown-based space for documenting design context and intent.
- Specs can exist as standalone files or directly alongside designs in Figma Design and FigJam.
- Designers can bring requirements, decisions, technical information, diagrams, and other context into the same workspace.
- Figma’s MCP server can let coding agents read, create, and update Specs.
- Specs is currently in open beta and rolling out across supported plans.
- A good Spec should describe decisions and constraints, not simply repeat what is visible in a screenshot.
- Human review still matters because documentation gives an agent direction, not perfect judgment.
Why AI Needs More Than a Figma File
A Figma file tells an AI a lot.
It can reveal colors, typography, spacing, component structure, layouts, variables, and relationships between elements. Figma’s MCP tooling is specifically designed to bring design context into AI workflows and can allow agents to work with native Figma content.
But visual information has limits.
Imagine a checkout screen with a green button.
An AI can identify the button.
It may not know why that button is green.
Is green reserved for primary actions? Does the checkout flow allow only one primary action per screen? Should the button become full-width on mobile? What happens when payment fails? Should a disabled state use the same color system or a dedicated token?
Those decisions often live somewhere else.
They might be buried in a design-system document, a product requirement, a Slack conversation, a developer ticket, or simply inside the designer’s head.
That is where the idea behind Specs becomes useful.
Instead of asking an AI to infer every rule from the finished design, designers can give the agent the reasoning behind the design.
That is a much better starting point.
What Exactly Is Figma Specs?
Figma describes Specs as a native home for context that can move into, out of, and across Figma.
It is built around Markdown and can be used as a standalone Spec file or placed directly into a Figma Design file or FigJam board. You can also bring existing Markdown into Specs.
The important word here is context.
A Spec can contain ordinary documentation such as:
- Product requirements
- Design decisions
- Open questions
- Technical requirements
- Component rules
- Interaction behavior
- Accessibility considerations
- Content requirements
- Edge cases
- Implementation notes
But it can also connect that written information to the visual work around it.
Figma’s documentation describes workflows where Specs can be created from designs, used alongside code, enriched with external context through MCP, and turned into technical specifications.
So think of a Spec less like a traditional document and more like a shared layer between design intent and implementation.
The Real Question: What Should You Put in a Spec?
This is where designers should be careful.
If you simply copy your design documentation into Specs, you may end up with a very polished document that still gives an AI surprisingly little useful direction.
The better question is:
What would another designer or developer need to know if they had to continue this work without asking me questions?
That usually leads to better information.
For example:
# Checkout
## Primary action
Use the existing Primary Button component for the final checkout action.
- One primary action per screen
- Do not create a custom button style
- Use the destructive variant only for irreversible actions
## Responsive behavior
Desktop:
- Two-column layout
- Summary remains visible beside the form
Mobile:
- Single-column layout
- Summary moves below the payment section
## Validation
Inline validation appears after the user leaves the field.
Errors should explain:
1. What went wrong
2. How the user can fix it
## Open questions
- Should saved payment methods appear before or after the billing address?Notice what this does not try to document.
It does not describe every pixel.
The design already shows much of that.
Instead, the Spec records decisions, constraints, behavior, and uncertainty.
That is the information an agent is much less likely to recover correctly from a screenshot alone.
Turn Design Guidelines Into Instructions an Agent Can Use
This is probably the most interesting workflow around Specs.
Design systems traditionally exist to keep humans consistent.
AI introduces a new consumer of those systems.
An agent needs to know things such as:
Use existing components before creating new ones.
Do not introduce a new color when an existing semantic token fits the requirement.
Use the compact navigation pattern on mobile.
Never use red for ordinary informational states.
Prefer the existing empty-state component.
Those are not merely visual properties.
They are rules.
And rules are valuable context for an agent.
Figma is also introducing Guidelines, which let teams add guidelines to published design libraries so agents can follow established patterns and avoid anti-patterns. Figma describes Guidelines as a separate open-beta capability, while Specs provides a broader space for capturing project context and decisions.
That distinction matters.
A useful way to think about it is:
Guidelines describe reusable system rules.
Specs describe the context and decisions for a particular piece of work.
The two can complement each other.
A Better AI Design Workflow
The most useful workflow is not:
Design → AI → Code
It is closer to:
Intent → Rules → Design → Specification → AI → Code → Review
Here is what that can look like in practice.
1. Start with the product problem
Write down what the feature is supposed to achieve.
Do not start with visual instructions.
For example:
Users need to compare subscription plans quickly and understand which plan is recommended.
That gives the agent a reason behind the interface.
2. Record the design decisions
Now capture decisions that should remain consistent.
Maybe:
- The recommended plan gets one visual emphasis.
- Pricing must remain scannable.
- Feature comparison should not depend on color alone.
- The CTA hierarchy should remain consistent with the existing product.
These become constraints.
3. Connect the Spec to the design
Place the Spec beside the relevant frames or use it within the Figma canvas.
Now the written decisions and visual exploration have a shared location.
Figma specifically supports putting Specs directly into Figma Design files and FigJam boards.
4. Give the agent the context
This is where Figma MCP becomes important.
Figma’s current MCP tooling supports reading, creating, and updating Specs, while its figma-spec skill is designed specifically to let coding agents work from requirements, decisions, and open questions stored in Specs.
Instead of:
Build this screen.
You can give an agent a much richer instruction:
Read the Spec first. Implement the subscription comparison using the existing design system. Follow the responsive behavior and component rules documented there. Do not introduce new components unless the requirements cannot be met with existing ones.
That is a fundamentally different interaction.
The agent is no longer guessing what matters.
Specs Can Also Capture What the AI Learns
There is another interesting side to this workflow.
The document does not have to be finished before the agent starts working.
Figma’s MCP documentation says agents can capture decisions and discoveries back into the Spec as work progresses.
That creates a useful feedback loop:
Designer decides → agent implements → agent discovers an edge case → Spec records it → team reviews the decision.
Over time, the Spec can become a living record rather than a document that nobody opens after the project starts.
That could be more valuable than the initial AI generation itself.
What About Developers?
This is where Specs becomes particularly interesting for design-development collaboration.
Developers frequently receive designs after many important decisions have already been made.
The visual result arrives.
The reasoning does not.
A developer may see a card component but not know whether its spacing is intentional, whether the card can contain arbitrary content, or whether the mobile layout is supposed to collapse.
A well-written Spec can carry those decisions alongside the design.
Figma’s current MCP tooling is explicitly designed to move context into coding workflows, and Figma says Specs can be sent to coding agents through MCP.
That does not eliminate communication between designers and developers.
It gives both sides a better shared reference.
Don’t Turn Specs Into a Giant Rulebook
There is a trap here.
Once designers discover that AI can read their documentation, it will be tempting to document everything.
That is probably the wrong direction.
A 40-page document explaining every possible button state may be technically comprehensive but practically useless.
The best context is relevant context.
Document:
- Decisions that matter
- Rules that should not be broken
- Behavior that is not obvious visually
- Constraints imposed by the product
- Important technical requirements
- Known edge cases
- Questions that still need answers
Leave out information the agent can reliably obtain from the design itself.
A good Spec should reduce ambiguity, not create another mountain of text.
Where Human Judgment Still Matters
This is the part worth emphasizing.
Giving an AI better context does not give it perfect design judgment.
An agent can follow:
Use the existing card component.
It can still choose the wrong moment to use that component.
It can understand a spacing rule and still produce an interface that feels cramped.
It can follow the documented responsive behavior while missing a user-flow problem that nobody thought to write down.
And if the Spec itself contains an outdated decision, the agent may faithfully reproduce the wrong thing.
That means the workflow does not become:
Write rules once and let AI handle the rest.
It becomes:
Document intent, let AI work within that context, and keep reviewing the result.
That distinction will become increasingly important as agents become better at making changes across larger parts of a product.
Figma Specs and Code Layers Are Part of the Same Shift
Figma also moved Code Layers into open beta at Config India 2026. Code Layers allow interactive, code-backed prototypes to live directly on the Figma canvas, including workflows that start from designs, code repositories, captured websites, or prompts.
At first glance, Specs and Code Layers look like separate features.
They make more sense together.
Specs provide the reasoning and constraints.
Design files provide the visual language.
Code Layers provide a place to experiment with working behavior.
MCP provides a bridge for agents to move between those worlds.
That starts to look less like a traditional design tool and more like a shared environment where design, documentation, code, and AI can interact.
What Designers Should Do Now
You do not need to rewrite your entire design process around AI.
Start smaller.
Take one active feature and create a Spec for it.
Write down:
- What the feature is trying to accomplish.
- The design decisions that matter.
- Which existing components should be reused.
- Responsive behavior.
- Accessibility requirements.
- Technical constraints.
- Edge cases.
- Open questions.
Then ask an agent to work from that context.
The result will tell you something important.
Not just whether the AI can generate the interface, but whether your design system and decisions are understandable enough to be followed.
That is a much more useful test.
The Bigger Change Is Not the Markdown
Figma Specs may initially look like a Markdown editor inside Figma.
That undersells the idea.
The more important shift is that design intent is becoming an explicit part of the AI workflow.
For years, designers have complained that developers miss the reasoning behind a design.
Now designers have a second problem: AI agents can miss it too.
The answer is not necessarily more screenshots, more prompts, or more elaborate design files.
Sometimes the missing piece is simply writing down the rule.
Figma Specs gives that rule a place to live, keeps it close to the work, and gives agents a way to consume it. Its current MCP integration can also let agents read and update those specifications as work evolves.
But the quality of the result will still depend on the quality of the thinking behind the Spec.
AI does not need designers to document every pixel. It needs designers to make the important decisions explicit.
And that may be the real skill emerging from this new generation of design tools.