Closing the gap between AI drafts and production UI

AI-generated designs can look polished in a first pass, but they often fail where it matters: they don't use your components, your data, or your constraints. The result is a draft that needs rewriting rather than refining. Figma's answer is to give the generator context it can actually act on, through two new capabilities in Figma Make: Make kits and Make attachments.

Make kits provide design system context drawn from code, while Make attachments supply project-specific context from the files you're working with. Together, they aim to shift the starting point of a prototype from a generic approximation to something grounded in how your product is actually built.

Make kits: encoding your design system for AI

Make kits are reusable, customized packages created by design system authors. They combine a library's components or styles with detailed guidelines that teach Make how to use them. Components can be brought in via npm packages, either from a public registry or Figma's secure private registry, or through styles and tokens from a Figma library. The guidelines go beyond listing what exists; they explain how each piece should be used.

The practical impact is a change in where iteration begins. Previously, you might generate a generic v1 and then prompt for refinements—fixing spacing, swapping in the correct patterns, and matching components to your system. With Make kits, the initial output already aligns with production components and structure. That means less cleanup before a design is ready for review, and a shorter path from prototype to shipped code.

This is most visible on shared surfaces that span teams and workflows. Kits help maintain consistency across forms, dashboards, settings, and onboarding flows. Teams can generate in parallel without drifting from the design system. And because engineers recognize the components and patterns immediately, reviews focus on the proposal itself rather than on translating a design into familiar terms.

Looking ahead, Figma is working to extend kits further—including replicating component structures from Figma libraries—so output reflects your design intention whether it lives in code or inside Figma.

Make attachments: grounding prototypes in project reality

Design systems cover the building blocks, but every project has context that can't live in a component library: real user data, legal copy, migration constraints, edge cases, and compliance rules. Make attachments are designed to bring that context in.

Attachments accept multiple file types, including PDFs, markdown files, CSV and JSON datasets, screenshots, brand guidelines, images, media, and SVGs. Instead of trying to summarize everything in a long text prompt, you attach the source material directly, and Make references it.

Consider a full onboarding flow. With real legal requirements and multiple validation states, a prompt tends to produce an idealized version—shortened legal copy, simplified states, dropped edge cases. With attachments, Make sees the actual spec and data. Real values reveal layout constraints, and edge cases surface early in the UI. The prototype becomes a grounded working draft.

This extends to everyday workflows. You can pull in brand guidelines, tone-of-voice documents, screenshots of existing surfaces, and real datasets, so stakeholders are reacting to something much closer to the final product. Attachments are flexible and project-specific; they work for a content-heavy flow, a data-constrained interface, or an evolution of an existing screen. A formal component library is not a prerequisite.

Bringing design and code closer together

When prototypes are built from real packages and realistic content, they become easier for the whole team to interpret. Reviewers spend less time filling in missing context. And with the Figma MCP server connecting design and code workflows, the same components used in Make can carry over into code generation, reducing the need to rebuild from scratch.

Make kits and Make attachments reframe Figma Make as a starting point grounded in how a product looks, feels, and behaves—not a generator of generic first drafts.