Rethink How You Spend Figma Make Credits
Since launching the AI prototyping workflow, a clear pattern has emerged: Teams that get the most out of Make aren’t necessarily writing longer or more elaborate prompts. They focus on how they set up their work, scope their edits tightly, and prepare their context. Below are seven practices that can help you build faster without running through credits on unnecessary back-and-forth.
1. Front-Load Your Ambition Into the First Prompt
Your first prompt is the foundation—more than that, it’s a brief. The more intentional you are with that first input, the less course-correcting you’ll do later. Treat it as the baseline: Include the overall goal, the relevant context, the key elements and constraints, and a clear definition of what successful completion looks like.
After that base is set, follow-ups become small deltas. Each one should answer three straightforward things: what to change, how to change it, and what must stay untouched.
For larger builds, resist the urge to refine content immediately. Prioritize getting the structure right—it’s the hardest thing to alter later—then layer on the intelligence and behaviors. Add polish only after the foundation is solid. If you need to make multiple edits in a single follow-up, it’s efficient only if they all reside in the same component or logic block. Bundling unrelated changes just makes the model work harder to interpret scope.
Specificity is patience. Prompts like “Update the calendar component,” “Add a new state to this screen,” or “Edit the tokens.ts file” direct Make exactly where to look. A prompt like “That’s not right, can you redo it?” forces the model to guess both the problem and the solution—a waste of a request.
2. Match Task Size to the Right Output Channel
Not every change needs a follow-up prompt. The Edit tool is ideal for moving the needle on small visual fixes like spacing, text tweaks, or removing an element. In code, Go to source lets you jump directly into files—often App.tsx or another component file—and modify the offending value right where it lives. This is critical when data is dynamic, like text that repeats across a list item and remains invisible from the preview pane. Make code is readable enough that locating the issue is feasible even without a developer background.
Use the ⌘F shortcut to find the specific tag or data source when you’re in the code view. This applies to larger visual flips too: Grab Copy design to move your Make preview over to Figma Design. There, you can restyle the layers using the native tools and prompt Make with that result as direct context. Combining copy-paste editing with a single contextual prompt is often more efficient than working through three rounds of visual guesswork in Make.
The short version: Reserve model calls for generation and complex reasoning. When the change is purely visual and requires a nudge, don’t ask—do it yourself.
3. Standardize Static Rules and Repeating Workflows
If your prompts sound repetitive, stop repeating them. Translate that recurring instruction into a guidelines.md file. Good guidelines act as standing project memory and cover naming conventions, preferred design patterns, the quality bar to hit, and where the truth lives for common decisions. This approach pays you twice: shorter prompts and more consistent, better-first-try outputs.
Treat the guideline file as infrastructure. Structure matters—break a monolithic file into smaller supporting .md files for specific domains like components, motion, or tokens. Keep headings clear and naming semantic so the model can parse its rules without drowning in a wall of text.
Guidelines operate as ambient context. For recurring actions, move to skills.md files. Skills are on-call workflows you invoke only when a specific task arises. A guideline defines what Make should know; a skill defines what Make should do. Turning a recurring multi-step chore (e.g., “Review screen against standards” or “Scaffold from a PRD”) into a skill removes that boilerplate from every future trigger.
4. Give Make the Right Context, Not All of It
When Make uses external sources through MCP connectors, scoping is everything. Use connectors when the task depends on a live spec, a bug report, or a custom system. But remember that sending Make into a giant Notion page or asking it to sift through a lengthy ticket can dilute efficiency—it has to interpret noise before it can act.
Narrow the retrieval range. Point to the specific file, URL, or ticket. If your answer lives in one paragraph, paste the excerpt directly into the prompt rather than forcing Make to find it. For documents you already possess, use file attachments. Bring a PDF readout direct into the thread for a research summary, or feed a CSV for dashboard and screen population. Media or video files can supply the raw material instead of prompting Make to fabricate a placeholder from thin air.
Skills also enhance context controls. Embed precise steps in a skill for how Make should use a connector or custom MCP, and you get more controlled outputs. Efficiency is about improving the signal-to-noise ratio in the prompt, not maximizing the quantity of data attached.
Reuse shared foundations instead of starting from scratch
Building the same UI repeatedly in Make is a direct drain on your credits. Both Make kits and templates provide jumping-off points that already include context, reusable patterns, and working structure. This approach avoids blank-page prompting, reduces the chance of hallucinations, and gives more people on a team a strong starting point quickly.
Make kits function as shared system ingredients—they help distribute foundations, tokens, components, and guidelines.md when you are working from 0→1 in Make. For teams with React components available as an npm package, this is especially powerful: Make kits can bring the components and patterns your development team has in production into your projects, instead of approximating them from scratch.
Templates, on the other hand, give your team reusable starting points: product shells, preferred layouts, and even starter prompts. This is particularly useful for larger teams scaling Make across varied levels of AI fluency and multiple product areas. Designer Advocate Laura Fehre’s open source SAP template, for example, contains fixed UI elements (header, navigation) shared by all products, alongside strict guidelines to make sure prompts can’t easily change them. It also includes "recipes" that help template users spin up specific themes and layouts on demand, living directly in the template's UI as ready-made, code-based prompts—click to copy, then paste into Make.
That kind of setup does two things at once: it makes the template more immediately useful and it teaches people how to use it well. The result is less rework, fewer dead ends, and a more reliable path to the prototypes the team actually wants to build.
Match the model to the task
No single AI model is the best fit for every Make workflow. The right choice depends on how complex the job is, how much reasoning it requires, how much visual context you’re attaching, and how refined the output needs to be. A good rule of thumb is to choose the lightest model that can handle the task well.
If you’re making a small change or doing routine iteration, a lighter model like Gemini Flash is often the better fit. If the work is more ambiguous, involves tougher debugging, requires stronger reasoning, or needs to preserve a lot of visual fidelity, a stronger model like Claude Opus may get you to a better result faster, albeit at a higher cost. In those cases, investing more upfront can actually be more efficient than spending many rounds correcting a weaker first pass.
This is especially true when you’re starting a new Make file or attaching rich visual context to a prompt. Design mockup attachments can be extremely helpful when you want Make to align to an existing direction. But the more intricate the design file, the more Make has to interpret it. If you’re front-loading Make with a lot of context at once, either use a model that can handle the complexity well, or reduce the context to only what matters for the current step.
Long-running Make projects also become heavier over time. As chat history builds up, each new turn gives Make more context to consider, which can compound cost—especially with more expensive models. When that happens, clearing your chat context can give Make a cleaner slate without forcing you to abandon the project or move everything into a new file.
Choose what to automate deliberately
The teams getting the most value from Make aren’t just teaching individuals how to use it better. They’re deciding, together, where it fits in their workflow and where it doesn’t.
That might mean reserving Make for bringing existing designs to life rather than 0→1 exploration, where ambiguity and iteration can be valuable. It might mean using it to accelerate prototyping, but not to replace manual craft in areas where the team already moves quickly and confidently. It might mean investing in templates, guidelines, and kits because the payoff compounds over time.
Not every task benefits equally from automation. The strongest teams know where Make adds leverage, where human precision still matters most, and where a bit of setup work up front will save a lot of effort later. The goal isn't to automate everything—it's to make better decisions about what to automate and how. Sometimes the most efficient investment is the one that costs a little more attention up front: a better template, clearer guidelines, cleaner prompts, or a shared team playbook. The payoff is that every project after that starts from a stronger place.
For more guidance on prompt optimization for Figma Make credits, visit the help center. If you've found other approaches for working more effectively in Make, share what you're building online or in the Figma Forum.
