How We Automated Figma-to-Unity UI Integration With AI Agents | GameDev Day 2026
In a Nutshell
Sisters built an open-source MCP server that lets AI agents convert Figma UI designs to Unity prefabs 4x faster by syncing component kits between tools, compressing prefab data to 8% of original size, and applying targeted updates that preserve scripts and manual fixes. The system works best when Figma kits use clear component naming, reusable components, and proper adaptive layouts that match Unity prefabs. The core workflow has designers maintain Figma as the source of truth while agents handle prefab building and updates through specialized skills for linking, previewing, and rebuilding.
These notes were generated by AI and may contain inaccuracies.
Olya is a user interface and experience designer with over 8 years building game interfaces. Alina is a developer at Unity with 9 years in game development. The sisters have built a tool to automate UI implementation work between design and development over the years.
UI implementation is the process of converting a Figma model into a working screen in Unity. This involves rebuilding the layout, placing each element, adjusting sizes and distances, and verifying everything works correctly. Manual implementation takes approximately 6 hours per typical game screen containing 30 or more items. The time is primarily spent on hierarchy, basic cases, linking components, and checking against the prototype.
The first version worked with Photoshop by reading binary PSD files directly and placing all layers on the canvas. When moving to Figma, the converter became cleaner because Figma provides a very readable structure and allows image export through its API. With the rise of AI agents, the idea emerged to convert the tool into an MCP server. The converter works well for standard screen construction, but manual work remains necessary for rebuilding prefab files, their variants, states, and designs with unusual structures.
The team works on mobile projects in production built with Unity UI. They chose to make the existing workflow faster rather than replace it. When giving agents the entire screen at once, the result was interesting but difficult to work with because Figma's JSON file is very large and the prefab is stored as a large YAML file. The agent spends significant time understanding the structure and often writes scripts for itself, making the process slow, expensive, and unpredictable.
Figma has its own official MCP protocol that gives agents prototype context and allows prefab creation, but lacks Unity integration. The Unity AI Assistant builds screens directly in the editor from Figma links and works with both Unity UI and UI Toolkit, but as a ready-made tool it doesn't always work as expected in large projects. Open-source tools like Unity Figma Bridge and paid converters function similarly to their existing transformer approach.
The team focused on three main areas: UI Kit Sync so the kit in Figma and Unity work as one system with all screens built from that kit; reducing manual changes so nothing needs fixing afterward; and rebuilding prefabs using agents instead of manual work. When designers change prototypes, agents implement changes while preserving company references and manual fixes.
Automation works best when the kit is organized and predictable. Components need clear names, cases must be organized consistently, and duplicate items should be reused rather than copied. The closer the Figma kit is to the Unity kit, the less the agent relies on guesswork. Even without AI, having a synchronized UI toolkit makes implementation significantly faster.
Components become "prefabs," variables become "prefab variables," automatic layouts become layout sets, and constraints become anchors. When this connection is clear, agents no longer need to guess designer intent.
Clear and consistent naming where item names clearly state what they are. Correct use of components and component variables where recurring UI elements should be reusable components rather than copies. Proper adaptive planning using automatic constraints and layouts so prototypes already show how elements should behave on different screen sizes. These rules help agents understand designer intent, use fewer tokens, and make fewer independent decisions.
A good prototype works like a good prompt where clear inputs yield more predictable results. If structure is unclear, agents may choose wrong icons, match incorrect prefabs, or rebuild components because original components were disassembled. Clear, predictable structure makes projects easier for entire teams to understand and maintain over time.
Before designers hand tasks to agents, they perform final checks on labeling and hierarchy, remove unnecessary elements, and verify automatic masks and layouts are used correctly. They also check optimization, components, component variables, assets, and adaptive behavior on different screen sizes and content. This can be done manually or using Figma agents, with the main goal being to give agents clear and reliable specifications.
Figma models are always the source of truth, with Unity models reproducing them. Unity maintains links between components and prefabs, and between images and graphic symbols (sprites). Any Figma change must be reflected in Unity. For example, updating a component in Figma requires updating the associated prefab in Unity while preserving all logic and references.
Figma components find their Unity prefabs through clear names and fixed component identifiers. Linking works by matching component IDs to specific prefab templates. The "Primary" button in Figma matches the "Primary" button in Unity. If no match exists, a skill searches for the correct prefab in the project. If nothing is found, the prefab must be built from scratch. Users can set up pairs manually or allow the skill to do so.
The foundation is a tool working with Unity UI divided into two layers. The lowest-level layer is the core - a simple Unity package that reads the Figma framework in a single tree model and runs it through a processing pipeline. The pipeline steps can be expanded and customized for specific projects. The high-level layer is the interface, using MCP instead of editor windows so agents can control the core directly through chat.
The MCP server contains tools divided into five groups: reading the prototype (loading node sequences from Figma, getting node information, exporting images); building the prefab (obtaining pipeline lists, building prefabs from node sequences); editing (changing prefabs all at once, getting compressed JSON format); origins and connections (saving sprites in Unity, linking assets to Figma component IDs, knowing what's in the project); and checking connection status.
Project setup and verification that everything is connected including code, editor, and paths. Figma and Unity linking tool that searches for prefabs and sprites, identifies what's in the project, and links to Figma components. Prefab building skill for creating tools and screens from scratch. Prefab updating skill that applies all prototype changes to current prefabs. Preview function showing differences between prototype and prefab without making changes. Download skill for getting images from Figma to the project.
The prefab building skill displays a preview and sequence of the future screen, chooses the correct path, and hands the task to MCP for building. After completion, the agent receives the prefab in JSON format containing only necessary information. The resulting prefab is examined for inaccurate points, which are corrected exactly as they would be manually.
Prefabs are stored in YAML format, which is difficult for both agents and humans to read. The raw prefab file was converted to JSON, resulting in approximately 135% larger size than the original. Compression reduced file size significantly, followed by shortening keys while maintaining clarity for agents. Some objects were stored as simple arrays, and default and empty values were eliminated. This resulted in reducing volume to approximately 8% of the original.
Seven formats were tested on the same prefab including plain JSON, TOON, and custom formats. The custom format was smallest but only slightly outperformed the enhanced JSON format. It required its own analyzer and the engine performed worse with it than with JSON. The enhanced JSON format was kept, resulting in 92% smaller size than the original model while maintaining compatibility with standard analyzers and engine performance.
Product changes constantly require UI updates for new business goals, features, or user needs. Previously, even small layout updates meant manually comparing designs to Unity screens and transferring each change individually. As products grew, these maintenance costs became ongoing.
The update prefab skill works differently from rebuilding from scratch. It compares the current model to the design and applies only the differences in structure and characteristics. When designers move elements in designs, agents are asked to rebuild tools. The model update skill detects changes and applies them, resulting in updated tools where scripts and references remain connected and all manual fixes stay in place.
Actual production screens and pop-up windows were tested for visual quality acceptability, closeness to design, component structure and reuse. Implementation cost and time were measured. Four methods were compared for building the same screen: manual work, using the converter, using a simple proxy, and the full setup combining converter, engine, proxy, MCP, and skills. Comparisons included human time, agent time, total construction time, and agent cost.
Manual execution carries risk of human error with results depending heavily on worker accuracy. The converter is more consistent but may struggle finding assets or prefabs when links are lost, and sometimes rebuilds existing components. Planning agents can give slightly different results per run, struggle with large screens, suggest manual fixes, and cause broken script references. The tool was designed to solve these problems but still has limitations requiring human intervention in some cases.
The tool works best when projects have at least basic design systems including reusable components, clear labeling, and predictable layouts. UI implementation became approximately four times faster on average across measured screens. The repository is open source and free to use.
Developer Mode in Figma is required because the free mode has limited API requests. A simple asset connects Unity UI kits to Figma via component IDs, with all Figma UI kit elements needing to be present in this schema. A skill handles this assignment because linking all elements manually is very difficult. Skills can be written to fix prototypes for implementation automation, find inconsistencies, and remove unnecessary elements.
The tool works well with older projects and was specifically created for them. New projects can use UI Toolkit without needing MCP since agents can create UI in UI Toolkit without MCP. The tool works effectively in older projects.
"Kids Light" is their own visual game project for people who have lost part of their field of vision. Oleg has experience with partial vision loss, and Alina created this game for people suffering from the same problem. The game trains reading and finding things to help with daily life activities like crossing streets where blind spots may hide people or cars.
The team works in mobile games with many elements, screens, mechanics, and user interfaces. They have not experienced responsiveness adaptability testing across different device sizes.
Figma is the source of truth. Changes made in Unity should not be reflected back in Figma. When changes occur in Figma, Unity should not be changed immediately - agents should be asked to make these changes instead.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
