Figma’s big idea with Make kits and Make attachments is pretty simple: stop asking AI to invent your product from thin air, and instead feed it the same ingredients your team already uses to ship real features.

If you’ve played with any AI UI generator, you’ve probably seen the pattern. You type in a prompt, the tool spits out a decent-looking screen, and for a moment, it feels like magic. Then reality hits: the buttons aren’t from your design system, the forms don’t match your validation rules, copy is lorem ipsum, and all the tricky edge cases you argued about in planning are nowhere to be found. What looked like a head start turns into an editing marathon where you slowly drag the AI’s output back to the world your product actually lives in.

Figma is trying to cut that busywork out of the loop. Make kits are their way of teaching Figma Make about your design system, using the same building blocks your engineers and designers already rely on. Design system owners can wrap up code components from npm packages—pulled from public or private registries—or styles and tokens from Figma libraries, then layer detailed usage guidelines on top. You’re not just saying “here’s a button”; you’re telling Make which button variants exist, when to use them, and how layouts should come together on real surfaces like forms, dashboards, and settings pages.

The payoff is that Make doesn’t start from a generic v1 anymore. When you generate a flow, it’s built from production-aligned components that mirror your codebase’s structure, so the v1 looks like something your team might actually ship. That has a few knock-on effects: teams can generate in parallel without drifting from the design system, reviewers spend less time fixing mismatched components and spacing, and engineers recognize the patterns instantly instead of asking if everything on the canvas is custom. The conversation shifts from “this doesn’t match our system” to “does this solve the problem?”

Under the hood, Make kits are basically a structured contract between your system and the AI. The more specific you are in those guidelines—how navigation works, how inputs behave, how error states should look—the more reliable the generated prototypes become on repeated use. It’s especially useful for shared surfaces that every team touches: onboarding, account settings, billing, admin tools. Instead of each squad reinventing those flows with slightly different patterns, Make can crank out proposals that already conform to the shared language of your product. Figma’s roadmap here also hints at deeper integration, like replicating component structures directly from Figma libraries so the output is even closer to what lives in your files today.

But even the best design system doesn’t capture everything about a real project. That’s where Make attachments come in: they let you drag the messy, nuanced context of the work straight into your prompt. You can attach PDFs, markdown docs, CSV or JSON datasets, screenshots, brand guidelines, legal copy, images, media, and SVGs. Instead of writing a giant wall-of-text prompt explaining every constraint, you attach the source materials and let Make read them directly.

This shift becomes obvious when you’re working on something ugly and real, like a full-onboarding flow. You might be dealing with actual user data structures, multiple validation states, legal text that can’t be shortened, and migration rules from an older system. In the past, an AI prototype might “clean up” your problem—trimming legal copy, simplifying form states, and smoothing out edge cases to produce a neat but unrealistic flow. With attachments, Make is forced to confront the real thing: the long legal strings, the weird edge values in your dataset, the constraints buried in the product spec. The result is a prototype that surfaces layout issues earlier and forces the team to reckon with what will actually ship, not a fantasy version.

Attachments also lower the bar for teams that don’t have a formal design system. You can still ground a prototype in reality by attaching tone-of-voice docs, screenshots of existing surfaces, brand rules, or even snippets of code. That keeps stakeholders from reacting to vague placeholders; instead, they’re looking at UIs that already speak in the right voice, use realistic data, and obey real-world constraints. Because attachments are project-specific, they flex across workflows—from content-heavy marketing flows to highly constrained internal tools.

There’s a bigger pattern here: Figma is trying to make AI prototypes feel less like one-off mockups and more like the first draft of production work. With the Figma MCP server stitching design and code together, the same components and structures that Make uses to build a prototype can be reused in code workflows, reducing the gap between exploration and implementation. For teams, that should mean less time reinterpreting AI output and more time iterating directly on something engineers can recognize and build from.

Put together, Make kits and Make attachments turn Figma Make into a more grounded starting point. Instead of AI inventing a UI and you spending hours dragging it back toward reality, you bring your reality in up front—your components, your data, your rules, your content. AI becomes less of a fantasist and more of a very fast collaborator that already speaks your product’s language.