Before writing the first prompt, take time for research. Use Claude, ChatGPT, Grok or another LLM to arrive at Make with a clear brief — not to design there, but to define it.
- Do similar products exist? How do they solve the problem?
- What are the main flows I need to show?
- What tech stack does dev use? — include it from the start (critical: if you don't specify it from the beginning, Make will make architecture decisions that are hard to correct later)
- What business objectives should the design reflect?
Team example — BryanC uses a ChatGPT project as a research base and to prepare the initial prompt before opening Figma Make
"It's better to get the initial generation as close to your vision as possible with only minor tweaks needed — fixing the output with multiple follow-up prompts takes much more time."
— Ana Boyer, Designer Advocate, Figma| Element | What to include |
|---|---|
| Task | What Make should do in this project |
| Context | Where this flow fits in the product and who it's for |
| Key design elements | Important features it should incorporate |
| Expected behaviors | What happens when the user interacts |
| Constraints | Device, size, visual style, tech stack |
| Business logic | Business rules the design must reflect |
Guidelines are persistent instructions that tell the agent how to work throughout the project, not just what to do on each prompt. They're like a permanent brief.
- Always update them through the chat, not by editing the file manually — the agent interprets its own instructions better than ones you write by hand
- If you agree on something in the chat, explicitly ask it to incorporate it into the guidelines so it doesn't forget
- You can refine them throughout the entire design process
Team example — BryanC structures the guidelines as a markdown file inside the project. The agent reads them before each interaction and follows the defined conventions.
In addition to the agent guidelines, you can add separate reference documents that the agent consults when needed. This keeps the guidelines clean and focused on the how, while support documents explain the what and the why.
- Business logic — defines the system rules: roles, permissions, state flows, validations, data models. The agent consults it to make architecture decisions consistent with the business.
- User guide — describes the system from the perspective of the people who use it: roles, main flows, use cases. It helps the agent understand the real context before designing.
BUSINESS_LOGIC.md — Defines the business rules, state flows, data models and system validations. The agent uses it to make coherent architectural decisions.
USER_GUIDE.md — Describes the system from the user's perspective: roles, main flows and use cases. Gives the agent the real product context before designing.
"An interesting thing I am finding with Make is that it works better if it understands the situation and objective rather than just being told what to do."
— WarwickMake one change at a time. Don't ask for everything at once.
✗ Wrong
"Change the colors, add the signature, move the button and make everything responsive"
✓ Right
One specific change per prompt. Give context for why, not just what. Including reference images improves precision.
JP adds: use Claude, ChatGPT or another LLM to prepare and refine the prompt before bringing it to Make. Together with reference screenshots and the design library, the result is more consistent.
"Figma Make, like all AI products, tends to work better when it has only the context that's relevant for its current task."
— Documentación oficial de Figma MakeDon't mix different functionalities in the same Make even if they belong to the same product. A cash closing and a sales report → two separate Make files.
This is the most important point of confusion for people coming from Figma Design.
Figma Design
A page is an organizational tab. You can move or rename it without technical consequences.
Figma Make
Each page is a real prototype route — like URLs on a website. Renaming it changes real code.
Ejemplos: /, /work, /services o deals/1, deals/1/edit → son URLs reales del prototipo, no tabs.
Pages are for structuring product flows, not for saving versions.
To version: ask the agent to copy the current version's code to a new page — don't duplicate the page from the menu, that doesn't preserve the code state.
Pages in Figma Make are real prototype routes — home, deals/list, deals/detail--pending, allocation-settings, deals/new. Each one generates its own component and route in the router.
- Well-configured Auto Layout in frames — it's the most critical parameter for a good code translation
- Layers named by content ("btn-primary"), not by position ("Rectangle 47")
- You can use Figma's "Suggest Auto Layout" and "Rename layers with AI", or the Clean Document plugin
Example of a well-structured Figma Design file: a single page with correctly named layers and Auto Layout applied. This is the type of file that translates well to Make.
| Figma Make is for | Figma Design File is |
|---|---|
| Quick exploration of ideas | Definitive design decisions |
| Interactive AI prototypes | Team's source of truth |
| Quickly iterate flows | Dev handoff |
| Kickstart a concept | Implementation reference |
Correct flow: Make → copy screens → Figma Design File → Dev handoff.
The Figma Design File as source of truth — pages organized by flows, frames with dev annotations, components documented and ready for handoff.
The official Figma documentation records a real error that can occur in large projects:
- More pages = more tokens per interaction, even if you're not editing them
- Large and complex frames = heavier responses
- Irrelevant content = noise that consumes tokens without improving the result
Step 1 · get_metadata
High-level map — only IDs and structure. Lightweight. Use it first to identify which nodes you need.
Step 2 · get_design_context
Call it only on the specific nodes you need. Not on the entire file or whole page.
"Break screens into smaller parts (like components or logical chunks) for faster, more reliable results."
— Official Figma MCP documentation · developers.figma.comWorkflow A · Figma MCP
- You have a Design File with node URLs
- You need component-level precision
- You want to extract assets, spacing, tokens
Workflow B · Code Bundle
- Your source is a Make URL
- You need full-screen parity
- You want a local reference in the repo
The most robust strategy is hybrid: Code Bundle as primary source for flows and screens → MCP as a precision tool for specific components.
- In Make: Code → Download code → save the ZIP
- Extract to
docs/design/figma_make_code/ - Ask the agent to analyze the bundle and generate an implementation checklist
- That checklist is the sprint
Copilot Instructions
- One per workspace
- Defines project context and code conventions
- For decisions: ask for options + pros/cons + recommendation
Agent Rules
- You can have multiple
- Defines consistent and repeatable behavior
- Ex: smoke test → fix → build → deploy
8 Essential Tips for Using Figma Make
Official blog · Prompting tips, scope per Make, clean files, agent behavior
Figma MCP Server — Tools and Prompts
Technical documentation · get_design_context, get_metadata, tokens and limits
developers.figma.com/docs/figma-mcp-server/tools-and-prompts
Avoid selecting large, heavy frames
Technical documentation · How to reduce context size and improve results
developers.figma.com/docs/figma-mcp-server/avoid-large-frames
Write design system guidelines for Figma Make
Technical documentation · How to structure guidelines.md so the agent follows design system conventions
developers.figma.com/docs/code/write-design-system-guidelines
Guide to the Figma MCP Server
Help Center · Installation, setup and use cases for the official MCP server
Introducing the Figma Dev Mode MCP Server
Official blog · Strategic context, tokens, design system integration and Code Connect