1. Product introduction: give a design the explanation it needs

Figma helps teams design interfaces and prototypes together. A screen shows where a button goes and how a page looks, but may not explain what should happen after a click. Requirements can live in a document, feedback in a chat, and the developer may receive only the picture.

Specs, introduced by Figma on October 15, provides a shared place to write those explanations. It can be a standalone document or sit on a Figma Design or FigJam canvas beside screens and diagrams. Existing Markdown files—plain-text documents with markers for headings and lists—can also be dragged onto the canvas.

Product managers, designers and developers can use it to explain a requirement together. A registration page, for example, needs more than a Submit button: what happens when places are full, or someone submits twice? Specs puts those decisions beside the screen so people can read and discuss them together.

The official help page lists Professional, Education, Organization and Enterprise plans. Creating and editing within a file also requires edit permission. Specs is rolling out in open beta, so an eligible account may not yet have the entry point.

The product connects documents, the canvas and comments. The suggested team practice requires people to separate questions from decisions; it is not a built-in approval system.

2. Core workflow: turn a registration screen into a shared plan

Start by writing what the page needs to do

Use a registration page as the example. In an existing design file, choose Spec in the toolbar or press D. You can also create a standalone Spec first and bring it onto the canvas. State the goal: participants should be able to submit a registration and know whether it succeeded.

  1. Describe the important behavior. One way to start is to list filling in, submitting, success and inability to submit, then write the message for each case. This is a suggested way to organize requirements, not a fixed template generated by Specs.
  2. Place related screens beside the explanation. Type / in a Spec and choose Figma file embed from the block list to embed a file. In Design or FigJam, you can also drag content between a Spec and the canvas. Connect the registration screen with its explanation. Compared with a screenshot without a source, the relevant design object is easier to find.
  3. Discuss a specific point. Comment beside the full-capacity message and say what needs a decision. Write the agreed outcome back into the body. Keep questions distinct from decisions so later readers do not mistake a suggestion for a requirement.
  4. Switch views for the reading task. Stay on the canvas to compare text with screens. To work through a long document, click View as scrollable page or Open full-screen editor in the Spec’s top-right corner. Long writing does not have to remain squeezed into a small canvas area.
  5. Hand it over, then check the implementation. People can read the Spec directly. Coding assistants need to connect to Figma MCP and use the figma-spec skill to read the relevant explanation; see the official guide for setup. MCP connects tools and AI to exchange information, while the skill supplies instructions for working with Specs. Define the implementation scope, then return to the page and check each part of the registration flow.

The official guide says direct manual writing does not consume AI credits. Using the Figma agent with Specs does, with usage depending on the task and context. The corresponding FigJam rule applies once its agent begins consuming credits; this is not a universal charging rule for external coding assistants. Write down your own judgment first, then decide which organizing work to give AI.

3. Design lessons: put the explanation beside the object it explains

Reduce the work of finding relationships

“Show an error here” is hard to understand without the screen it refers to. Specs puts writing, design objects and discussion in the same working environment. Readers can move from the explanation to the screen and back to the reason.

This matters for someone joining a project later. They do not have to guess which screen “here” refers to before understanding the decision. The team still needs to organize the material: putting every old draft in one place without identifying the chosen one creates another kind of mess. The useful idea is to connect each material with its purpose, not to collect everything possible.

Give discussion a place to become an editable decision

Comments are useful for questions; the document body is useful for the current decision. If an answer stays buried in a long comment thread, the next person has to reconstruct it. Shared writing and comments provide a way to bring the result back into the explanation.

For the registration example, “Should we allow a waiting list after capacity is reached?” is an open question. Once the team decides, the body should describe the behavior clearly. People do that organizing work. AI can join the discussion or summarize it, but a space for discussion does not automatically resolve disagreements.

Let the same explanation support different reading tasks

A canvas supports comparing several objects; a full-screen document supports writing paragraph by paragraph. Specs lets people move between those views, so the explanation can stay close to a screen and still be read on its own. The product page emphasizes this flow of information between planning, design and implementation.

When handing work to a coding assistant, the team need not describe the background from scratch. It still needs to check that the assistant has the scope intended for this task. The transferable principle is to make decisions easy for people to find, understand and update before using them as AI input. Specific explanations give you a clearer basis for checking the result.