Figma AI Editing Model: Training, Testing, and Trade-offs
See how Figma trains and evaluates an AI editing model with synthetic data, supervised fine-tuning, reinforcement learning, and designer-led quality checks.
Why Figma Is Training an AI Model to Make Better Design Edits
AI can generate a polished-looking screen and still miss what a designer actually needs. It might touch the wrong component, ignore a key instruction, break the layout, or produce an edit that's slower to fix than to redo by hand. In a design file, the result isn't just an image - it's a structured, editable system of layers, components, styles, and relationships.
That's why Figma is training a model specifically for design editing. Instead of treating every task like "generate a new thing from scratch," the focus is on the edits designers repeat every day: adjusting spacing, changing a color, or reshaping a layout based on feedback. Figma's work is a good example of what happens when you specialize a general model for a real product workflow.
This article looks at why design editing is hard for general models, how supervised fine-tuning and reinforcement learning fit together, what a credible evaluation process needs to measure, and where a specialized model can pay off for a business. The underlying lesson is simple: when the work isn't fully verifiable, training data and evaluation have to match the actual task - not just whether the output looks convincing at first glance.
Why is design editing different from image generation?
A design edit is a constrained change to an existing artifact. The model has to understand what's already on the canvas, figure out which parts matter for the request, and make the change without wrecking everything else. That's a different problem than generating a brand-new image from a prompt.
In a production design file, the visuals are only one layer of the job. A button can look right while using the wrong component. A layout can look nice while failing to do the specific thing the user asked for. Text can overlap, a control can get clipped, and spacing can drift out of sync with the rest of the interface. The design still has to work for the person who will keep editing it.
The canvas carries context
Designers work in small steps. A request like "make the product card easier to scan" depends on the existing typography, layout choices, brand conventions, and what the screen is meant to do. Some of that context is in the selected objects, but some comes from nearby content, reusable components, and the design system.
If a model treats the request like isolated text, it can produce an edit that looks locally plausible but doesn't fit the file. It might swap an established component for a lookalike, or make a tweak that clashes with the surrounding system. So the result depends on the model and on the context and tools it has.
Small tasks create a high bar for speed
Most day-to-day design tasks are modest in scope. That doesn't make them easy. Designers repeat them all day, and every pause adds friction. If an agent takes too long for a small edit, the user waits, inspects the result, and often has to redo it.
So latency, cost, and reversibility aren't side issues - they're part of product quality. A useful agent makes the change quickly, preserves what shouldn't be touched, and keeps the designer in control. A model that can produce something impressive but takes forever to get there can still be a bad fit.
Structure matters as much as appearance
Figma's approach represents designs in the platform's native file format, so the model learns to make changes that can be applied back to the canvas. The goal isn't only to describe how something should look. It's to produce a valid, editable change inside a real document.
This is a general point for AI systems built on professional software: the artifact has structure, and that structure reflects real decisions made by users over time. If a model respects it, it can support the workflow. If it doesn't, you may get something that looks fine in a screenshot - but costs more than it saves once people have to work with it.
How does Figma train a model to edit designs?
Figma describes a training setup that combines supervised fine-tuning (SFT), synthetic training examples, automated checks, and an ongoing investment in reinforcement learning (RL). The point isn't that any single method "solves design intelligence." Each one targets a different part of the problem.
Figma says that when this work began, frontier models didn't reliably understand Figma's design syntax. Getting them to make edits just through prompting would mean lots of instructions and high token usage. That can be workable for prototypes, but it doesn't fit well with speed, cost, and consistency requirements in a product. So Figma chose to train models directly on the editing task.
Build examples around the actual edit
For supervised fine-tuning, each training example pairs a starting design with an edit request and a successful version of the change. The model sees the artifact it has to work with and an example of what "a good transformation" looks like. When an edit depends on design-system assets, the pipeline can create prompts using themes and components.
Data quality matters. If the training examples only cover simple color changes, the model won't learn how to handle a layout revision or a component-based design. Synthetic data can expand coverage without requiring someone to hand-author every example, but volume isn't the same thing as quality. The generated tasks and answers still need checks that reflect how designers actually work.
Figma used larger teacher models to generate attempted edits, then evaluated candidate outputs with deterministic validators and visual model judges. The checks included whether the file was valid and whether the edit matched the request. The generation pipeline could also revise an edit based on evaluator feedback, which the company describes as self-healing.
Use SFT for grounding, then push generalization
SFT helps a model learn to imitate successful examples. Figma reports that an earlier Llama 3.3 70B model, trained on more than 250,000 examples, became competitive with leading models of that period on design-editing tasks. The takeaway is straightforward: with the right specialization, a smaller focused model can do well in a specific workflow.
But imitation has limits. A model may do fine on patterns it has seen, while struggling with unfamiliar combinations or edge cases. Figma also says SFT alone was less sample-efficient for this objective, requiring many examples across different parts of the task. More data can improve coverage, but collecting and validating it costs real time and money.
Add reinforcement learning where it helps most
Figma is also investing in RL, focusing on better design-domain environments, more diverse training examples, reward models, and criteria written by experts. The goal is to align rewards with what designers value, rather than treating a single visual score as the full definition of "quality."
That distinction matters. If the reward only measures visual similarity, the model can preserve the look while missing the instruction. If it only rewards task completion, it might make the requested change while damaging the design system. RL can help, but it depends heavily on the environment and reward signals. A poorly defined reward can teach the model the wrong shortcut faster than SFT.
How can you evaluate AI-generated design edits?
Design quality has a subjective side, but evaluation doesn't have to collapse into one vague "looks good" score. A practical approach breaks the problem into dimensions that can fail independently, then combines automated checks with expert review. Figma says it evaluates whether models can work in the design environment, follow instructions, and produce useful edits, along with the speed and cost of doing the work.
That combination is more informative than a single visual impression. A polished-looking screen can still miss the request. A technically valid file can still have an awkward layout. A control can look correct while swapping the wrong design-system component. Each kind of failure has different consequences, and it may point to a different fix in training or product design.
Separate structural, visual, and task checks
A useful evaluation setup can start with three categories:
- Structural validity: Can the edit be applied? Are the objects and relationships in the file valid? Did the change preserve the artifact's editable structure?
- Instruction fulfillment: Did the model change the requested elements and leave unrelated elements alone?
- Visual quality: Does the result maintain readable hierarchy, alignment, contrast, and layout integrity?
These checks catch different issues. Deterministic validators help for properties you can test reliably, such as whether the output is valid. Visual judges can spot patterns that are harder to express as strict rules, like overlaps or poor alignment. Neither one fully replaces the other.
Calibrate automated judges with designers
Visual evaluation can be misleading when a judge rewards the wrong thing. A model might score well simply because its output resembles a reference, even if the user asked for a different change. Or an automated judge might miss a subtle component mismatch that matters in practice.
Figma says it uses expert designers to calibrate and review evaluation results. That's not just a ceremonial step - it's a way to learn where automated scoring is reliable, where it disagrees with human judgment, and which criteria need refinement. Expert-written criteria can also feed into reward models as the training approach evolves.
If you're building similar systems, it helps to track the failure type, not just the final score. Did the model misunderstand the request, pick the wrong component, violate a constraint, or respond too slowly? That diagnosis points you toward the real bottleneck: context retrieval, tool behavior, training examples, evaluation, or the interface.
Include operational metrics
A benchmark is only one input into product decisions. Figma notes that its internal editing evaluations help assess candidate models, but they aren't the only factor in choosing what to ship. Production performance also depends on the agent's tools, the surrounding context, and the system that connects the model to the canvas.
You also want the metrics users feel day to day: completion time, cost per interaction, acceptance, and how often users undo or substantially revise an edit. Interpret these metrics together. A low undo rate can suggest better edits, but it can also mean users don't notice problems. Speed improvements only matter if quality and user control stay intact.
What does a specialized editing model change in practice?
A specialized model is most useful when it improves a workflow people repeat often enough for small gains to add up. For design teams, a faster first pass on routine edits can free up time for the decisions that actually require judgment. But an AI edit isn't automatically productive just because it arrives quickly. Users still need to review and correct, and those steps have to stay worth doing.
Figma frames its editing model as one part of a broader design agent. The canvas, design system, and available tools provide the context and the mechanisms for making changes; post-training improves how the model fits into that overall process. This distinction matters: the model isn't the whole agent, and model quality can't compensate for missing context or poorly designed tools.
Interpret the reported results carefully
Figma reports that between the agent's beta and general availability, typical tasks became about 20% faster. In head-to-head tests with expert designers, the newer agent beat or matched the previous production agent 62% of the time. The company also reports user ratings 33% higher and 60% fewer user undo actions.
These are company-reported results, not guarantees you can generalize to every setup. They reflect a specific product, evaluation environment, and comparison point. You should treat them as evidence that the overall agent improved, not proof that a single model change caused every gain. Figma attributes the progress across the agent to improvements that include models, tools, and the harness around them.
Figma also says it more than doubled the share of work powered by its own post-trained design model and reduced average cost per message. Those measures connect model development to day-to-day operations: lower cost can make frequent use more sustainable, and using an in-house model can give the product team more control over iteration. The trade-off is that specialized models require ongoing investment in data, evaluations, and infrastructure.
Treat privacy and user control as product requirements
Training on customer work raises questions metrics alone can't answer. Users need clarity on how their content and preferences are handled, and product teams need policies that match what actually happens in the data pipeline. Figma says it trains in a way that respects customer privacy and preferences. In other words, it's part of the trust model, not a substitute for clear communication.
Control matters during use, too. Designers should be able to inspect an edit, keep or reject it, and understand what changed. The lower undo rate Figma reports is one useful signal, but it shouldn't be the only one - you also need direct user feedback and task-level review. For professional software, AI should reduce the cost of iteration without taking away the final say.
Conclusion: train for the work, not the demo
Figma's research shows why a specialized AI model can be useful even when strong general models exist. Design editing is a structured, iterative job where context, valid file edits, visual quality, and speed all matter. SFT can provide a solid starting point, and RL plus expert-calibrated evaluation can help address imitation's limits - but it doesn't remove the need for strong tools and real testing.
The practical question isn't just "Should we build a custom model?" Ask whether the task repeats often, whether general models fail in specific and measurable ways, and whether your team can set up reliable training and evaluation loops. If those answers are yes, specialization can improve the user experience and the economics of the product. If not, a more general model - paired with better context and tools - may be the smarter investment.