Figma Make Usage Manual (Operations and Use Cases for Basics/Templates/Importing Design Library Styles/Adding Guidelines/Open Source Components/Adding Backend/Publishing)

What is Figma Make (one-sentence explanation for PMs): An AI tool built into Figma — you describe what you want to build in plain language, and it directly generates a clickable, runnable, shareable prototype or web application, no coding required. You can think of it as "a ChatGPT that can code, but instead of outputting text, it produces an interactive product demo".

The biggest difference between it and the Figma you know (which is for drawing static mockups):The output of Figma Make is alive— buttons actually work, forms can actually be filled in, data can actually be stored (after connecting a backend), and it can even be published as a real URL for others to access. For PMs, it compresses the cost of "I want to verify if this idea is worth building" from "scheduling and waiting for engineers to build a demo" to "chatting it out yourself in half an hour".

This article is a functional operation manual: broken down into seven modules, each answering three things —how to operate / why do it this way (Why) / when to use it. It does not cover "the overall process methodology of AI doing design" (that is AI-Assisted UX·Experience/UI Design Stages (Prompts and Processes for Using AI to Generate Beautiful UI·Design Systems·Color Schemes·Interaction States·Microcopy·UI-to-Code Figma·Responsive Design)), nor does it expand on the mindset level of vibecoding (that is AI-Driven Product Design / Vibe Coding Process (One-Sentence Requirement → Interrogation → PRD → DRD + Coding Prompts → Figma Make Demo → Publish → Visual Iteration)), and only focuses on how to use the Figma Make tool itself smoothly.

Seven modules: 1.Basics(three-column interface + four input methods) 2.Writing Good Prompts and Feeding Attachments(the core skill that determines generation quality) 3.Templates(turn specifications into reusable starting points for the team) 4.Importing Figma Design Library Styles(make AI-generated UI match your company's visual identity) 5.Adding Guidelines(set long-term rules for AI) 6.Feeding with Code/Data Files + Open-Source Components(make prototypes close to real products) 7.Adding a Backend + Publishing Online(from "demonstrable" to "actually usable, actually accessible")

1. Basics: Three-Column Interface + Four Input Methods

1.1 There are only three sections in the interface, first understand their division of labor

The Figma Make workspace has three columns. Figure out what each does, and all subsequent operations will be smooth:

Area	What it does	Analogy
AI Chat (Conversation Area)	You type requirements here, and AI generates or modifies the application based on them	Discussing requirements with a programmer colleague
Preview (Preview Area)	See the real running state of the generated application in real time, clickable and interactive	The "live demo" of the product
Code (Code Area)	Directly view/edit the code generated by AI	Under the hood (PMs usually don't touch it, but you can ask AI to explain it when problems arise)

Why you need to understand this first: Many people think Figma Make is like a chatbot with only a dialog box, but in fact the "preview" is where you judge whether something is right or wrong, and "code" is the entry point for advanced actions (modifying guidelines, viewing plan.md). The linkage of the three columns is the essential difference between it and text-only AI.

1.2 Four ways to feed your "ideas" to AI

You don't only have to type. The closer your input method is to the picture in your head, the less likely AI is to guess wrong:

Type descriptions (Generate with text): Write requirements in the conversation area, add details gradually, and AI builds the complete application step by step.When to use: The primary method when starting from scratch or making iterative adjustments.
Paste Figma designs (Paste a design): Copy existing frames or components from Figma into the conversation area.Why: Directly give AI a structured design skeleton, which is much faster than verbal description.When to use: You have already drawn mockups in Figma and want to make them "runnable".
Upload/paste images (Use images):Click + → Upload image, or directly paste screenshots/sketches/reference images into the conversation area, and AI generates the interface based on the images.When to use: You only have a reference image or hand-drawn sketch, and haven't drawn formal mockups yet.Pitfall: Images can only help AI "get close" to your expectations,they do not equal precise reproduction— for example, the model may not accurately read the exact color values in the image.
Click the preview to make targeted edits (Point to edit): Use the Edit tool in the preview to directly select a UI element, then say "Change the spacing/color/copy of this section to…".Why: Saves you the trouble of using text to locate elements like "that blue button on the right of the second row".When to use: Making fine adjustments to a specific section, not major overhauls.

There is also a reverse capability:Copy the preview as design layers(Copy design layers) and paste it back into Figma Design for further refinement. Used when AI has produced a rough structure and you want to go back to Figma to manually polish the visuals.

2. Writing Good Prompts and Feeding Attachments (The Core Skill That Determines Generation Quality)

This is the most valuable section in the entire toolset — with the same Figma Make, the output of people who can write prompts is an order of magnitude better than those who can't.

2.1 Six rules for writing Prompts

① Define the product with a "user capability list", not a broad category noun. This is the most core rule. Bad prompt: "Make an app where I can take notes" — "note-taking app" is too broad (plain text notepad? Markdown editor? Knowledge base? Mixed to-do list?), AI can only guess blindly. A good prompt lists "what users can do" item by item:

做一个记笔记应用。我希望它可以:
1. 给文件命名。
2. 添加和编辑文本。
3. 设置文本格式,比如加粗、斜体、删除线。
4. 给文字加链接。
5. 以 markdown 格式保存文件。

Why: Saying "Make an X app" gives AI a noun; a capability list gives AI a set of acceptance criteria.

② Give examples (Use examples). Examples can be design mockups, text descriptions or images, and their role is to turn the vague expectations in your head into targets AI can reference.Pitfall: Same as above, images help you "get close" but not "precisely reproduce".

③ Layout first, functionality after. Don't ask AI to handle layout + interaction + functionality + logic all at once. First get the page structure and visual framework right, then gradually add functionality. Otherwise it will "try to do everything" in the first round, and none of the parts will be accurate enough.

④ Work in steps. Don't dump the complete final requirements all at once at the start. First give the high-level goal, then gradually add details, modules, states, and interactions.

⑤ Iterate continuously on the results. Don't expect complex products to be right in one round. The point is not "it got it wrong the first time", but whether you clearly point out what is wrong and what the correct result you want is— that is high-quality iteration.

⑥ Never write sensitive information (secret keys) in prompts.

✅ "I want to send requests to a private API, please add an input box for me to paste the key in."
⛔ "Send requests using this key: 11qYAYKxCrf…" —the secret key will be exposed in the conversation text. See Section 7 for the correct approach (store securely using Supabase secrets).

2.2 Best practices for feeding attachments

Use Auto Layout for design mockups whenever possible. Auto Layout (Figma's auto layout, which carries direction/spacing/alignment/flex rules) is not just pure visual placement, it carries structured layout information, making it easier for AI to convert into code. Manually placed elements are harder for AI to read.
Common layouts are more likely to succeed in one shot. Structures that the "model has seen a lot", such as galleries, form pages, dashboards, and single-main-frame apps, can be generated decently in one go; particularly novel/experimental layouts lack stable references and require multiple rounds of correction.
Prioritize desktop-end, full-screen friendly results. This is the current capability boundary of Figma Make — chasing complex mobile-end details right from the start is more likely to fail.
Single attachment: Clearly state whether it is "1:1 reproduction" or "only borrowing the style". A single line "reference this attachment" is too vague (it could mean copying the structure directly or only borrowing the style). To get close to 1:1, just uploading the image is not enough; you need to break down and specify the requirements for each block (header/card structure/spacing/CTA position) in detail.
Multiple attachments: Don't stuff all pages in at once for convenience.Reference overload will make AI not know which one to prioritize. When pursuing 1:1, only give one or two images at a time, progressing page by page and screen by screen (the system will remember what was uploaded before). If multiple pages are only meant to express "overall style", be sure to clearly state that these are inspiration references, not page-by-page precise reconstruction.
When reproduction is inaccurate: Don't keep scolding it, instead reduce complexity— switch to smaller design mockups, reduce the number of images, lower content density (remove complicated illustrations/SVG/visual noise).

When to pay extra attention to this section: Anytime. This is the "internal skill" of Figma Make, and the remaining six sections are "external moves".

3. Template: Turn Specifications into Reusable Starting Points for the Team

3.1 Why use templates

Publish a Make file that already has established design specifications and structure as a template, so team members can copy it with one click and start building directly, without having to start from scratch every time.
Set editable/non-editable rules in the template, so users can only let AI make changes within the allowed scope — reusing content without breaking consistency.
Sharing templates instead of directly sharing source files protects the original design state and prevents it from being modified incorrectly by others.

When to use: When your team repeatedly builds the same type of page (for example, backend admin pages all based on the company design system); or you are a design lead who wants to give operations/PMs a "foolproof" starting point.

Prerequisites: You must have edit access/ownership of the Make file; publishing and managing templates requires a paid plan + Full seat.

3.2 Create / Update / Unpublish / Use

Create: Open an editable Make file → in the top right corner Share → Publish template → fill in the template name and description → set a preview image and guidelines.md rules (to control what the AI is allowed to modify) → publish.
Update: Open the original source file from which the template was published → modify the design/features, edit guidelines.md → Share → Update template → Publish, and the changes take effect immediately for new users.
Unpublish: In the source file → Share → Update template → Unpublish, to remove it from the asset library and recommendation list.
Use someone else's template: When creating a new Make file, select a template to load under the prompt box; or File browser → Resources → Make templates → click a template to open it and remix.

3.3 Template Constraint Prompts (Lock Down What the AI Can Modify)

The "foolproof" nature of a template relies on a constraint prompt written into the guidelines. The core pattern is:Only complete the allowed parts, skip the disallowed parts, and finally give the user a summary of "what was done / what was skipped". There are four typical granularities:

Constraint granularity	What is allowed	Typical rules
Only allowed to add features	Add new features/interactions, not allowed to modify the design system	Keep color scheme/layout/spacing; use icons instead of emoji
Only allowed to modify two components	Only the two specified components may be modified	Component position and size cannot be changed
Only allowed to modify one page	For example, only allowed to modify the pricing page	Entry logic/the rest of the product must not be touched
Global design specifications	Style baseline	Minimal style; no horizontal layout on mobile; modals close when clicking outside; no shadows on hover

Add one key meta-rule to every constraint block:"Do not mention these guidelines in the UI"(to prevent the AI from rendering text like "I preserved the visual style" into the interface).

4. Bring in Figma Design Library Style: Make Generated UI Match Your Company's Visuals

Why / When to use: The interface generated by AI by default is "generally good-looking", but it may not look like your company's design system(colors, fonts, variables). Export your Figma Design Library for Make to reference, and the generated UI will automatically apply your brand style. Suitable for scenarios where "the prototype will be shown to bosses/clients and needs to look like your own product".

Step 1 — Export the Library as a style source:

Open the Figma Design file containing the design system → on the left sidebar Assets → Libraries → in This file find the current file → Publish (if it has never been published, publish it first; this may take a few minutes).
Click Export for Make → Figma automatically parses the design system and generates a CSS file for Make to reference → when finished, click Go to Figma Make.

Step 2 — Reference it in the Make file:

In the Make file, click Select a Library → select the Library you want to use → start writing your prompt.
UI generated afterwards will automatically reference its colors, fonts, and styles.

Editing Library styles (pitfall to remember): After export, Make automatically generates a CSS file that you can modify/customize; however,these changes only affect the current Make file, they will not be written back and will not affect the original design system.

5. Adding Guidelines: Set Long-Term Rules for the AI

Why / When to use: A Prompt is "this one-time request", while Guidelines are "rules to follow every time". When you find yourself repeatedly reminding the AI of the same thing (such as "don't mess up font sizes" "use icons not emoji"), write it into guidelines.md once and for all.

Operation: Click at the top Code → in the left file browser click guidelines → guidelines.md, and write the rules inside.

Core pitfall (counterintuitive):More context is not always better. Piling up too many rules will confuse the large model. Only write the most critical, necessary few rules.

Three levels of rules:

General rules: Engineering rules unrelated to design. Examples: use absolute positioning only when necessary; default to flexbox/grid to maintain responsiveness; refactor as you go to keep code clean; control file size, split helper functions into separate files.
Design system rules: Make generated results look like your company's design system. Examples: base font size 14px; dates fixed in "Jun 10" format; bottom toolbar has at most 4 items; if there are ≤2 options, do not use a dropdown; Chips must appear in groups of at least 3.
Component-specific rules: Create a separate file for a single component (right-click guidelines → Create new file), and write detailed usage rules for that component. For example, Button: three variants (Primary/Neutral/Subtle) + ButtonDanger for destructive actions such as deletion; place only one Primary per page as much as possible; copy is short with no line breaks, uses sentence case, and retains :focus focus styles.

Related: The "template constraint prompt" in Section 3 is essentially a special rule written into guidelines (to lock the editable scope); this section covers broader "rule-setting".

6. Feeding Code/Data Files + Open-Source Components: Make Prototypes Close to Real Products

6.1 Four types of text files you can upload

Figma Make can accept four types of text files,with a 1MB per-file limit(split/compress if exceeded):

Category	Format	What it provides to the AI
Code files	`.tsx` `.js` `.ts` `.jsx`	Component structure/frontend logic, letting the AI extend and refactor on top of existing components
Markup and styles	`.html` `.css` `.md` `.svg`	Webpage structure/styles/documentation, converting static webpages into modular interactive interfaces
Data files	`.csv` `.json`	Real data, automatically generating lists/tables/data dashboards
Plain text	`.txt`	Real copy/FAQ/marketing content, letting typography reflect real-world length

6.2 Five common uses (each = one Why)

Generate data dashboards with real data: Upload an Excel-exported .csv or API-returned .json, and the AI reads the field structure to generate corresponding tables/leaderboards/charts.Why: The prototype no longer uses fake data and is closer to a real product.
Generate interfaces based on API responses: Save an API example as .json and upload it to generate user lists/profile cards/detail pages with a structure consistent with the real system.
Reuse ready-made components: Upload open-source React components (.tsx/.jsx) as base parts, and let the AI build new pages on top of them instead of drawing from scratch.
Lay out with real copy: Organize product introductions/FAQs/marketing copy into .txt/.md and upload to automatically generate Hero/Features/FAQ/CTA sections.Why: Only with real copy can you tell whether the layout makes sense (placeholder Lorem ipsum cannot show that).
Turn static webpages into interactive interfaces: Upload the .html+.css of an existing template, and the AI splits it into reusable components, optimizes layout, adds interactions, and upgrades the static page into a Web App prototype.

6.3 Optimize UI with open-source components (shadcn/ui as the main option)

shadcn/ui is an open-source, beautifully designed UI component library suitable for B-end admin backends, and is one of the default choices for generating UI in AI coding / vibecoding (similar options include Flowbite, MUI, Tailwind Plus).

When to use: When you feel the AI's default interface is "not professional enough / inconsistent" and want to replace the whole site with a mature, standardized component style in one click.

Key technique — strongly constrained "full-site refactor" prompt: Ask the AI to replace every native HTML element in the entire project with the corresponding shadcn component one by one (button→Button, input→Input, modal→Dialog, table→Table…), and set a few hard rules:

Only modify the UI layer and styles, fully preserve business logic, state, data structures, interactions, routing, and copy — do not delete features, do not simplify, do not rewrite product logic.
Stay close to shadcn visual specifications: neutral backgrounds, restrained borders,rounded-md/lg rounded corners, balanced spacing, consistent typographic hierarchy, muted secondary text.
Refactor every page, not just the current file; if there is no corresponding component, adapt using the closest shadcn pattern; do not leave old HTML styles.
(Strict version) Directly output runnable complete code changes, no explanations, no plans.

Pitfall: This kind of "full refactor" is a major operation; be sure to emphasize "preserve all existing features" in the prompt, otherwise it is easy to break the logic while refactoring styles.

7. Adding Backend + Publishing Online: From "Demoable" to "Truly Usable, Truly Accessible"

7.1 Adding a backend (Supabase): Give the prototype memory

Decision mnemonic (most important): When building, just ask one question —"Does this thing need to be remembered?" If yes (user information/tasks/login state/form content/API key) → you should connect a backend.

Key concepts (for non-technical PMs):

Backend: The invisible layer of the system responsible for storing data, remembering users, login authentication, and saving keys.
Supabase: The backend service platform currently integrated with Figma Make (a website that helps you quickly build an app backend), providing database, user login, storage, and key management. Figma Make does not directly run a backend itself; it provides capabilities through Supabase.

The simplest connection method — add it directly via chat:

Just say it directly in AI Chat, for example Add user sign-in / Add authentication to my app / Call OpenAI API.
A prompt pops up asking you to connect Supabase → click Connect → the browser opens the Supabase page (log in/register first + authorize Figma).
Follow the prompts to create/select an organization (projects must belong under an organization) → Authorize Figma.
Return to Make, select an existing project or create a new one (fill in Project name / select a Region close to your users / set a Database password; note this is the database password, not your account password) → Create project.
Go back to AI Chat and continue describing the features you want (a feedback collection form, a to-do list that can save tasks, a check-in tool with login…).

Securely save keys/API Keys (corresponds to Section 2 "Don't write keys in prompts"):

First make sure a backend is connected (keys are stored in Supabase; without a backend there is no secure storage location).
In chat explicitly say to create a secret, for example "Make a weather app and create a secret for the API key."
An Create a secret input field appears in the interface → paste the key in → Create secret. This is the official allowed secure entry point;never write Use my key: sk-xxx.

Managing the backend: In the top right of the Make file Make settings → on the left Integrations → Supabase → find the row for the current project, click the ellipsis → Manage project (backend dashboard) / Manage organization (team space) / Manage secrets (key management).

7.2 Taking the code with you: Push to GitHub / Download ZIP

Why / When to use: When the prototype needs to be handed off to engineers to continue in a formal development workflow, or when you want version control with rollback capability.

Download code:Code Editor → Download code → you get a ZIP → open it in VS Code/IDE.Pitfall:Code modified after download will not automatically sync back to Figma Make(one-way).
Push to GitHub:Make settings → GitHub → Connect GitHub → select an account/organization → choose to authorize "all repositories" or "selected repositories" (this has no actual functional impact but GitHub requires a choice; Figma Make only accesses repositories it creates itself) → Install & Authorize. After that, every update can be synced.

Advanced supporting actions (from advanced workflows):

Have the AI explain the code: Enter Explain the code of this app to me. Start at a high level. in chat, and the AI will explain the project structure, core logic, and the purpose of each file. For designers who cannot read code.

Plan before modifying (plan.md): Directly modifying code for complex apps is error-prone. First ask it to only generate without modifying:Don't make any changes... Create a file called plan.md... write down a plan; review/modify this plan in the Code Editor; then ask it to Use the latest version of the plan in plan.md to make changes.

Support multiple users: One prompt to have it implement registration/login/per-user independent data storage using Supabase.

7.3 Publishing online

One-click publish to a web URL: Open the finished file → in the top right Publish → fill in the Title (displayed in browser tabs/search/share cards)→ Publish, and you will get a URL (e.g. lunar-gala-73178537.figma.site) + publish status + timestamp.Pitfall: Changes made after publishing will not automatically sync to the website; you need to click Publish again. If you no longer want others to see it:Make settings → Unpublish(the URL will stay the same if you republish later).

Bind a custom domain(to change the URL to www.yourproduct.com):

First purchase a domain (Namecheap/GoDaddy/Aliyun/Tencent Cloud/Cloudflare) and publish your website first (domains can only be bound to published sites).
On the left side of Figma Settings → Site → Domains → Add connected domain → enter the domain name.
Figma officially recommends setting up a root-to-www redirect (more stable for SEO).
Figma will provide you with two DNS records: one TXT record to verify ownership, and one CNAME record pointing to cname.figma.site); copy them to the DNS settings of your domain platform → return to Figma and click Refresh, and when it successfully shows Connected.
wait for the HTTPS certificate to take effect (5–30 minutes).
Three pitfalls you will 90% encounter: DNS not yet propagated (propagation takes 5 minutes to 1 hour); incorrect CNAME record (it must exactly match cname.figma.site); Cloudflare users must turn off Proxy and set it to DNS only.

Why go through the trouble of configuring DNS: DNS is the "address book of the internet" — people remember domain names, while computers access destination addresses. The TXT record proves "this domain belongs to you / you authorize Figma to use it", and the CNAME record tells the whole internet "when visiting this domain, go to Figma's service". Once configured, others who type your domain will be directed to your site, and HTTPS will be automatically set up.

Uploading web fonts (an easily missed pitfall): If you used local fonts on your computer in Make, you must upload the font files before publishing, otherwise the website will fall back to default fonts (the Figma editor can use fonts on your computer, but visitors' browsers cannot see them).Publish If you see the prompt Missing fonts → Settings → Fonts → Upload upload .woff/.woff2 → then Publish again.

Advanced settings during publishing(determine how the site is seen/statistics/who can view it): Title, Meta Description (search snippet), website language, Google Analytics, No Index (prevent search engines from indexing), Favicon (tab icon), access permissions Public/Internal (Enterprise plan),password protection(suitable for demos/internal testing/client presentations), social share image (recommended 1200×630), custom code (insert analytics/customer service/tracking scripts into head/body).

Quick reference: overview of the seven modules and their uses

Module	One-sentence purpose	When to use
Basics	Three-column interface + four input methods (typing/pasting drafts/uploading images/clicking to edit)	Anytime, the first step for beginners
Prompt & Attachments	The core skill that determines generation quality	Always prioritize this
Templates	Turn standards into reusable starting points for the team	When repeatedly making similar pages / providing foolproof starting points for non-designer colleagues
Import design library styles	Generate UI that matches the company's visual identity	When the prototype needs to look like your own product
Guidelines	Set long-term rules for AI	When you always have to repeat the same instructions
Code/data files + open-source components	Make the prototype close to the real product	When you need real data/real copy/professional component libraries
Add backend + publish	From "demoable" to "actually usable and accessible"	When the answer to "Does this thing need to be remembered?" is yes / when you need to share and launch it

Division of labor with companion articles

This article = a functional operation manual for the Figma Make tool alone(how to click, how to write prompts, how to connect the backend and publish).
AI-assisted UX/UI design phase (prompts and workflows for using AI to generate beautiful UI, design systems, color schemes, interaction states, microcopy, Figma UI-to-code, responsive design) = The overall process methodology for using AI for experience design(how AI intervenes in the Discover→Define→Ideate→Experience Design→Deliver pipeline); Figma Make is only one of the tools in the "Experience Design / prototyping" stage.
AI-driven product design / Vibe Coding workflow (one-sentence requirement → interrogation → PRD → DRD + coding prompts → Figma Make demo → publish → visual iteration) = Vibe coding mindset(the mentality and process of "using natural language to direct AI to produce runnable outputs"); the "step-by-step iteration", "plan before editing with plan.md", and "strongly constrained refactoring prompts" in Sections 2, 6, and 7 of this article are concrete implementations of the vibe coding mindset on Figma Make.