Figma2Code: Automating Multimodal Design to Code in the Wild
Authors: Yi Gui
Jiawan Zhang
Yina Wang
Tianran Ma
Yao Wan
Shilin He
Dongping Chen
Zhou Zhao
Wenbin Jiang
Xuanhua Shi
Hai Jin
Philip S. Yu
Venue: ICLR 2026 Poster (2026)
Keywords: Code Generation
Design to Code
Primary area: applications to computer vision, audio, language, and other modalities

Abstract: Front-end development constitutes a substantial portion of software engineering, yet converting design mockups into production-ready *User Interface* (UI) code remains tedious and time-costly.  
While recent work has explored automating this process with *Multimodal Large Language Models* (MLLMs), existing approaches typically rely solely on design images. As a result, they must infer complex UI details from images alone, often leading to degraded results.  
In real-world development workflows, however, design mockups are usually delivered as Figma files—a widely used tool for front-end design—that embed rich multimodal information (e.g., metadata and assets) essential for generating high-quality UI.  
To bridge this gap, we introduce Figma2Code, a new task that generalizes *design-to-code* into a multimodal setting and aims to automate *design-to-code*  in the wild.  
Specifically, we collect paired design images and their corresponding metadata files from the Figma community. We then apply a series of processing operations, including rule-based filtering, human and MLLM-based annotation and screening, and metadata refinement. This process yields 3,055 samples, from which designers curate a balanced dataset of 213 high-quality cases.  
Using this dataset, we benchmark ten state-of-the-art open-source and proprietary MLLMs. Our results show that while proprietary models achieve superior visual fidelity, they remain limited in layout responsiveness and code maintainability.  
Further experiments across modalities and ablation studies corroborate this limitation, partly due to models’ tendency to directly map primitive visual attributes from Figma metadata.

Published as a conference paper at ICLR 2026
FIGMA2CODE: AUTOMATING MULTIMODAL DESIGN TO CODE IN THE WILD
Yi Gui' Jiawan Zhang': : Yina Wang', Tianran Ma', Yao Wan't, Shilin He?, Dongping Chen", Zhou Zhao', Wenbin Jiang', Xuanhua Shi', Hai Jin', Philip S. Yu Huazhong University of Science and Technology, ?Independent Researcher University of Maryland, 'Zhejiang University, University of Illinois Chicago wanyao@hust.o edu..c.co cn
ABSTRACT
Front-end development constitutes a substantial portion of software engineering, yet converting design mockups into production-ready User Interface (UI) code remains tedious and costly. While recent work has explored automating this process with Multimodal Large Language Models (MLLMs), existing approaches typically rely solely on design images. As a result, they must infer complex UI details from images alone, often leading to degraded results. In real-world development workflows, however, design mockups are usually delivered as Figma files-a widely used tool for front-end design-thar embed rich multimodal information (e.g., metadata and assets) essential for generating high-quality UI. To bridge this gap, we introduce FIGMA2CODE, new task that advances design-to-code into a multimodal setting and aims to automate design-to to-cee in the wild. Specifically, we collect paired design images and their corresponding metadata files from the Figma community. We then apply series of processing operations, including rule- based filtering, human and MI..M- --beeedd annotation and screening, and metadata refinement. This process yields 3,055 samples, from which designers curate a balanced dataset 213 high-quality cases. Using this dataset, we benchmark ten state-of-the-art open-source and proprictary MLLMs. Our results show that while proprietary models achieve superior visual fidelity, they remain limited layout responsiveness and code maintainability. Further experiments across modalities and ablation studies corroborate this limitation, partly due to models' tendency to directly map primitive visual attributes from Figma metadata."
INTRODUCTION
Front-end development is cornerstone of modern software engincering, often consuming a substan- tial share of the overall workload (Wu et al., 2024b). In practice, designers deliver design mockups, while developers translate them into UI code that reflects the intended visual appearance- workflow that remains costly and to-code, a vision with enduring academic and practical significance. With the recent emergence of powerful MLLMs,, this long-standing vision is no longer merely conceptual but is now the horizon.
This has long motivated the pursuit of fully automated design-
Inspired by earlier machine learning based approaches (Beltramelli, 2017: Robinson, 2019), a flurry of recent studies has advanced the resign-to-code task by leveraging MLLMs. Some works introduce large-scale synthetic (Laurençon et al., 2024) or real-world datasets (Gui et al., 2025a) to train or finetune MLLMs (Yun et al., 2024), enabling them to convert design images into UI code. Others contribute benchmarks that aim at systematically evaluating and pushing the boundaries of MLLMs on the design-to- so-coe task. Among them, Design2Code Si et al. (2024) presents the first real-world evaluation dataset together with dedicated metrics for assessing UI code generation, and explores different approaches to this task, such direct prompting and text-augmented prompting. In parallel,
"Equal Contribution, 'Corresponding Author
'The codehase and dataset available ? GitHub and Hugging Face.

---

Published as a conference paper at ICLR 2026
Image-only Design (Screenshot-driven)
X
Icons
Hierarchy
misang
Infer
Green Block
Styles
Layout
Generate
Figma Design (Workflow-grounded
"name": "image Seccion",
Pz
E8
Image
"chrlddrent: [C
"rills"s [E
Icons
Hierarchy
hinageRef" prgg") Tabso www.ooondddnooooooooooooo
Green Block
Contain
"y*: BC,
"henghe"": 480),
Styles
Layout
Generate
Assets
Metadata
Figure 1: Comparison of UI generation from image-only and multimodal (Figma) design.
several studies have also investigated related challenges, including UI code repair and editing (Xiao al., 2025), well code generation from complex layouts (Gui et al., 2025b).
Despite the promising performance reported in previous studies, there remains a substantial gap before MLLM-base -basedd automated design-to-code can be applied in industrial-scale development. Most previous efforts have focused on UI code generation from image-only designs, where the typical application scenario invokes replicating designs from screenshots of existing UT pages, similar to screenshoot-o-coole (Raja, 2024). As illustrated Figure 1, this approach implicitly requires inferring UI includinn icons, hierarchy, styles, and layout- from design images, which has long been a challenging problem (Wu et al., 2021). Morcover, the absence of essential assets such as background images and button icons often leads to degraded UI code. software development, design mockups are not limited to static images but also include metadata (e.g., hierarchy, layout, and styles) and assets (e.g., g., icons and background images), most prominently as Figma (Figma, Inc.) files. These files contain rich information otherwise missing in image-only designs, thereby enabling higher-quality UI code generation.
standard workflow of
To advance toward fully automated UI code generation, propose aiming to move design-to-code research beyond image-only approaches toward a more realistic and redestty setting grounded in real-world scenarios. We begin by collecting large corpus of design files from the Figma community, spanning diverse platforms and content, where each sample consists of a design image paired with its metadata files in JSON format. Each file is divided into independent pages, which are subsequently refined through heuristic filtering and manual review. We further integrate dependent resources and refine the metadata through structure pruning and abstraction. In parallel, annotators label attributes such as complexity, platform, and quality, while an MLLM is employed to categorize samples by content. Through this pipeline, obtain a base dataset of 3,055 samples. We then perform stratified sampling followed by expert review, yielding 213 high-quality and diverse samples that form the FIGMA2CODE dataset.
task, FIGMA2CODE,
Using this dataset, we systematically evaluate both open-source and proprietary MLLMs on the FIGMA2CODE task with metries covering visual fidelity and code quality in terms of layout respon- siveness and code maintainabilitt. Results show that while proprietary models achieve significantly higher visual fidelity, they still lag in code quality, leaving a substantial gap from industrial-grade UI code. We further assess UI code generation across different modalities and methods, conduct ablation studies on five key components in Figma metadata, and perform qualitative case analyses. The results indicate that Figma metadata substantially enhances visual fidelity in the task, introduces challenges for responsiveness and maintainability partly partly due to models' tendency to directly map absolute coordinates and primitive visual attributes from the metadata.
Overall, the key contributions of this work are threefold:
New Problem and Dataset. We introduce new task, FIGMA2CODE, advancing design-to-cod research beyond image-only methods toward a multimodal, industry-relevan setting. To this end, we build the FiGMA2CODE dataset, comprising 213 diverse, high-quality samples.
2

---

Published as a conference paper at ICLR 2026
Daa Data Collection
OFittering and Annotation
Metadata Refinement
wwya
Houristic Rules
Structure Pruning Abstraction
Fitaring 1.
Extreme Aspect Rade
tu
Conttent Spursiyy
Rule Baarge Placeolder Image
Communty
Crowler
lemphoo
ayers
Visual Deduplication
Iratevant attricuee
Inter Simibeity C.S5
gru Kry
Manual Curation
Asset Collection Integration
Pylane
Fiokays
Indopendent. completee
BinageRee
Update
asseds
Path
Quality
eccompnennts
accomponenttttts Bralyfou
Delinition
Desktop
I--air, 2-Dood,3 Excellon
Datasst Partition
Complexity
Content
Low, Mid, High Hard
Foutures
Red
Image
Metadata
Annotator
MLLM
Annotation
Sampling
Expert Selection
H8gh cuary
Figure 2: The pipeline of constructing the FIGMA2CODE dataset.
Comprehensive Benchmark. We are the first to establish systematic evaluation framework that assesses not only visual fidelity but also code quality for multimodal design-to-code generation, and comprchensively benchmark state-of-the-ar MLLMs the task.
Findings and Implications. Our studies indicate that current MLLMs struggle to balance visual fidelity with code quality in the metadata. These findings highlight opportunities for future research in this domain.
task, challenge arising from integrating Figma
PROBLEM FORMULATION
The FIGMA2CODE task aims to convert Figma design artifacts into executable user interface (UT) code. Unlike previous design-to-code (Si et al., 2024) settings that rely solely on visual inputs, Figma designs provide multimodal information, including a JSON metadata file describing the hierarchical structure and properties of UI elements, 2 associated design assets such as icons and images, and 3 a rendered screenshot of the full design. The objective is to generate corresponding UI code (e.g., HTML/CSS, React, Flutter) that meets three essential criteria: Visual Fidelity, faithfully reproducing the intended appearance the original design; Layout Responsiveness, enabling graceful adaptation across devices and screen sizes; and Code Maintainability. ensuring structural qualities that facilitate modularity, reuse, and long-term evolution.
Formally, the task takes input (M, A, V), where M denotes the JSON metadata, A the of design assets (e.g., icons and images), and E HR x3 the screenshot of the Figma design. The output is codebase C in specific UI language output. The objectives are threefold: 1 minimize the perceptual dissimilarity D(V, Ren,ee(drr))) 2 maximize the Layout Responsiveness Score (RS), and 3 maximize the Code Maintainability Score (MS). The joint optimization problem is:
framework, with Render(C) (C) denoting its rendered
Č arg max
- D(V. Render(C)) + 3- RS(C) + PMS(C)
where a, e, 2 0 balance the three objectives.
FIGMA2CODE: THE DATASET
3.1 DATASET CONSTRUCTION
This work aims to construct a high-quality and diverse Figma design dataset derived from real-world design practices support and advance research in automatic front-end code generation. Figure
3

---

Published as a conference paper at ICLR 2026
Complexity
Figma2 Code
Low
Mid
10.0
Hard
Information 22.1
All
Presentation
Communisation Collaboration 3.8%
Desktop 45%
Others
Density
4.2%
9.9%
Mobile 55%
4.0
Interadion Flows
E-Commerce & Transaction 19.2%
11.7%
Usar idantity
Personalization
12.7% %
Marketing Landing
OK
1.0M
Length (Tokens)
Figure 3: Dataset statistics different content, complexities and platforms.
Figure 4: Estimated token distribution over differ- ent complexities.
illustrates our meticulous data construction pipeline (details in Appendix C), which consists of four main stages: raw data collection, filtering and annotation, metadata refinement and dataset partition.
Raw Data Collection. To ensure that dataset reflects real-world design practices, sclect the Figma community as our primary data source. The Figma community is an open and widely used platform where professional designers and developers share real projects, templates, and UI components, making it a natural and reliable source for authentic design artifacts. To guarantee diversity, we perform balanced crawling across seven calegories--inludinn blogs, advertisements, and mobile applications. This process yields an initial collection of about 2, 100 design files. Since each design file typically contains multiple pages, we further decompose them into about 30,000 independent pages, and use the page as the unit of our dataset. These pages provide a rich and varied foundation for the subsequent filtering and refinement process.
Data Filtering and Annotation. The raw corpus, collected from the open Figma community, inevitably contains many irrelevant or low-quality samples, as files are contributed by diverse users and often include blank pages, non-UI oI artifacts (e.g., presentations), addition, pages derived from the same design file were often highly redundant. To distill a dataset that both high-quality and diverse, design rigorous multi-stage filtering pipeline (Details in Appendix C.2): Heuristic rule-based filtering, where we apply simple structural constraints (e.g., discarding pages with extreme aspect ratios or too few elements) automatically remove obviously unsuitable cases, drastically reducing the data volume; 2 Visual deduplication, where we generate CLIPP embeddings for each page screenshot and remove perceptually similar pages (cosine similarity > 0.95), ensuring that each retained sample contributes unique visual information; and 3 Manual filtering, where design experts review the remaining pages following clear guidelines, eliminating incomplete semantically trivial designs while retaining only coherent and meaningful UI layouts. This multi-stage pipeline effectively ensures both the quality and diversity the final dataset, providing a robust foundation for subsequent benchmarking.
overly simplistic drafts. In
Following the filtering process, design experts perform multi dimensional annotations on the qualified pages, including their platform, structural complexity, and design quality. Furthermore, enrich the data with additional semantic information for finer-grain analysis and applications, we leverage large language model to assist in annotating the content of each page, categorizing them into 12 major classes to describe their primary purpose. This human-in-the- process ultimately yields 3,055 high-quality, richly annotated design pages.
Metadata Refinement. The raw design metadata from Figma is extremely verbose, containing editor-specific properties and redundant structures that add substantial overhead and hinder effective code generation. Such artifacts not only inflate the representation, but also obscure the essential design semantics required for model learning. To transform this raw data into a clean, lightweight, and structured representation, perform two-step post-processing procedure.
4

---

Published as a conference paper at ICLR 2026
Table I: Overview of existing design-to-code benchmark datasets.
Design Format
Dimensions
Size Source
Image Meta Assets
Platform Complex Content
pix2code (Beltramelli, 2017)
1,742
Synth. Real
X
X
V
X
Design2Code (Si et al., 2024)
484
X
X
X
X
X
IW-Bench (Guo al., 2025)
1,200
Real
X
X
X
V
X
WebCode2M (Gui al., 2025a)
768
Real
X
X
X
X
MRWeb (Wan et al., 2024a)
500
Mixed
x
J
X
V
X
CC-HARD (Gui et al., 2025b)
128
Real
x
x
X
X
X
FIGMA2CODE (Ours)
213
Real
V
V
V
Structure Pruning and Abstraction. This step aims to streamline the raw Figma JSON and distill the core UI structure and attributes. Specifically, we perform series of refinement operations: removing nodes that do not contribute to the final rendering (e.g., invisible or fully occluded elements), flattening redundant container hierarchies, and filtering out metadata attributes specific to the Figma editor that are irrelevant to UI reproduction. In addition, groups of vector nodes identified as composing the same icon are merged and abstracted into a single complete icon, which we export as SVG file and reintegrate into the metadata rectangle node with local image reference. These refinements substantially reduce the sequence length of the structured representation while preserving essential semanties.
Asset Collection and Integration. UI designs frequently rely on external assets like bitmap images and vector icons. To create fully self-contained data samples, identify and localize all external dependencies. This process involves batch downloading necessary images, components, and style resources, deduplicating images with identical content, providing local relative paths for images within the data structure, and integrating components and style definitions, thereby ensuring the completeness and portability of each sample.
Dataset Partition. To support both robust evaluation and future research, we partition our base dataset which comprises 3,055 samples, into benchmark dataset and auxiliary dataset. The benchmark dataset is constructed through stratified sampling followed by expert selection (Details in Appendix C.5), ensuring its distribution across key dimensions- pllaffom, complexity, and content category mirrors that the full dataset. From this stratified pool, designers further select representative cases ensure both representativennss and quality. This process yields high-quality benchmark dataset of 213 samples, while the remaining 2,842 auxiliary samples are also released to the research community.
3.2 DATA CHARACTERISTICS
Compared with existing design-to-code benchmarks (Table 1), our dataset built from real design mockups and provides design images, metadata, and assets, all of which essential for generating faithful, high-quality UI code. We further supply annotations along three key dimensions (i.e., platform, complexity and content) support future research. Overall, the dataset has the following two key characteristies: 1 Rich diversity across multiple dimensions. As shown in Figure 3, it covers scenarios such as data visualization, presentation, e-commerce. marketing, user identity, interaction flows, and communication, while maintaining a balanced distribution across semantic categories that reflect real-world practices. In terms of complexity, spans clear hierarchy from simple cases to mid-level designs and highly complex interfaces, with token length distributions (Figure 4) highlighting these differences. High quality. All samples are collected from the Figma community and undergo heuristic filtering, visual deduplication, and expert inspection to eliminate noise and non-Ul pages, followed by metadata refinement. Each page is a self-contained sample with complete assets, styles, and components, and multiple vector instances of the same icon consolidated into single exported SVG file. This construction addresses layout and resource gaps in prior work and establishes solid foundation for generating high-quality UI. Please see more details in Appendix D.
5

---

Published as a conference paper at ICLR 2026
Table 2: Benchmarking the multimodal code generation capabilities of state-of-the-arl MLLMs from leading vendors when provided with design images and metadata as input.
Visual Fidelity
Responsiveness (%)
Maintainability (%)
Model
VES (f) MAE (4)
RUR (1)
APR (4)
STR (t)
AVU (4)
Llama 4 Maverick (MetaAI, 2025)
0.6902
0.2266
3.30
6.09
25.28
7.71
Llama Scout (MetaAI, 2025)
0.6184
0.2375
4.72
1.42
35.76
0.87
Qwen 2.5 VL (Alibaba, 2025)
0.6516
0.2120
4.40
2.66
29.54
0.15
ERNIE 4.5 424B VL (Baidu, 2025)
0.6983
0.2198
4.81
2.83
32.03
2.06
Nova Pro v1 (Amazon, 2025)
0.5993
0.2496
4.59
3.84
29.28
1.53
Gemini 2.5 Pro (Google, 2025)
0,8110
0.1936
4.43
10.51
28.98
25,46
Grok4 (xA1, 2025)
0.7997
0.1822
2.30
31.09
13.88
49.97
Claude Opus 4.1 (Anthropic, 2025)
0.7761
0.1911
1.05
9.62
19.79
23,29
GPT-4o (OpenAI, 2024)
0.7405
0.2227
3.72
2.94
25.21
2.46
GPT-5 (OpenAI, 2025)
0.8405
0.1874
1.73
14.35
15.37
37.72
4
BENCHMARKING ON FIGMA2CODE
4.1 EVALUATION METRICS
Even within the same UI technology stack (e.g., HTMLJCSS variants on the web or declarative frameworks mobile), implementations of visually identical UI can differ substantially. To accommodate this diversity, the evaluation relies on reference-free metrics, using the design image as the primary ground truth while incorporating constraints on responsiveness and maintainability.
Visual Fidelity. We evaluate the visual fidelity of the generated UI code with respect to the original design mockups along two dimensions: high-level semantic similarity and low-level pixel similarity. For semantic similarity, we compute Visual Embedding Similarity (VES) via the cosine similarity between the embeddings of the generated page screenshot I and the original design image i, expressed as cos(Ene) (os(Foode( /), Encode ()). We adopt DINOv2 (Oquab al., 2023) as image encoder instead of OpenCLIP (Cherti et al., 2023), since it is self-supervised vision foundation model that learns robust and transferable visual representations, surpassing OpenCLIP on most image- and pixel-level benchmarks. For pixel-level similarity, employ the normalized Mean Absolute Error (MAE) the generated page screenshot and the design image, which has been shown in a prior study ( (Wan al., 2024a) correlate strongly with human perceptual preferences.
Layout Responsiveness. Responsiveness is a fundamental requirement for front-end code quality, modern user interfaces expected adapt seamlessly across heterogencous devices (desktop, tablet, mobile) and varying screen resolutions. Inspired by (Parlakkılıg, 2021; Bhanarkar et al.. 2023), we primarily assess the responsiveness along two dimensions: the Relative Unit Ratio (RUR) (e.g., %, em, rem, vw/vh, fr) used in layout-related CSS properties, which captures the intrinsic scalability of the design; and A Absolute Positioning Ratio (APR), the prevalence of off-of-flow positioning (absolute/fixed) that may undermine adaptability across diverse viewports.
Code Maintainability. Maintainabilityy is another key dimension of front-end code quality. Un- like static mockups, production-reads front-end code must be extensible (Gharachorlu, 2014) and semantic (Deng et al., 2022), enabling future developers to easily understand, modify, and reuse We primarily assess maintainability along two dimensions: Semantic Tag Ratio (STR), defined as the proportion of semantic HTML elements (e.g., header, sect i on, art article) among all DOM nodes, reflecting structural clarity and accessibility; and 2 Arbitrary Value Usage (AVU), the proportion of class tokens using arbitrary value syntax (e.g., w- [123px), bg- [#fFO]), indicating deviations from standardized design tokens.
4.2 EVALUATED METHODS
We study generation approaches across three modalities: image-only. metadata-only, and multimodal (image metadata), to systematically evaluate the effect of different inputs. In the image-only setting, adopt two methods from Design2Code (Si et al., 2024), namely Direct Prompting and

---

Published as a conference paper at ICLR 2026
Table Benchmarking different approaches on the task using the ERNIE 4.5 424B VL model under different modalities
(aa Design image, </> Metadata, or both).
Visual Fidelity
Responsiveness (%)
Maintainability (%)
Method
Input
VES (1)
MAE (4)
RUR (1)
APR ())
STR (1)
AVU (4)
Direct Prompting
0.5653
0.2203
6.14
0.01
31.86
0.00
Text-Augmented
0.5683
0.2145
7.02
0.01
29.67
0.00
Direct Prompting
0.6801
0.2101
4.97
5.01
21.46
6.09
Template Conversion
</>
0.6219
0.1205
0.00
58.0
0.01
24.94
Direct Prompting
0.6923
0.2228
4.81
2.83
32.03
2.06
F2CAGENT
</>
0.7990
0.1923
4.69
13.57
28.57
16.71
Text-Augmented. In the metadata-only setting, evaluate the FigmaToCode (Ferrari, 2025) plugin (termed Template Conversion) and implement a vanilla approach that instructs MLLMs to convert ISON metadata into responsive and maintainable UI code. In the multimodal setting, we further design a vanilla approach that integrates both images and metadata. For clarity, we denote all vanilla prompting approaches collectively as Direct Prompting (Details in Appendix F).
Building on ReAct (Yao et al., 2022), we develop preliminary agentic workflow for the FIGMA2CODE task, termed F2CAGENT (detailed in Appendix F.2). Inspired by Ferrari (2025), F2CAGENT first converts raw Figma JSON into Intermediate Representation (IR) by restructuring the node hierarchy, preserving design attributes, and inlining component and style dependencies. The IR is then translated into UI code via rule-based templates. Implemented without the Figma sandbox (Figma, Inc.), this step often introduces visual and structural flaws. To address these issues, we adopt ReAct-style refinement loop, where critic detects deficiencies and refiner iteratively improves visual fidelity and code quality.
4.3 MULTIMODAL CODE GENERATION CAPABILITIES OF MLLMS
To comprehensively evaluate the multimodal code generation capabilities of MLLMs on the FIGMA2CODE task, we adopt ten flagship models from leading vendors, covering both open-source and proprietary solutions. Each model is provided with the design image and corresponding Figma metadata in JSON format and is instructed to generate UI code that reconstructs the target design while explicitly ensuring layout responsiveness and code maintainability.
Under our benchmark and unified protocol, current MLLMs still struggle to balance visual fidelity with code quality in the FIGMA2CODE task. shown in Table 2, GPT-5 and Gemini 2.5 Pro achieve the highest visual fidelity, with VES scores of 0.8405 and 0.8110 and corresponding MAE values of 1874 and 1936. Claude Opus 4. and Grok4 also perform competitively this dimension. By contrast, open-source models such as Llama 4 Scout, which records VES of only 0.6184 and an MAE of 0.2375. fall far behind, highlighting the advantage of proprietary models in multimodal alignment for reconstructing design appearance. The pattern, however, reverses when considering layout responsiveness and code maintainability. Llama 4 Scout generates the cleanest and most responsive code, with APR of 1.42% and STR of 35.76%. Grok4, despite its strong MAE of 0. 122, suffers from extremely poor responsiveness and maintainability. with APR rising to 3..09% and AVU reaching 49.9 49.97%. Even GPT-5, the strongest in visual fidelity, shows a high AVU 37.72%, reflecting a frequent reliance on absolute positioning and non-standard style tokens.
4.4 CODE GENERATION PERFORMANCE ACROSS MODALITIES
To examine the impact of different modalities on the FIGMA2CODE task, we derive three input variants from the FIGMA2CODE dataset: image only, metadata only, and image metadata. For each variant, we evaluate two corresponding methods using ERNIE 4.5 424B VL as the backbone model.
While Figma metadata greatly improves visual fidelity, it also introduces rigidity that under- mines responsiveness and maintainability. As shown in Table 3, metadata-only methods achieve higher fidelity than image-only ones ones-for for example, Direct Prompting reaches VES of 0.6801 compared with 0.5653 for its image-only counterpart- while multimodal inputs perform best, with F2CAGENT attaining VES of 0.7990, the highest across all methods. By contrast, image-only
7

---

Published as a conference paper at ICLR 2026
Metacata only
Baseline
wr Style
wio Hierarchy
Metacata Image
Geometry
w/b Image Assets
web Text
0.7
0.05
0.5
9.20
0.05
0.04
0.10
0.23
0.0
0.00
0.00
VES1 (Viuual Embedding Similarity. rity)
MAEL (Mean Absolute Error)
RURT (Relative Unit Ratio)
0.35
0.96
3.05
0.30
0.25
3.03
0.20
0.02
0.10
0.03
3.00
0.00
0.00
APR4 (Absolute Positioning Ratio)
STR (Semantic Ratio)
AVU (Arbitrary Value Usage)
Figure 5: Ablation study on five metadata components. Using the ERNIE 4.5 424B VI. model, we conduct Figma-to-code generation under both metadata-only and mmma settings, where each metadata component component-gcomettyy style, image assets, hierarchy, and text-is removed in turn.
methods produce the most responsive and maintainable code, with APR and AVU values near zero, whereas metadata-based approaches often yield rigid layouts and arbitrary style tokens, as seen in APR 5.01% for metadata prompting and 13.57% for F2CAGENT. Template Conversion shows the most extreme case: despite a competitive MAE O. 0.12 its responsiveness and maintainability collapse, with RUR falling to 0%, STR to 0.01%, and APR soaring to 58.0%. Overall, F2CAGENT achieves the strongest visual fidelity while partially alleviating structural issues compared to metadata-only prompting (please see case studies in Appendix J).
4.5 How DOES METADATA INFLUENCE GENERATION PERFORMANCE?
To disentangle the effects of Figma metadata in the FIGMA2CODE task, we perform an ablation study on five key components: textual content, style attributes, hierarchical structure, image assets, and geometric information (details in Appendix G). Using ERNIE 4.5 424B VL as the backbone model, we conduct the ablation studies under both metadata-only and image metadata conditions.
Multimodal input mitigates degradation caused by ablations, highlighting the complementary strengths of visual and metadata signals. As shown Figure 5, drops in VES or rises APR are less pronounced connounced-indicatiing that visual and metadata signals work together to stabilize generation quality. Style and image assets are most critical for visual fidelity: removing style lowers VES from approximately 0.65 to below 0.55 and raises MAE above 0.25, while ablating image assets produces a similar decline, underscoring their importance for faithfully reconstructing visual appearance. By contrast, responsiveness is most sensitive to geometry and hierarchy: removing either halves RUR and raises APR, showing that these cues are essential for flexible, adaptive layouts. Interestingly, ablating style or geometry slightly improves maintainability, reflected by higher STR and lower AVU, suggesting that current MLLMS struggle to fully exploit these signals and instead fall back on arbitrary tokens or con-semantic structures.
4.6 QUALITATIVE ANALYSIS
We present representative UI code snippet generated by Grok4 alongside manually created golden case, as illustrated in Figure 6. The Grok4 output relies heavily on absolute positioning, which hinders seamless adaptation across devices of different resolutions. It also overuses arbitrary style tokens and non-semantic < d' v> elements, introduces unnecessary hierarchy, and thus produces code that is difficult to reuse and evolve. In contrast, the manually crafted golden uses readable semantic
8

---

Published as a conference paper at ICLR 2026
1
class"absolurs" Left- [5pp]
[335px]
h- 44px
header lasos""absolute Left-5 top-
211
class= class= (absolute left-B top-0 w- [44px]
h- 44px
w- [335px]
1-11 Flex itons-center"
<d1v "aass="bbsour Left-8 top-8
[4dpx]
[4px
rounded-
button
class
itens-
full backdrop-blur- [38px] bg- [#f7f7fb] "></div>
justify-canter w-11] rounded-full
<ing /aarr...rwwwwggg class- class="absoluute (absolute
Left- [5px
bg. (E-[AAF677b) backdrop-bles (300
top- 25px w-[5.5px] h-[11.5px]" alt="Back">
<ing sree". prcca.//arrw.stt alce"Back"
</div>
(Sssg=" h- h=[]1'5px]'' </buttan></headee
</div>
Figure 6: HTML snippet generated by Grok4 (left) and the golden implementation (right). The former overuses absolute positioning, arbitrary style tokens, and non-semantic < <di fiv,, while the latter uses semantic tags and flex layout, improving responsiveness and maintainability.
tags, Tailwind predefined classes, and flexible layouts, resulting in higher responsiveness and main- tainability. This example underscores the limitations of proprictary MLLMs in the FIGMA2CODE task and demonstrates that automated design-to-code with MLLMs still faces significant challenges. We also present some generation cases in Appendix J.
5 RELATED WORK
Multimodal Code Generation. Recent MLLMs such GPT-4o (Hurst et al., 2024), Gemini (Reid et al., 2024), Claude (Anthropic), MiniGPT-4 (Zhu ct al., 2023). LLaVA (Liu et al., 2023). DeepSeck- VL (Lu et al., 2024), Qwen2.5-VI. "ALLAllia (Alibaba, 2025), and Int (Zhu et al., 2025) demonstrate strong multimodal grounding but still struggle on cemain-speciffr code generation. To address this, specialized benchmarks and systems have emerged: ChartMimic (Shi al., 2024), Plot2Code (Wu et al., 2024a). and ChartCoder (Zhao et al., 2025) target chart-to-code tasks; HumanEval-V (Zhang all, 2024) and Vision (Xu & Sheng, 2025) test coding with diagrams: code generation has also been explored as visual reasoning in VQA (Shen et al., 2024; Sur's is et al., 2023). Datasets such as MMCode (Li al., 2024) and VisCodex (Jiang et al., 2025) reveal the limitations of current LMMs and propose vision-language code integration. Overall, MLLMs present significant opportunities and potential for advancing multimodal code generation.
Design to Code. Early design-to-code systems explored deep learning on simple cases (Beltramelli, 2017; Chen et al., 2018). Recent work emphasizes layout reasoning and iterative refinement: layout- as-thought (Gui et al., 2025b) decomposes designs into sequential blocks; feedback-drive systems (DeclarUI (Zhou et al., 2025), WAFFLE (Liang et al., 2024), UICoder (Wu et al., 2024b)) refine outputs through compiler or training signals; and hierarchical pipelines (DCGen (Wan et al., 2024b), LaTCoder (Gui et al., 2025b)) improve composability by dividing complex UIs. Extensions include coarse-to- torrsc-to-fineeeee strategies (UICopilot (Gui et al., 2025c)) and structural fidelity via hierarchy-awarn grouping (DesignCoder (Chen et al., 2025)). These advances are supported by large-scale bench- marks warks-WebUl (Wu et al., 2023), 2Csi (Si et al., 2024), Web2Code (Yun et al., 2024), IW-Bench (Guo et al., 2025), and WebCode2M (Gui et al., 2025a) which standardize evaluation on both code correctness and layout fidelity. However, most existing approaches remain limited to omage-only UI generation and rarely incorporate industry-grounded design drafts (e.g.. Figma), resulting in considerable gap from practical industrial applications.
6 DISCUSSION AND CONCLUSION
Although our work represents an important step in advaneing design-to-code research beyond image- only methods, it remains an initial exploration that defines the scope of this line of study rather than a definitive solution. To establish principled foundation and ensure tractability, reproducibility, and comparability across models, we adopt several pragmatic design choices. For instance, we standardize the generation target to Tailwind -Sd-widely adopted in practice and modular in trrctture-whihh serves as a practical baseline without loss of generality. Likewise, we introduce streamlined evaluation criteria that, while simple, capture multiple dimensions of code quality and motivate future exten- sions toward richer evaluation signals. Our proposed agentic workflow, F2CAGENT, demonstrates promising gains in visual fidelity for a weaker open-source model (ERNIE 4.5 424B VL), while also highlighting opportunities to strengthen responsiveness and maintainability. Yet, the broader

---

Published as a conference paper at ICLR 2026
challenge of reconciling visual fidelity with robust engineering quality continues to define the frontier of multimodal design-to-con research.
In conclusion, we formally introduce the FIGMA2CODE task and present the first dataset constructed from real-world Figma design files integrating images, metadata, and assets. Through systematic evaluation of state-of- -ot--o----trrrrr- art MLLMs, show that these models still struggle balance visual fi- delity with engineering practicality in Figma-to-code generation: while Figma metadata substantially enhances visual fidelity, simultaneously introduces challenges for responsiveness and maintainabil- ity. We believe this work represents significant step toward practical and scalable design-to-code automation. For future work, we aim to explore reinforcement learning based agents and more reliable agentic workflows to address these limitations, as well as diffusion models to improve the efficiency of UI code generation.
ACKNOWLEDGEMENTS
This work is supported by the Major Program (JD) of Hubei Province under Grant No.3023BAADD and the National Natural Science Foundation of China under Grant No.U24A20326. This work also partially sponsored by CCF-Huawei Populus Grove Fund (No. HuaveiSE22025027)
ETHICS STATEMENT
Our dataset is sourced from the public Figma community. To mitigate ethical risks, such as the inclusion of private inappropriate content, we conducted a rigorous manual filtering process in which design experts reviewed every sample (see Section 3.1 and Appendix C.2). This ensures that the final dataset is appropriate for research and fully complies with the platform's terms of service. Details regarding licensing and redistribution compliance are provided in Appendix B.
REPRODUCIBILITY STATEMENT
To ensure reproducibility, we detail our dataset construction in Section 3.1 and Appendix C, and our evaluation framework in Section 4.1 and Appendix E. Additional implementation details are provided in Appendix D. We will release the FIGMA2CODE dataset along with our codebase and experimental scripts to enable full verification of results and facilitate future research. To further strengthen reproducibility, we set the temperature parameter of all MLLM invocations to 0 and fix random seeds for Python's ' random, torch, and numpy packages. Detailed inference protocols for invoking MILMS are presented Appendix F.3.
REFERENCES
Alibaba. Qwen2.5-vl technical report. ArXiv, abs/2502.13923. 2025.
Amazon. The amazon nova family of models: Technical report and model card, ArXiv, abs/2506.12100 2025.
Anthropic. The claude 3 model family: Opus, sonnet, haiku.
Anthropic. Claude opus 4.1, 2025. URL https::/ww.atttroppt. com www.///ww//ww...o.cco.o.o...eeee htt.:///....ccoee//////ueeeeeeee claude- pus-4- 1aa-----aaueeesssaanoouu
Baidu. Ernie 4.5 technical report, 2025.
Tony Beltramelli, pix2code: Generating code from a graphical user interface screenshot. Proceedings of the ACM SIGCHI Symposium on Engineering Interactive Computing Systems, 2017.
Noorkaran Bhanarkar, Aditi Paul, and Dr. Ashima Mehta. Responsive web design and its impact on user experience. International Journal of Advanced Research in Science, Communication and Technology, 2023.
10

---

Published as a conference paper at ICLR 2026
Chunyang Chen, Ting Su, Guozhu Meng, Zhenchang Xing, and Yang Liu. From ui design image to gui skeleton: A neural machine translator to bootstrap mobile gui implementation. 2018 JEEE/ACM 40th International Conference on Software Engineering (ICSE), pp. 665-676, 2018.
Yunnong Chen, Shixian Ding, Ying Ying Zhang, Wenkai Chen, Jinzhou Du, Lingyun Sun, and Liuqing Chen. Designcoder: Hierarchy-aware and self-correcting ui code generation with large language models. ArXiv, 0oos/2506.16665 2025.
Mchdi Cherti, Romain Beaumont, Ross Wightman, Mitchell Wortsman, Gabriel Ilharco, Cade Gordon, Christoph Schuhmann, Ludwig Schmidt, and Jenia Jitsev. Reproducible scaling laws for contrastive language-iman image learning. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, pp. 2818 2818-2829, 2023.
Xiang Deng, Prashant Shiralkar, Colin Lockard, Binxuan Huang, and Huan Sun. Dom-Im: Learning generalizable representations for html documents. ArXiv, abs/2201.10608, 2022.
Bernardo Ferrari. Figmatocode. https: //g thub. wwt.///rnaaererrrr//aa..../ www.reerrrrrrr//gggaaaaaama 2025. Accessed: 2025-09-11.
Figma, Inc. Figma: The collaborative interface design tool. https://wwe figma com/. Accessed: 2025-09-17.
Golnaz Gharachorlu. Code smells in cascading style sheets an empirical study and a predictive model. 2014.
Google. Gemini 2.5: Pushing the frontier with advanced reasoning, multimodality, long context, and next generation agentic capabilities. ArXiv, 2025.
Yi Gui, Zhen Li, Yao Wan, Yemin Shi, Hongyu Zhang, Yi Su, Bohua Chen, Dongping Chen, Siyuan Wu, Xing Zhou, Wenbin Jiang, Hai Jin, and Xiangliang Zhang. Webcode2m: A real-world dataset for code generation from webpage designs. Proceedings of the ACM on Web Conference 2025, 2025a.
Yi Gui, Zhen Li. Zhongyi Zhang. Guohao Wang. Tianpeng Lv, Gaoyang Jiang, Yi Liu, Dongping Chen, Yao Wan, Hongyu Zhang, Wenbin Jiang, Xuanhua Shi, and Hai Jin. Latcoder: Converting wehpage design to code with layout-as-thought, Proceedings of the 3/st ACM SIGKDD Conference on Knowledge Discovery and Data Mining V.2, 2025b.
Yi Gui, Yao Wan, Zhen Li, Zhongyi Zhang, Dongping Chen, Hongyu Zhang, Yi Su, Bohua Chen, Xing Zhou, Wenbin Jiang, and Xiangliang Zhang. Uicopilot: Automating ui synthesis via hicrarchical code generation from webpage designs. Proceedings of the ACM Web Conference 2025, 2025c.
Hongcheng Guo, Wei Zhang, Junhao Chen, Yaonan Gu, Jian Yang, Junjia Du, Shaoshen Cao, Binyuan Hui, Tianyu Liu, Jianxin Ma, Chang Zhou, and Zhoujun Li. Iw-bench: Evaluating large multimodal models for converting image-to-web. In Annual Meeting of the Association for Computational Linguistics, 2025.
OpenAl Aaron Hurst, Adam Lerer, Adam P. Goucher, Adam Perelman, Aditya Ramesh, Aidan Clark, AJ Ostrow, Akila Welihinda, Alan Hayes, and et al. Gpt-4o system card. ArXiv, abs/2410.21276. 2024.
Lingjie Jiang, Shaohan Huang, Xun Wu, Yixia Li, Dongdong Zhang, and Furu Wei. Viscodex: Unified multimodal code generation via merging vision and coding models. 2025.
Hugo Laurençon, Léo Tronchon, and Vietor Sanh. Unlocking the conversion of web screenshots into html code with the websight dataset. ArXiv, abs/2403.09029, 2024.
Kaixin Li, Yuchen Tian, Qisheng Hu, Ziyang Luo, and Jing Ma. Mmcode: Benchmarking multimodal large language models for code generation with visually rich programming problems. In Conference on Empirical Methods in Natural Language Processing, 2024.
Shanchao Liang, Nan Jiang, Shangshu Qian, and Lin Tan. Waffle: Fine-tuning multi-modal model for automated front-end development. In Anmual Meeting of the Association for Computational Linguistics, 2024.
11

---

Published as a conference paper at ICLR 2026
Haotian Liu, Chunyuan Li, Qingyang Wu, and Yong Jae Lee. Visual instruction tuning. ArXiv, abs/2304.08485, 2023.
Haoyu Lu, Wen Liu, Bo Zhang, Bing-Li Wang, Kai Dong, Bo Liu (Benjamin Liu), Jingxiang Sun, Tongzheng Ren, Zhuoshu Li, Hao Yang, Yaofeng Sun, Chengqi Deng, Hanwei Xu, Zhenda Xie, and Chong Ruan. Deepseek-vl: Towards real-world vision-language understanding. ArXiv, abs/2403.05525, 2024.
MetaAl, Llama 4: Advancing multimodal intelligence. https:/ /aii meta. wtt.ccoooolbbccccccccc ma 4- mnoltimodal- - 2025,, Accessed: 2025-09-13.
OpenAl. Gpt-4o system card, 2024. URL https: abs http//aab//22//// //1/222112222222 2024.10.25.
OpenAl. Gpt-5, 2025.
Maxime Oquab, Timothée Dareet, Théo Moutakanni, Huy Q. Vo, Mare Szafraniec, Vasil Khalidov, Pierre Fernandez, Daniel Haziza, Francisco Massa, Alaacldin El-Nouby, Mahmoud Assran, Nicolas Ballas, Wojciech Galuba, Russ Howes, Po-Yao (Bernie) Huang, Shang-War Li, Ishan Misra, Michael G. Rabbat, Vasu Sharma, Gabriel Synnaeve, Huijiao Xu, Hervé Jégou, Julien Mairal, Patrick Labatut, Armand Joulin, and Piotr Bojanowski. Dinov2: Learning robust visual features without supervision. ArXiv, abs/2304.07 193, 2023.
Alaattin Parlakkılıg. Evaluating the effects of responsive design on the usability of academic websites in the pandemic. Education and Information Technologies. 27:1307 1322, 2021.
Abi Raja. The serreenshot-to-cooo project on the github, 2024. URL com/ www.abii////coocccccoc.ooo/...aa /oro:/ssreessott-- to- codeee//
Machel Reid, Nikolay Savinov, Denis Teplyashin, Dmitry Lepikhin, Timothy Lillicrap, Jean- Baptiste Alayrac, Radu Soricut, and et al. Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context. ArXiv, hass/2403.05530 2024.
Alex Robinson. Sketch2code: Generating website from a paper mockup. ArXiv, 2019.
Ruoyue Shen, Nakamasa Inoue, and Koichi Shinoda. Pyramid coder: Hierarchical code generator for compositional visual question answering. International Conference on Information Photonics, 2024.
Chufan Shi, Cheng Yang, Yaxin Liu, Bo Shui, Junjie Wang, Mohan Jing, Linran Xu, Xinyu Zhu, Si- heng Li, Yuxiang Zhang, Gongye Liu, Xiaomei Nie, Deng Cai, and Yujiu Yang. Chartmimic: Evalu- ating Imm's 's cross cross-modal reasoning capability via chart-to-code generation. ArXiv, abs/2406.09961, 2024.
Chenglei Si, Yanzhe Zhang, Ryan Li, Zhengyuan Yang, Ruibo Liu, and Diyi Yang. Design2code: Benchmarking multimodal code generation for automated front-end engineering. In North Ameri- can Chapter of the Association for Computational Linguistics, 2024.
D'idac Sur is, Sachit Menon, and Carl Vondrick. Vipergpt: Visual inference via python execution for reasoning. 2023 IEEE/CVF International Conference on Computer Vision (ICCV), pp. 11854- 11864, 2023.
Yuxuan Wan, Yi Dong, Jingyu Xiao, Yintong Huo, Wenxuan Wang, and Michael R. Lyu. Mr- web: An exploration of generating multi-page resource-aware web code from designs. ArXiv, 1531/442,113100, 2024a.
Yuxuan Wan, Chaozheng Wang, Yi Dong, Wenxuan Wang, Shuqing Li, Yintong Huo, and Michael R. Lyu, Automatically generating ui code from screenshot: A souudd-and-conuur-bbsseee approach. ArXiv, abs/2406.16336 16386, 2024b.
Chengyue Wu, Yixiao Ge, Qiushan Guo, Jiahao Wang. Zhixuan Liang, Zeyu Lu, Ying Shan, and Ping Luo. Plot2code: comprehensive benchmark for evaluating multi-modis large language models in code generation from scientific plots. ArXiv, 0e0p24405079990 2024a.
12

---

Published as a conference paper at ICLR 2026
Jason Wu, Xiaoyi Zhang, Jeffrey Nichols, and Jeffrey P. Bigham. Screen parsing: Towards reverse engineering of ui models from screenshots. The 34th Annual ACM Symposium on User Interface Software and Technology, 2021.
Jason Wu, Siyan Wang, Siman Shen, Yi-Hao Peng, Jeffrey Nichols, and Jeffrey Bigham. Webui: A dataset for enhancing visual ui understanding with web semantics. Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems, 2023.
Jason Wu, Eldon Schoop, Alan Leung, Titus Barik, Jeffrey P. Bigham, and Jeffrey Nichols. Uicoder: Finetuning large language models to generate user interface code through automated feedback. In North American Chapter of the Association for Computational Linguistics, 2024b.
XAL. Grok 4. News release, July 9 2025. URL httpst/ //x aww///////w////.../ grok-4.
Jingyu Xiao, Ming Wang, Man Ho Lam, Yuxuan Wan, Junliang Liu, Yintong Huo, and Michael R. Lyu. Designbench: A comprehensive benchmark for mllm-bases front-end code generation. ArXiv, abs/2506.06251, 2025.
Zhenyu Xu and Victor S. Sheng. Codevision: Detecting llm-generated code using 2d token probability maps and vision models. ArXiv, 0als/2001.32260 2025.
Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. React: Synergizing reasoning and acting in language models. ArXiv, abs/2210.03629, 2022.
Sukmin Yun, Haokun Lin, Rusiru Thushara, Mohammad Qazim Bhat, Yongxin Wang, Zutao Jiang, Mingkai Deng, Jinhong Wang. Tianhua Tao, Junbo Li, Haoman Li, Preslav Nakov, Timothy Baldwin, Zhengzhong Liu, Eric P. Xing, Xiaodan Liang, and Zhiqiang Shen. Web2code: A large-scale scale webpage-to-code dataset and evaluation framework for multimodal 1lms. ArXiv, abs/2406.20098, 2024.
Fengji Zhang, Linquan Wu, Huiyu Bai, Guancheng Lin, Xiao Li, Xiao Yu, Yue Wang, Bei Chen, and Jacky Wai Keung. Humaneval-v: Evaluating visual understanding and reasoning abilities of large multimodal models through coding tasks. ArXiv, 0etp22410.2288... 2024.
Xuanle Zhao, Xianzhen Luo, Qi Shi, Chi Chen, Shuo Wang, Wanxiang Che, Zhiyuan Liu, and Maosong Sun. Chartcoder: Advancing multimodal large language model for chart-to-code genera- tion. ArXiv, htbb//501.06598.. 2025.
Ti Zhou, Yanjie Zhao, Xinyi Hou, Xiaoyu Sun, Kai Chen, and Haoyu Wang. Declarui: Bridging design and development with automated declarative code generation. Proc. ACM Softw. Eng., 219-241 2025.
Deyao Zhu, Jun Chen, Xiaoqian Shen, Xiang Li, and Mohamed Elhoseiny. Minigpt-4: Enhaneing vision-language understanding with advanced large language models. ArXiv, abs/2304. 10592, 2023.
Jinguo Zhu, Weiyun Wang, Zhe Chen, Zhaoyang Liu, Shenglong Ye, Lixin Gu, Yuchen Duan, Hao Tian, Weijie Su, Jie Shao, Zhangwei Gao, Erfei Cui, Yue Cao, Yangzhou Liu, Haomin Wang, Weiye Xu, Hao Li, Jiahao Wang, Han Lv, Dengnian Chen, Songze Li, Yinan He, Tan Jiang, Jiapeng Luo, Yi Wang, Cong He, Botian Shi, Xingcheng Zhang, Wenqi Shao, Junjun He, Ying Xiong, Wenwen Qu, Peng Sun, Penglong Jiao, Lijun Wu, Kai Zhang, Hui Deng, Jiaye Ge, Kaiming Chen, Limin Wang. Min Dou, Lewei Lu, Xizhou Zhu, Tong Lu, Dahua Lin, Yu Qiao, Jifeng Dai, and Wenhai Wang. Internv13: Exploring advanced training and test- oest-time recipes for open- source multimodal models. ArXiv, 200225004410499 2025.
13

---

Published as a conference paper at ICLR 2026
Part I
Appendix
Table of Contents
Usage of Large Language Models
15
B Licensing and Redistribution Compliance
15
Details of Dataset Construction
Data Acquisition Pipeline
C.2 Multi-Stage Curation Protocol
C33 Semantic Annotation and Enrichment
17
C.4 Data Transformation and Structuring
19
C.5 Datasct Partitioning Strategy
20
D Dataset Analysis
20
E
Implementation Evaluation Metries
21
E.1 Visual Fidelity
21
E.2 Layout Responsiveness.
21
B.3
Code Maintainability
23
F
Implementation of Benchmarking Methods
24
F.I
Direct Prompting
24
F2 F2CAGENT
................................
26
F3
Unified Inference Protocols for MLLMs
................................
28
G
Ablation Study Figma Metadata Components
29
G.1 Objective and Rationale
29
G.2 Experimental Design
30
G.3
Implementation Methodology
30
MAE.px versus MOS
31
More Experimental Results
31
Case Study
32
14

---

Published as a conference paper at ICLR 2026
A USAGE OF LARGE LANGUAGE MODELS
In compliance with the ICLR 2026 policies on the use Large Language Models (LLMs), we hereby disclose the usage of such models in the preparation of this manuscript. Our use of LLMs can be categorized into three main areas: data annotation as part of our research methodology, assistance with code implementation, and writing assistance for the manuscript.
LLM in Paper Writing. We utilize LLMs to aid in the writing process, primarily for improving grammar, enhancing clarity, and refining the phrasing of the manuscript. The goal is to improve the overall readability and quality of the text.
LLM in Data Annotation. As detailed in Section 3.1 and Appendix C.3, an LLM (GPT-4o 4o mini) employed as a tool to assist in the semantic annotation of our dataset. The model's role is to categorize UI design pages into predefined content classes and generate concise descriptions. This process is conducted under a human-in-the-looy framework, where the LLM-generated annotations part of broader supervised data curation pipeline. The prompts and methodology are explicitly documented to ensure transparency.
LLM in Code Implementation. LLMs are utilized assist in the development and debugging of scripts for our experimental framework. This includes generating code snippets for data processing, implementing evaluation metrics, and refining algorithms. All L. I.LM-assisted code is carefully reviewed, tested, and verified by the authors to ensure its correctness and efficiency.
Author Responsibility. In accordance with the ICLR policy, the authors have meticulously reviewed, revised, and validated all content produced with the assistance of L.Mss. We assume full responsibility for all statements, claims, and any potential inaccuracies within this submission. The final content of this paper, including all the code and text, reflects the authors' own work and conclusions.
B LICENSING AND REDISTRIBUTION COMPLIANCE
All design files in our dataset are sourced from the Figma community, which allows users to publicly share design artifacts. In accordance with Figma's licensing framework,' free community files are distributed under the Creative Commons Attribution 4.0 (CC BY 4.0) license, which permits sharing and adaptation (including for commercial use) provided that appropriate credit is given. Paid resources, in contrast, are governed by the Community Paid Resource License and cannot be redistributed in their original form. To ensure compliance, we conduct a systematic review of the license and content before redistribution.
License Inspection. For each Figma file, record its source URL,, author information, and license type (free CC BY or paid). When explicit license information was missing, ambiguous, or marked as paid, we exclude the corresponding raw assets from redistribution.
Attribution. For files under CC BY 4.0, we provide author credit in our dataset metadata and release notes, satisfying the attribution requirement.
Asset Handling. For design assets such as images and icons, we localize them into our dataset package only when redistribution was explicitly permitted. Otherwise, retain only rendered screenshots and structural annotations, while pointing users to the original Figma source.
Content Filtering. We manually filter out files containing sensitive, offensive, or copyrighted third-party material to avoid inappropriate redistribution.
Usage Restriction. We release the dataset strictly for non-commercial research purposes. Any commercial use of the design files or assets remains subject to the original Figma license terms and, where applicable, the Paid Resource License.
Through these steps, we ensure that all redistributed components of FIGMA2CODE comply with licensing requirements. Ambiguous or paid cases are handled conservatively by limiting distribution
Phttps://he1p fi Figma. ottp:///aaaaa//tttttoeeeee/////2 htt.:///aaaaaeeeeeeeeeeaeeaaeeae Fi imm- Commun
-copyright-and- incnnnn
15

---

Published as a conference paper at ICLR 2026
to derived representations only (e.g., screenshots and metadata), while free CC BY resources redistributed with proper attribution.
C DETAILS OF DATASET CONSTRUCTION
This section provides comprehensive account of the methodologies and protocols implemented each stage of the FIGMA2CODE dataset's construction.
C.I DATA ACQUISITION PIPELINE
This subsection details the technical approach for collecting the initial corpus of raw design files from the Figma community.
Automated Crawler Implementation. To ground our dataset in authentic, real-world design prac- tices, we choose the Figma community as our primary data source. We implement an automated data collection script using Python with the Selenium WebDriver framework. This script programmatically controls web browser navigate the website's s dynamic-loading content, systematically crawling publicly available design files. The collection process involves
the unique identifiers (filekeys) two main stages. First, the script accesses predefined list of Figma community category pages, parsing up to 300 design template links from each. Second, after deduplicating this aggregated list of links, the script iterates through each unique URL,, simulating user click on the "Open in Figma" button. In the URL of the newly opened browser tab, the f fileKey is then precisely extracted using the regular expression (file design) /)
Metadata and Image Retrieval via Figma API. Using the collected filekeys, leverage the official Figma API to retrieve the complete metadata for each design file in structured JSON format. Within this hierarchical data, we identify the target design pages by selecting nodes of type FRAME that are direct children of a CANVAS node. The unique IDs of these F FRAME nodes are then collected. In the final step, these IDs are used make subsequent API calls to download the high-resolution rendered image of each respective page, thereby assembling our initial raw dataset.
Target Source Specification. We target free "files" resources across diverse range of application scenarios ensure design diversity. The specific Figma community URLs include:
/
f wttp://acccooooommoooococca
https:// f
https:// :/wp::///www. for.figgman http:://ww...E.a.ccccccoooottttt
https://wwws f wtt.ccooccccom
C.2 MULTI-STAGE CURATION PROTOCOL.
This subsection outlines the rigorous filtering and selection process designed distill high high-tuality samples from the raw data corpus, which contained significant number of irrelevant or low-quality samples.
Heuristic Pre-filtering Rules. To efficiently process the massive raw data, we first discard pages that are obviously unsuitable according to four heuristic rules: 1 Size Validity-pages with bounding- box width or height < 0: 2 Extreme Aspect Ratio the ratio of the longest to shortest side exceeds 5:1, typical of standaadd UI designs such as flowcharts banners: 3 Content Spar- fewer than three direct child nodes, indicating a hear-blank canvas; 4 Dominant Placeholder Image-any single image node occupies > 80% of the total page area.
16

---

Published as a conference paper at ICLR 2026
CLIP-based Visual Deduplication. To further improve visual diversity, we leverage the pre- mreitrained CLIP model (ViT-B/32) to detect and eliminate perceptually near-duplicate pages in two stages: Intra-Filekey Deduplication clusters pages within each Figma file whose cosine similarity exceeds 0.95, retaining only the page with the largest image file size as a fidelity proxy; 2 Inter-Filekey Deduplication pools the survivors and repeats the clustering across the entire corpus, removing residual duplicates that span multiple files. This dual-stage strategy balances coverage and uniqueness while remaining computationally tractable.
Manual Screening Criteria. The final filtering stage involve manual review by design experts to ensure semantic quality and relevance. The primary objective is to remove non-conforming pages while retaining only those representing complete, self-contained UI designs. Pages are discarded they meet any of the following criteria: Incomplete Missing Content-designy containing only single icon, image, or otherwise truncated layout; 2 Non-UI Artifacts Artifacts- design-systenn documentation. Figma covers, or presentation slides; 3 Overly Simple Layouts-splash screens or basic forms lacking sufficient structure; 4 Abnormal Composition- whitespace or chaotic arrangement; Highly Similar Variants Variants-neart near-duplicates differing only in theme, color, minor details; and 6 Sensitive Inappropriate Content- privttte information, violence, or any other unethical material. This manual sweep ensures that only coherent, self- contained, and ethically sound UI designs enter the final benchmark.
areas of meaningless
C.3 SEMANTIC ANNOTATION AND ENRICHMENT
Prompt for Using GPT-4o Additional Annotation
You prufessional image analyst. Analyze provided image outpul
JSON annotation. You return single,
complete JSON object and nothing clse. Do not Markdown, explanations, or extra Fields fields strictly filled):
content: Choose create functional calegory. Reference categories include: Login/Auth, Dashboard, List/Feed, Detail
View, Form/Input, Settings, Profile, Fcommerce, Londing Page, Onboarding, Search, Modal/Diolog, Norificottio/Alert, Error/Empty State, Navigation/Tab Bar, Checkont, Payment, Content Editor, Unknown.
description: Provide concise description of the Ul's primary elements, layout, and l'unction.
Instructions:
Examine the layout, text, colors, and all design elements carefully.
non non-emppl empty value. the conLent. field, if of the reference categorics good new, appropriate category name.
every
present
Ensure the final ousput single, fully parsable ISON object.
Examples:
"ocacent"; "Heasaging", "description": mobilc for nessaging app, and Last message anippela."
of recent pretile pictures
"concent": "Daatboard", "daseription": : "A dasktop adnin dashboard in dack node, displaying analysics charts, a side naviqation memu, and swveral surnary sards."
Figure 7: Prompt for using GPT-4o in additional annotation.
This subsection describes the process of annotating the curated dataset with rich, multi-dimensional labels to facilitate detailed analysis.
Manual Annotation Dimensions. Using annotation interface shown in Figure 8, each retained page is examined along three orthogonal axes under strict guidelines to guarantee aneettatt consistency:
17

---

Published as a conference paper at ICLR 2026
1 Platform label the target environment Mobile or Desktop. Decision cues: (i) Canvas/ratio: portrait, typical mobile frames (c.g., 375x812 844) indicate Mobile; landscape, desktop frames (c.g.. 1440x900, x 1080) indicate Desktop. (ii) Context: phone/tablet apps webpages rendered on phones count as Mobile; desktop apps or wehpages rendered on desktop count as Desktop. (iii) UI patterns: Mobile often shows status bar (signal/baterrytiime,, top app bar with back, bottom tab bar, drawer; Desktop often shows top horizontal nav, side nav, breadcrumbs, denser clickable links, Resolve ambiguity by prioritizing concrete UI patterns over canvas alone.
2 Complexity-grade structural richness as Low, Mid, High, or Hard using three lenses: hierarchy depth, component diversity, and layout organization. Low: 1-2 levels; <5 basic components (text, button, image, input, icon, etc.); single or simple two-column layout; ample whitespace; typical of login, simple forms, onboarding. Mid: 2-3 levels; 6-10 component types; multi-column or card layouts; lists/grids of moderate complexity; clear visual hierarchy; typical of product lists, profile, settings. High: 3-4 levels; 11-15 component types; complex multi-column; includes charts, complex tables, or multi-level menus; high information density and rich functions; typical of dashboards or analysis. Hard: 24 levels; 216 component types; highly intricate layouts with many interactive/dynannt modules; integrated
workspaces; complex information architecture and high cognitive load; typical of comprehensive admin suites or multi tool workbenches. When in doubt, select the level matching the most demanding criterion among depth, diversity, or layout complexity.
3 Quality Rating-scom score visual and experiential quality 3-point scale: I-Fair, 2-Good, 3-Ex- cellent. 1-Fair: basic color pairing without conflict but lacks highlights; conventional typography with limited hierarchy: usable but average experience; styles mostly consistent yet coarse details; information clarity is adequate, interactions minimally considered. 2-Good: coordinated colors and clear visual layers; appropriate typography with readable hierarchy; strict adherence design tokens; consistent components and spacing; smooth basic UX with clear information and standard usability. 3-Excellent: outstanding color and strong visual impact; refined, layered typography; meticulous, innovative yet consistent component design; superior UX with intuitive flows, precise information de- livery, and attention accessibility; demonstrates thoughtful, possibly novel interactions. Annotators should rate based the overall impression, resolving ties by weighing consistency and UX clarity over mere visual flair.
Page Screenshot
Output
Ruge 941324
GBSTOCcKEPORSRCCCGINN TO4/55
Resume
Prevoux
Experience
Keep
no
platform
mobile
desktop
complesity
High
quality. rating
Figure 8: The custom-built interface for manual annotation of design pages. From this UI, design experts assign labels for Platform (Mobilc/Desktop), Complexity (Low, Mid, High, Hard), and Quality Rating (1-Fair, 2-Good, 3-Excellent) to each curated design.
MLLM-Asissed Content Categorization. To further enhance data richness while reducing man- ual effort, we use opt-4o-mp 44-mmni to annotate the content and descriptise of the retained pages. We establish comprehensive classification system dividing page content into 12 main cate-
18

---

Published as a conference paper at ICLR 2026
User Identity & Personalization user profiles, account setting: 2 Marketing & Landing Content landing pages, blogs, product 3 E-Commerce & Transactions product browsing, payment, order management; 4 Data & Information
gories: 1
reviews;
- producctnnspprrutttteeeeeeee
darenattiion-dddbbrrrrrs.. data reports, list feeds; 5 Forms & Interaction Flows-forms, filters, search functions, modals; 6 Communication & collaboration-insttane messaging, community discussions; 7 Support, Guidance & Onboard- ing-help centers, tutorials, onboarding guides; 8 Notifications & cuates-noifiiatioon warnings, er- rorfempty state pages; 9 Media & Entertainment- players, photo albums, games; 10 Schedul- ing & Activities calendars, appointments, itinerary planning: 11 Health & Lifestyle- fitness tracking, meal plannings; 12 Sithers-categon not fitting above, such as contracts or maps.
C.4 DATA TRANSFORMATION AND STRUCTURING
This subsection details the post-processing steps for converting verbose Figma JSON, which contains editor-specific properties, into a clean, lightweight, and model-friendly structured representation.
Structure Pruning and Abstraction. This step streamlines the data structure and extracts the core UI information.
Node Refinement: We remove nodes that are ineffective in the final rendering. This includes: (a) invisible nodes with visible: false or opacity: 0; (b) empty shape nodes with no fills or strokes styles: (c) nodes completely occluded by opaque elements above them, identified via reverse Z-order traversal algorithm.
Layer Refinement: We flatten the node tree by removing redundant nesting. For container nodes (FRAME or GROUP) that contain only single child and have no style information of their own, we remove them and promote their child node to the container's original level. For layer groups that distribute a single set of style information across multiple layers, we merge the multi-level style information reduce nesting depth.
Property Refinement: We filter out metadata properties specific to the Figma editor (e.g.. locked, exportSett ings), as these are irrelevant to the final UI code structure.
Asset Abstraction: Figma allows designers freely assemble icons, resulting in some icons being composed of multiple shape nodes. We identify shape nodes belonging to the same icon using heuristic rules (node type is of VECTOR, STAR, LINE, ELLIPSE, REGULAR__POLYGG BOOLEAN_OPFRATE
or the name contains "merge")). These are merged into a unified SVG abstract node for subsequent export as static assets.
Coordinate and Numerical Value Standardization: We convert the absolute coordinates of all nodes to relative coordinates with the page's 's root node as the origin. Since high precision is not required for implementation, we also standardize all floating poatingg-poitt values to three decimal places to reduce input size.
Asset Collection and Integration. To create fully self- ceffaconteieed data samples, we identify and localize all external dependencies. This involves:
We identify and collect all external resources for localiza- tion and integration. This primarily includes: (a) imageRef identifiers in the fills property (bitmaps); (b) the ID of SVG ASSET nodes (vector graphics); (c) the Key for componentss, component.Sed and styles defined at the top level of the file. After collection, the corre- sponding PNG, SVG, and JSON definition files are batch-downloade
Asset Identification and Download:
via the Figma API.
Asset Deduplication & Integration: The goal of this stage is to eliminate resource redundancy and associate local resources with the node tree.
b Resource File Deduplication: While assets identified by key are often unique, assets identified by a node IDD commonly have identical duplicates (e.g., the same icon used in multiple places). These duplicates typically share the same name in the node tree. To reduce storage overhead, we perform a deduplication process: first, we group files by node name, and then perform a content comparison within each group. A mapping from duplicate IDs to primary ID is established for content-identical resources.
b Path Association and Format Unification: We update the imageRef in the node tree to a local relative path. The previously abstracted sVG ASSET nodes are converted into standard
19

---

Published as a conference paper at ICLR 2026
RECTANGLE node, and its fills property is set to IMAGE type fill pointing to the local SVG file. This approach unifies the handling of bitmaps and vector graphics, maintains Figma's 's syntax, and simplifies the processing logic for downstream models. Concurrently, the JSON definitions for componentss, component.Sets. and styles are embedded into the main data file to ensure self-containment of information.
C.5 DATASET PARTITIONING STRATEGY
To support robust model evaluation, we partition our final collection of 3,055 designs. A high-quality test set of 213 samples constructed using a rigorous process of stratified sampling followed by manual curation, with the remaining 2,842 samples forming the training set.
Stratified Sampling Framework. Our core strategy is Stratified Sampling to ensure the diversity and representativeness of the test set across key features. We construct a hierarchical structure based on the following four core dimensions: 1 Platform - Mobile vs. Desktop; 2 Complexity Low, Mid, High, Hard; Quality Rating 2, 3 (samples with rating of are excluded to retain higher-quality samples); 4 Content Category - 12 main functional categories. We calculate the proportion of samples for each combination of the above dimensions (i.e., each "stratum") in the total dataset and allocate samples for the test set according to these proportions, ensuring it serves as an unbiased microcosm of the overall dataset.
Sopert-in-the-Loow Selection Process. To guarantee the quality and typicality of the test samples, we design a two-stage selection process:
Phase Automated Candidate Set Generation
We first on the stratified sampling strategy. The number of samples this candidate set (Nredundone) is dynamically adjusted based the required number of samples for that stratum (Nearget) and the number of remaining samples (Nremain). aiming to provide ample high-quality options for manual selection. The calculation is follows:
automated script to draw oversampled candidate set from each stratum based
min(Nremaan (Nemmin 6).
Ntarget <3 3 S N Ntarget $ Ntarget > 5
Nredundont
min N Nemoinn 3. Naarget,,
min Nremain: 2Ntarget),
Phase 2: Expert Manual Selection
The generated candidate set (including image previews and stratum information) is submitted design experts. Experts review all candidate samples within each stratum and select those that best represent the category and have the clearest design. This "human-in-the-loop" process leverages both the objectivity and efficiency of automated scripts for handling large-scale data and the profound insights of human experts in aesthetics and functional understanding. This ultimately ensures the quality and typicality of every sample in the test set.
Through this process, construct high-quality, well-distributed, and representative test dataset. This dataset not only provides a solid foundation for our model evaluation but also serves as reliable benchmark for future research.
D DATASET ANALYSIS
We conduct a statistical analysis of the FiGMA2CODE dataset to demonstrate its diversity and complexity.
Composition and Diversity. The dataset contains 45% mobile and 55% desktop designs, reflecting balanced coverage of platforms. In terms of complexity, 46% of the designs are medium, 26% high, 15% low, and 14% very high. Most designs are in English, with a small fraction in other nearly balanced, with 53% labeled as good and 47% as excellent. Light themes account for 74% of the dataset, while the remaining 26% are dark. Layout usage varies across samples: 3% adopt vertical layout, 16% use horizontal layout, 48% combine both vertical and
languages. Quality ratings
20

---

Published as a conference paper at ICLR 2026
horizontal layouts, and 32% do not employ Auto Layout. As illustrated in Figures 9, these statistics highlight the dataset's 's diversity in platform, complexity, and general characteristics.
Technical and Structural Features. The metadata token length is mostly within 250,000, though a few samples reach up to 2,500,000. The maximum DOM depth mainly falls between 3-7. Node counts are typically below 200, though some designs exceed 700. The number of resource files is usually under 100, with a few samples reaching 350. Image resolutions cluster into two ranges: 800-1200 px width x 1500-2500 px height for mobile designs, and 2500-3000 px width x 1500-2500 px height for desktop designs. The variation of these structural properties across samples is visualized in Figures 10-15.
Content and Functional Category Analysis. We analyze the textual content and functional attributes of the designs to understand their distribution, as shown in Figure 16. Across functional categories, the dataset spans 12 types, with Data Information Presentation, E-Commerce & Transactions, and Marketing & Landing Pages being the most common. To further capture semantic patterns, a word cloud is generated highlighting prominent keywords such as design, designer, contact, and services, well commerce-relateer terms (product, shop, e-commerce) and user interaction keywords (account, payment, support, search). The resulting word cloud is presented in Figure 17, collectively illustrating the dataset's 's semantic diversity and functional coverage.
In summary, FIGMA2CODE demonstrates clear advantages in scale, diversity, and structural complex- ity, making it more representative of the real-world challenges in design-to-code generation.
E IMPLEMENTATION OF EVALUATION METRICS
E. VISUAL FIDELITY
Visual Embedding Similarity (VES). This term evaluates the semantic fidelity of the gen- erated UI code with respect to the original design mockup. It is defined as VES cos(Encode(T), Encode (f)), where denotes the generated page screenshot and î the origi- nal design image, and Encode is vision encoder. We adopt DINOv2 the encoder instead OpenCLIP, since DINOv2 a self-supervised vision foundation model that learns robust and transferable visual representations, surpassing OpenCLIP on most image- and pixel-level bench- marks. In contrast, CLIP's image- contrastive objective primarily emphasizes coarse coarse-grained semantic alignment and is less sensitive fineggrained layout or visual variations.
Mean Absolute Error (MAE). This term measures the pixel-level fidelity of the generated UI code with respect to the design mockup. It is defined the normalized mean absolute error between the generated page screenshot I and the design image î:
MAE L
Σ
4
41
where I, and i, denote the pixel values at position i, and N is the total number of pixels. Nor- malization ensures comparability across different resolutions. Prior work Wan et al. (2024a) has shown that MAE correlates strongly with human perceptual preferences, making an effective proxy for visual fidelity at the pixel level.
E.2 LAYOUT RESPONSIVENESS.
Relative Unit Ratio (RUR) Relative units (e.g., %, em, rem, vw/vh, fr) enable layouts to Now. scale across devices. We define RUR Nusves where Njat counts the usage of relative units in layout-related CSS properties and Ninyout is the total number of layout-related declarations (sum of both absolute layouts and relative layouts). For example, using wi width: 508 instead of wi hi 500px increases the RUR.
Absolute Positioning Ratio (APR). Excessive absolute/fixed positioning reduces adaptability across viewports. We define APR Natspos where Natspos is the number of elements with
Npositionn
pos positiin:abssen ant.oonnabobuu.... post t ono fixed, and Npns is the total number of positioned
21

---

Published as a conference paper at ICLR 2026
Platform
Complexity
45%
48%
15%
Quality_rating
Theme
26%
47%
53%
dark
74%
Language
Auto Layout
3%
16%
48%
ROHIZON
32%
Figure 9: Distribution of dataset samples across multiple attributes, including platform, complexity, quality rating, theme, language, and auto layout.
elements. For example, replacing posi cositionn absolute with a Rexbox-based layout lowers the APR.
Flex/Grid Utilization (FU). Modern CSS layout models improve structured and adaptive reflow.
We define FU Newws/grid Neustainery" where Naex/grid counts container elements adopting Flexbox or Grid, and Ncontainers is the total number of container elements. For example, using a grid layout for gallery instead of manual floating increases the FU.
Breakpoint Coverage (BC). Responsive design requires targeting multiple standard viewports.
We define BC
Neowered where N Neovered is the number of standard viewport ranges (S M/L Nes
22

---

Published as a conference paper at ICLR 2026
Total Tokens
Max Depth
3.5
0.14
3.0-
0.12
Density
2.5
Density
0.10
2.0
1.5
0.06
0.04
0.5
8.00
0.5
1.0
1.5
2.0
2.5
0.00
Length (Tokens)
1e6
Max Depth
Figure 10: Estimated total token length distri- bution.
Figure 11: DOM depth distribution.
Node Counts
100
0.004
80-
Donsity
Count
40-
0.001
0.000
400 Node Counts
FRAME RECTÁNSLE
TEXT
INSTANCE
GROUP
Node Type
Figure 12: Node counts distribution.
Figure 13: Different node types distribution.
XXL) explicitly targeted through media queries or utility prefixes, and Notd is the total number of such standard ranges. For example, defining styles for both mobile and desktop viewports increases the BC compared to only supporting one.
The weights wi ... wy balance the contribution of different aspects; in this work we set them heuristically, but they can be tuned or learned from human preference data in future studies.
E.3 CODE MAINTAINABILITY
Semantic Tag Ratio (STR). Semantic HTML improves code readability and accessibility, We define STR Noemantic where Nsemantic counts semantic elements (e.g., header, nav, main, article, ul/li), and Nelem counts all DOM elements. For example, using <button> instead of <div> with onc i ck improves the score.
Natam
Arbitrary Value Usage (AVU). Arbitrary values utility classes reduce consistency with design tokens. We define AVU Nacharray where Narbitrary counts class tokens using arbitrary value Netas
syntax (c.g., w- [133px] bg- [ff[]) and Nalss is the total number of class tokens. For example, replacing w- [1 [123px] with a standardized spacing utility (e.g., 3-3 lowers the AVU.
Inline Style Ratio (ISR). Inline styles hinder reusability and separation of concerns. define ISR Natyle
Netam where Nayyle is the number of elements carrying inline style declarations and Nelem is the total number of DOM elements. For example, using <div style="color: color: red; decreases the ISR if replaced with reusable CSS class.
23

---

Published as a conference paper at ICLR 2026
14000
Images
Metadata
12000
5
Height (pixels)
Density
8000
6000
2-
2000
8.0
0.2
0.4
12
1.4
1.6
1000
2000
3000
4000
5000
Metadata Size
1e7
Width (pixels)
Figure 14: Estimated metadata size distribu- tion.
Figure 15: Scatter density visualization of image width and height.
Health & Lifestyle
Support, Guidance & Onboarding
Media & Entertainment
Scheduling & Activities
Notifications States
Communication & Collaboration
Others
Forms & Interaction Flows
User Identity Personalization
Marketing & Landing Content
E-Commerce & Transactions
Data Information Presentation
0
10
20
30
40
Count
Figure 16: Different content type distribution across the dataset.
Custom Class Reuse (CCR). Reusing custom (non-utility) classes reflects style modularization. We define CCR Nrmund, Neustom where Nroused the number of custom class names applied to multiple elements (used frequency greater or equal to 2) and Neustom is the total number of distinct custom class names. For example, encapsulating button styles in custom class used by 10 buttons yields a higher CCR than giving each button unique inline styles.
F IMPLEMENTATION OF BENCHMARKING METHODS
F.I DIRECT PROMPTING
Design Rationale. This section presents the implementation of the Direct Generation baseline. The goal is to provide fundamental, non-iterative benchmark for generating front-end code from design files. The core principle is to leverage the comprehension and generation capabilities of Large Multimodal Models (LMMss) to directly translate Figma design specifications into fully functional HTML code through single-pass, structured prompt.
24

---

Published as a conference paper at ICLR 2026
mix
off.
business
terms
indisnusstry
figma
dattpre
service
duck
fuctunn
app
d
designee
see
rpojeccts
dise
services
album
aummy
design
simply
order
privacy
year
customer
co
companyado
conto
ct
best
chellptop
support
payment
profile
shopdel
mhopdelivery
livery
searc
printingtotal
datause see fread
countaddress view vieWstandaroprode stonndrrprodducts team team
experience website
a
Figure 17: Word cloud of the most frequent terms in the dataset.
We adopt Tailwind CSS as the target code format because it is both widely used in real-world front-end development and structurally suitable for research. Compared with arbitrary CSS, Tailwind offers standardized set of utility classes that reduce the output space while retaining sufficient expressiveness to reproduce complex layouts. This makes evaluation more consistent and reproducible across MLLMs. At the same time, Tailwind aligns with industrial workflows, ensuring that our benchmark is not purely synthetic but grounded in practical practice. Thus, Tailwind provides reasonable and effective starting point for design-to-code generation research.
This baseline supports two input modalities to evaluate the impact of different information sources on code quality:
Single-modal (JSON-only): Uses only the preprocessed Figma JSON input, testing the model's ability to reconstruct visual interface from purely structured data.
Multi-modal (JSON + Screenshot); Provides both the Figma ISON and a corresponding screen- shot. In this setup, the JSON is defined as the authoritative source of truth for layout, styling, and asset binding, while the screenshot serves only as an auxiliary reference to resolve ambiguities supplement missing context.
Prompt Engineering Strategy. To ensure stability and reproducibility. we design a rigorous prompt engineering strategy. relies on a meticulously crafted System Prompt that functions "behavioral contract" to guide the model's reasoning and output. Design data are then delivered in structured format, preceded by "content overview" to aid comprehension.
The system prompt is not simple natural language request but highly structured, machine-readable specification, built on three principles:
Principle 1: Clear Information Hierarchy. Each input source is assigned role and priority. In the multi-modal case (Figure 18), the ISON is explicitly designated as the non-negotiable source of truth for all design tokens and asset paths, while the screenshot is secondary reference only. This prevents the model from making visual inferences that contradict structured data, ensuring fidelity to the original design.
Principle 2: Transparent Preprocessing. To build more reliable interaction with the model, explicitly communicate all preprocessing steps. As shown in Figure 19, we inform the model that opaque image identifiers have already been resolved into relative paths. This prevents the model from guessing asset locations and grounds its output in the provided file structure.
Principle 3: Strict Output and Behavioral Constraints. We impose strict constraints to prevent errors and ensure utility. The prompt mandates pure HTML output for direct automated evaluation.
25

---

Published as a conference paper at ICLR 2026
The most critical rule is Mandatory Image Asset Binding, which requires the model to render an HTML element for every specified image asset using the exact provided path, eliminating hallucinated or missing assets.
Prompt for ISON-only FIGMA2CODEY Generation
You are an expert front-end developer. Generate a complete HIML decument using Falwind CSS classes from the provided Figma JSON. Adjust the generation strategy nocording preprocessing notes input contract. implementation should ensure the code not only reproduces the design draft visually, but also enhances responsiveness and maintainability. The Figma ISON the primary source for layout, spacing, sizing, colors, typography, borders, radii, shadows/ellecis, and asse bindings.
Input Contract:
Contains: Figma JSON (strictured).
Preprocessing Notes:
provided Figma JSON is preprocessed.
Originally, Figma
JSON
imageRef
values
Were
ogmnque
IDs
(eg..
34 7a55 2ad33aadddddde Fd9e93669b288535 (693366662286611
Image
heen replaced actual local relative paths (eg-. asset wtt.ss.oooopppp..oo
assels L //bar avg).
Some
merged and exported local SVG files. rectangle node created hold cach exported
SVG. with the local file path written into its imageRef.
Unnecessary properties have been removed to simplify the ISON.
Output Specification:
Format:
document only extra
after).
Example:
<IDoCTYDE
<htma lang-"en">
<heads
</read>
<hodyy </body?
</htmi>
Requirements:
Retum only the complete HTML, document.
Do wrap output in JSON any other stricture.
The
use Tailwind classes preserve visual lidelity of design.
Constraints:
1. Mandatory Image Asset Binding: For every visible node whose tills include an IMAGE with non-empty, case-sensitive imageRef value (already local relative path), you must render that ussel path in the IITML. requirement.
Allowed Rendering for Image Referenees: Prefer <img src=* [LmegeBe [ "> for placedraster'S VG asscts. Use CSS backgreund- image only when design explicilly values, escupe properly, e.g, bg- [url 1 (' aaseta a/ foo.png
image background fill. When using arbitrary
3. Path Integrity: Do not alter provided paths or their semantics.
No Hallucinated Assets: Do not introduce assets that are not explicitly specified the ISON.
External Resources: external URLs are permiited exoept Tailwind CDN.
Code Format: The final output must be the complete HTML document.
Figure 18: System prompt for the JSON-only modality, illustrating the explicit definition of input contract, preprocessing notes, and constraints.
Integration with Ablation Studies. The process is designed to naturally support ablation studies. Before the Figma JSON is passed to the model, it can be programmatically "ablated" (e.g.. by removing styling information, text content, or hierarchical structure). This ensures that in comparative experiments, all other aspects of the process inclusiingi the prompt's 's structure and content- remaann identical, Any observed performance differences can therefore be reliably attributed to the specific information removed, ensuring the validity of experimental conclusions.
F.2 F2CAGENT
To transcend the limitations single-pare generation approach, we designed and implemented more sophisticated agent model. This model emulates human developer's workflow by
26

---

Published as a conference paper at ICLR 2026
System Prompt for Multi-modal FIGMA2CODE (JSON + Screenshot) Generation
provided preprocesed Figma ISON and puge screenshot. Adjust the generation stralegy according the preprocessing notes in the input contract. The oulpui musi preserve the visual lidelity of design while improving reaponsiveness and maintaimallity.
You expert front-ead developer.
complete document using
The Figma ISON is the authoritative hindings. The screenchot only secondary reference to resolve ambiguities or missing details, and must never override explicit ISON values.
for layout, spacing. sizing, colors, lypugraphy, borders, radii, shadowsilleetts, and
Input Contract:
Contains: Higma JSON (structured), Page Screenshot (image).
Preprocessing Notes:
The provided Figma JSON is preprocessed.
Originally, Figma
JSON
imageReI
values
opaque
(o.g.
34 7oaaaaaaee 1o0a777557aaa 7adaabedd
These have been replaced with actual local relative paths (e.g., assets/foo foo. wow..ng........o.o.............. sasets/bac. avg).
vectors were merged exported local SVG liles. Rectangle nodes created hold these SVGs,
their file paths written into imageRaf.
Unnecessary properties have been removed to simplify the ISON.
Output Specification:
Format:
Valid HTML decument only (no extra text before or after).
Example:
<IDoCTVPE
<htm1 lanq="er">>
<head> </boad>
</body>
</html>
Requirements:
Return only the complete HTML decument.
wrap output JSON any other
use Tailwind classes preserve fidelity of design.
Constraints:
1. Mandatory Image Asset Binding: For every visible node whose fills include an IMAGE with non emply, case sensitive I value (already local relative path), you must render exact asset path in the HTML. a requirement.
2. Allowed Rendering for Imuge References: Prefer <img sre=* [ime ge "> for placediusten assets. Use CSS backgroundd- image only when design explicitly uses image background fill. When using Tailwind arhitrary values, escape properly, e.g., be [ur (' aaset Too prig
Path Integrity: Do not alter provided paths or their semantics.
4. No Hallucinated Assets: Do not introduce asscts that are not explicitly specified in the JSON.
External Resources: No external URLs are permiited except the Tailwind CDN.
Code Format: The final output must the complete ITTL document.
Figure 19:
System prompt for the multi-modal (JSON + Screenshot) modality, illustrating the explicit definition of input contract, preprocessing notes, and constraints.
decomposing the complex code generation task into a sequential and iterative process, encompassing initial drafting, self-critique, and refinement. The agent operates on simplified, structured Interme- diate Representation (IR) of the design, rather than the raw Figma JSON, which enhances the focus and efficiency of each step.
The agent's workflow is orchestrated as a pipeline comprising three principal stages:
Stage 1: Design Abstraction to Intermediate Representation (IR). The initial stage of the pipeline responsible for converting the verbose and complex Figma JSON into streamlined, task-oriented IR. This abstraction process serves two primary goals:
Simplification and Normalization: It distills the design data, which contains plethora of properties irrelevant to code generation, into a structured format that exclusively retains essential information, such as node hierarchy, geometry, styling attributes, and textual content.
27

---

Published as a conference paper at ICLR 2026
Semantic Enhancement:
The process enriches the representation by making implicit design semantics explicit. For instance, it might identify layout patterns (e.g., flexbox vs. grid), group related elements, or resolve asset paths, thereby creating a more actionable "blueprint" for the subsequent generation stage.
This conversion to IR effectively provides the agent with simplified and more coherent "world model" of the design, allowing it to reason about the layout and components more effectively than it could with the raw source file.
Stage 2: Initial Code Generation from IR. Following the creation of the IR, the pipeline generates an initial HTMML. Unlike other stages that leverage LMMs, this step is intentionally deterministic, employing a rule-based templating engine. This engine traverses the structured IR and maps each node corresponding HTML element with appropriate Tailwind CSS classes based predefined set of rules.
The primary objective of this rule-based approach is to produce structurally sound, albeit potentially naive, first version of the code. This initial draft faithfully represents the hierarchy and basic attributes defined in the IR, providing a consistent and predictable foundation for the subsequent refinement stage. By starting with deterministic baseline, we ensure that the creative and corrective capabiliiiess of the LMM in the refinement stage are focused on improving solid structural base, rather than generating code from scratch.
Stage 3: Iterative Celf-Coreection and Refinement. This stage embodies the agentic behavior of the model, where it iteratively improves upon its own work. The self-correction loop consists of two key personas:
Critic and Refiner.
The Critic:
The agent invokes the Critic persona to perform a self-evaluation, guided by the prompt shown in Figure 20. The Critic is instructed to analyze the currently generated HTML code against the original design specification (represented by the IR and the page screenshot). Its task is to identify discrepancies, logical errors, or areas for improvement, such as layout inaccuracies or styling deviations. The output of the Critic a structured list of actionable feedback, which serves as a clear, machine-readable guide for the Refiner. The inclusion of this critique step is a configurable option within our experimental setup, allowing us to study the impact of explicit self-evaluation final code quality.
The Refiner: The Refiner's goal is to improve the code, following the instructions in its dedicated prompt (Figure 21). It receives the current version of the HTML as its primary input. When the Critic is active, the Refiner is additionally provided with structured feedback. The prompt instructs the Refiner to apply the suggested fixes or, if no critique is provided, independently identify and implement improvements based on its own understanding of best practices. The Refiner then outputs a new, revised version of the HTML code.
This and-riien cycle can be executed for a predetermined number of iterations until the model determines that no further improvements can be made. This iterative process allows the agent to systematically address errors and converge towards a higher-fidelity final output, mirroring the cycles of coding and debugging in human software development.
F.3 UNIFIED INFERENCE PROTOCOLS FOR MLLMS
To ensure fairness and reproducibility, we adopt a unified inference setup across evaluated MLLMs.
Image Input Resolution. In direct prompting, the screenshot input resolution is set to 2x the size specified in the top-level Figma metadata container. To reduce token length, images are uploaded to a cloud service and passed to the API as secure URLs.
API Access. We query 10 MLLMs via the OpenRouter API, without imposing artificial cap on the maximum output tokens. This allows each model to utilize its full context length.
Input of Critic for F2CAGENT. For the critic phase of F2CAGENT, we encode the rendered page screenshot into base64 and provide it as input to the MILMM.
Temperature Settings. In the critic phase, we set temperature = 0.5 to encourage exploration and creativity. For all other cases, set temperature 0.0 to improve determinism and reproducibility.
28

---

Published as a conference paper at ICLR 2026
Prompt for the Critic Persona
against design specitication (given un Intermediate Representationn and screenshol) Identify all discrepancies and areas for improvementt. Your response must be a single, valid JSON object containing a issues. Do not include any surroundiag text explanations.
an expent UULX
developer.
analyze provided
JSON Schema (All fields are mandatory):
critique (Array of Objects): A list of issue objects. Each object must contain:
issue type (String): The category issuc. Examples: Layout, Styling, Compowent, Missing Content, Accessibul-
concise explanation of discrepancy. suggestion (String): specific,
description (String):
how
code.
Instructions:
1. Compare the visual rendering of the HTMI. with the provided screenshot to identify layout and style mismatches.
2. Cross-rcference the HTML against the Intermediate Represcntation (IR) to verify correct implementation of specifled properties (e.g.. colors, fonts, spacing).
For each identified issue, provide precise description and suggestion for correctio.
If the code is already perfect and requires no changes, retur JSON object with empty cr Lque array.
Example:
"critique":
"iscue_type": "Seyling",
"soscription": "The primary action button's backgreund. color is incorrect. appoars as a standard biue sut should be specific shade of purple poz the desion.", "supgestioa": the button's class 1ist, change "bg-biue-500" "bc-purpio-600" match the IR screenshot.""
"yssue_typ"": "Layout",
"dascription" "The usez profile icona header vertically atacked being aligned harisontally in row.", "auggeation"; "Ensure the containes div for the procile icons has the Y Tflex and "Clxxrron' railwind css classes applied."
Figure 20: The prompt used to instruct the Critic persona for seff-evaluation.
Prompt Templates. Within the same experiment, all MILMMs use the same prompt templates. ensuring consistent task framing and fair comparison.
G ABLATION STUDY ON FIGMA METADATA COMPONENTS
G.1
OBJECTIVE AND RATIONALE
The primary objective of this ablation study is to quantitatively assess the relative importance of different components within Figma metadata for the task of automated UI code generation. Our central research question is: "Which categories of information within the structured Figma metadata are most critical for generating high-fidelity, production-quality front-end code?"
The rationale behind this study is to deconstruct the multimodal nature of UI design artifacts and understand the model's reliance on each data modality. design's source-of-truid contains not only a visual representation (the rendered image) but also rich, structured metadata detailing its geometric layout, styling, content, and component hierarchy. By systematically removing (ablating) specific categories of this metadata and observing the corresponding degradation in the quality of the generated code (e.g., measured by visual similarity scores or structural correctness), we can infer the model's dependency internal reasoning and highlights which metadata components are indispensable versus those that can be robustly inferred from other available information, such as the visual rendering.
each ablated component. This provides critical insights into the model's
29

---

Published as a conference paper at ICLR 2026
Prompt for the Refiner Persona
improve provided ITTLL document based on set of critiques. Your response must be only the complete, revised ITTL. document. Do not include explanations, apologics, or any text outside the <!DOCTY2E hemi>. ... </html> block.
an expert front-end developer specializing relactoring correction.
Inputs You Will Receive:
Current HTML: The full HTML, code of the current implemeniation.
Critique (Optional): A ISON object containing a specific issues suggestions improvement.
Instructions:
1. Carefully review the entire current ITTML code.
If ori que ISON is provided, systematically address every issue listed. Apply the suggestions to correct the code.
If no orl t que provided, perform general review of the code. Independemtly identify and any potential issues related layout, styling, semantic correctness, component structure.
Ensure your linal output single, complese, and valid HTML document that incorporates all necessury corrections.
Example Oulput:
<1DOCTVFE ntml>
<ttnl Lang <hoad>
charses="Urr-B">
sneta nane "viowert"""" content- sidthh-deric-wwddbh undtial-scaleii.09
<script "ttsps///snn wttp/////.taataa.eee.eeeooo.saaa tannttaiinn wwi.iiiie..eo.. comteecoo///////////o/// "<//////pppt <title>Recined Pagos/sitle>
<body>
10
The full, corrected, and Inproved BIN content
rounded rounded Sumnitt/taattt <btton "ica=""s--puppie-6 test-white etc. vor
</body>
14
</heml>
Figure 21: The prompt used to instruct the Refiner persona for code correction and improvement.
G.2 EXPERIMENTAL DESIGN
To investigate this, we designed a series controlled experiments. Each experiment involves ablating one fundamental dimension of the design information from the input provided to the model. We also include baseline group, which receives the complete, unaltered metadata, serves as the control to establish the model'ss optimal performance. The experimental groups are defined in Table 4.
G.3 IMPLEMENTATION METHODOLOGY
To facilitate these experiments, developed a programmatic data processing pipeline generate the required input files for each ablation group from a single source Figma JSON file.
G.3.1 TRANSFORMATION PIPELINE
The pipeline takes the file path of a source JSON as input and applies a series of transformation functions, each corresponding to one of the ablation experiments. For each transformation, produces JSON file where the targeted information has been systematically removed, ensuring a consistent and repeatable process for every sample in our dataset.
G.3.2 TRANSFORMATION LOGIC FOR EACH ABLATION GROUP
The logic for each ablation is as follows:
Geometric Layout Ablation. The transformation recursively traverses the entire JSON tree and removes all keys related to geometric properties. This includes not only node-level attributes like and width but also nested structures such absolut sesluutBBouniinge.. and transform matrices. The process also cleans up references to these properties in component override lists to ensure their complete removal.
30

---

Published as a conference paper at ICLR 2026
Table 4: Experimental groups for the ablation study.
Group ID
Ablated Information
Core Research Question Investigated
Baseline
None (complete metadata)
What is the upper-bound performance of the model with full information?
Ablation A
Geometric Layout.
Can the model accurately reconstruct the layout solely from visual cues in the rendered image?
y. width, height, abscluteBoundingga. transforms, etc.
Ablation B
Visual Styling, Colors, fonts, ef- fects, comer radii, strokes, opac- ity, etc.
Can the model correctly infer visual styles (e.g., colors, font sizes) by "sampling" from the im- age pixels?
Ablation C
Image Content. imageRef, imageHash, and other refer- ences to external image assets.
How critical are explicit image references for correctly rendering image elements, as opposed to treating them generic placeholders?
Ablation
Hierarchical Structure. The nested parent-child relationships of all nodes.
How important the explicit DOM hierarchy for achieving correct and maintainable layout, versus "flat" structure?
Ablation
Content. characters, text, and other fields containing literal string content.
Textual
Does the semantic content text nodes influ- ence the generation of layout and styling for surrounding elements?
Visual Styling Ablation. This process performs a comprehensive removal of all styling- related information. The set of ablated keys includes fills, strokes, effects, font properties (fontName, fontsi ze, etc.), cornerRad us, opacity, tiyyy and references to style libraries The removal is applied recursively ensure that style information is purged from all parts of the JSON, including style override tables.
(e.g., fillstylerde
Image Content Ablation. This translormation targets all references to external image assets. recursively removes keys such imageRef and imageHash. Furthermore, it inspects fills and background properties and filters out any paint objects of type IMACE, effectively leaving image-filldd shapes empty containers.
Hierarchical Structure Ablation. This process fundamentally alters the node hierarchy to create a flat structure. It operates by first traversing the entire JSON to collect unique set all nodes (identified by their ic). It then reconstructs the children list of the root node, populating it with this flattened collection of all other nodes. The children property of every node in this new flat list is then explicitly emptied, resulting in structure with maximum depth of one.
Textual Content Ablation. This transformation removes all semantic textual content. It deletes the characters field from all nodes and, for nodes of type TEXT, also removes text field and anonymizes the node's 's name to prevent semantic leakage. The process also clears text values within component properties and removes text-related fields from override lists.
This methodological rigor ensures that each experimental condition cleanly isolated, allowing for valid interpretation of the results.
H MAE PX VERSUS MOS
I MORE EXPERIMENTAL RESULTS
In the main text, we report subset of evaluation metrics for clarity and readability. Here, we provide more experimental results of our benchmarking experiments, including all measured attributes from the raw evaluation files. These results allow for a more detailed examination and potential reproduction of our findings.
31

---

Published as a conference paper at ICLR 2026
Scatter Plot: MAE_PP vs MOS
2.0
1.0
MOS
0.0
-055
-1.0
-1.5
-2.0
0.0
0.2
0.4
0.6
0.8
MAE_pX
Figure 22: Scatter plot between pixel-level Mean Absolute Error (MAE-px) and Mean Opinion Score (MOS). MAE px quantifies per-pixel luminance/color deviations between paired images (lower is more similar), whereas MOS reflects human- auman-perceived structural and semantic similarity (higher is more similar). The dispersion illustrates systematic mismatch between pixel-wise error metrics and perceptual judgments, especially in cases dominated by background intensity differences or localized content shifts.
Table 5: Complete responsiveness results for multimodal code generation models.
Model
RUR (% f)
BC (% f)
FÜ (% f)
APR (% J)
Llama Maverick
3.30
6.72
50.37
6.09
Llama 4 Scout
4.72
26.06
45.89
1.42
Qwen 2.5 VL
4.40
8.24
42.07
2.66
ERNIE 4.5 424B VL
4.81
10.43
40.61
2.83
Nova Pro vl
4.59
6.88
35.14
3.84
Gemini 2.5 Pro
4.43
18.16
50.05
10.51
Grok4
2.30
5.97
34.95
31.09
Claude Opus 4.1
1.05
2.62
42.98
9.62
GPT-4o
3.72
1.99
46.88
2.94
GPT-5
1.73
17.68
35.64
14.35
J CASE STUDY
32

---

Published as a conference paper at ICLR 2026
Table Complete maintainability results for multimodal code generation models.
Model
STR (% f)
ISR (%
AVU (% 4)
CCR (%
Llama 4 Maverick
25.28
0.16
7.71
42.94
Llama 4 Scout
35.76
0.33
0.87
48.71
Qwen 2.5 VL
29.54
0.37
0.15
44.05
ERNIE 4.5 424B VL
32.03
0.61
2.06
34.68
Nova Pro Gemini 2.5 Pro Grok4
29.28
0.71
1.53
42.87
28.98
3,42
25,46
47.34
13.88
6,91
49.97
53.52
Claude Opus 4.1
19.79
1.92
23.29
40.44
GPT-4o
25.21
0.16
2.46
34.89
GPT-5
15.37
4.21
37.72
46.44
Table Complete responsiveness results for different approaches.
Method
Input
RUR (% f)
BC (% 1)
FU (% 1)
APR (% L)
Direct Prompting
6.14
0.00
0.52
0.01
Text-Augmented
7.02
0.00
0.43
0.01
Direct Prompting
</>
4.97
10.08
40.58
5.01
Template Conversion
</>
0.00
0.00
13.67
58.0
Direct Prompting
+ </>
4.81
10.43
40.61
2.83
F2CAGENT
</>
4.69
5.75
36.63
13.57
Table Complete maintainability results for different approaches.
Method
Input
STR (% t)
ISR (% 4)
AVU (% L)
CCR (%
Direct Prompting
31.86
2.68
0.00
25.69
Text-Augmented
29.67
2.46
0.00
25.75
Direct Prompting
</>
21.46
2.17
6.09
36.49
Template Conversion
</>
0.01
0.00
24.94
63.32
Direct Prompting
</>
32.03
0.61
2.06
34.68
F2CAGENT
</>
28.57
0.28
16.71
38.7
33

---

Published as a conference paper at ICLR 2026
08:0
low MAE & high MOS
high MAE & high MOS
S-M
9-42
Launch your Business with us
Large Title
THIM
Ti1le
Launch your Business with
low MAE & low MOS
high MAE & low MOS
summarizing the relationship between MAE.px px and MOS. (i) Low MAE, low MOS: Large structural misalignment or missing content yields poor perceptual similarity, yet MAE remains small when displaced/removed regions share similar background chromaticity or low contrast; pixel-wise differences are masked by homogeneous backgrounds. (ii) High MAE, high MOS: Global page layout and semantics are preserved (high MOS). but extensive background color shifts (c.g.. dark blue versus white) introduce large, spatially widespread intensity deltas, inflating MAE despite perceptual similarity, (iii) Low MAE, high MOS (desired): Minimal pixel deviations with large uniform backgrounds and small foreground components; structural alignment and content consistency lead strong agreement between MAE and MOS. (iv) High MAE, low MOS: Prominent, vividly colored foreground regions (high saturation/low luminance) occupy substantial area; local additions/removals or misplacements produce large pixel-wise errors and poor perceptual similarity. Overall, MAE is highly sensitive to global intensity and color distribution (background dominance and area coverage), while MOS is driven by structural alignment, object presence, and semantic plausibility. This divergence motivates complementing pixel-level metrics with perceptual or structure-awee aware measures for robust similarity assessment.
Figure 23: Qualitative
34

---

Published as a conference paper at ICLR 2026
CYcogt2FfgatthkookklV 12114222______1 1465/
processed wwtpsseddnntattajjoooo.
Processed netadata
root. png
Rendered image of the root node
assets/
aeeerrefs/
inageRef images
assets/
SVG asset files
5vg
Files Structure
Robeids Kinglom
working
Share
Congrats
9:41
Yourve just wor ahe gomo dicio pinctsikoim this twrm
Claim Price
Image Refs
SVG Assets
"document":
"type";
"La"ts "#22-1465",
"High Flielity (Live Strean)",
"sorpenentSeta":
"422:147":
"name": "Laoge"
"key": aepp:eessse00eeeeeeetteeeeeeeeee
"scrollnahaviar": "SCROLLS", "chi Idren":
"ronate":
"olondModo": "PASS THiouon",
"cllpscontant": true, "fille":
"document".
"name": "Taage
"Ld": "422:2427",
"blendMode"; "NDEWAL",
"sypa":
"scralieewwvter "ScROlis", "crepoeent aeppeeenrrmeeeyrrenttttioo
"type": "coeroeen" SET",
"colon":
*y*: 8.698, "p":
8.196,
"Type":
"defouitvalue" "Coven"
"vardantoptions"" "Coven"
Strokkes: [], "strokeleeight". 1.8,
"strokenlian": "IuSIDe", "styles": "istbsf; "422:78" },
childrent: ....... 1,
"Bsoouteesindinnaa""" "y":
"height":
"x" 0.o, "y": 0.8, "width": 375.8, "height": 822.8
"nane": "Color foundation/ Muttra//hitte"""
"effects": [I.
"constraints": ("vertical": "TOP", "norizontal"; "LEFT"),
"Interactione:: []
"rwant": talse.
"ytyleTyp"" "FTI"".
"descristion"
"document"
"id": Foudetioo//errrraaaatt""""
"cmponentss:
"kay":
"HECTAMOLE"
"description":
"name": "Type-tover, GasenCare, Library-Sonice,
"ollndMedd=" "PASS TiROUS"" "Fills": [
"reeote": ralse,
"documentati []+
"componentsette" "422:1427",
"alendNoda" "MBRKL"
"type": '5OLID", "colon":
"document".
1.0, tat 1.0, 16" 1.0, ta"t 1.8
Library-Sonic",,
"type": "COMROMENT"
"scrotiBehavior" "SCBOLIS", "childrenn":
Metadata(Part 1)
Metadata(Part 2)
Figure 24: Illustration of Dataset Sample.
35

---

Published as a conference paper at ICLR 2026
"opacity"
"id": "1:5",
Htype"s "GROUP" "children"s :
SoxpontSottinge
"id";
Irrelevant Attributes
"Id":
T2" 8, "
"type": TGROUST
width" 188,
hesgnt 188
"childron''-
"document"s ("id": "2:1", .....
"corponentss
Occluded by
"type": "RECTANGLE",
"3:1":
"Id": "1:4", "absolureBoundingeorr
"nome": "Type=tover, Game-Gane, LibrarysSonic"
"description" "", "remoto"s false, "componentSatId"" "4:1",
"fills" :.....)))
Invisible Nodes
Redundant Layers
docomentattooniinks""
"Id": "1:30",
"id": "1:9", Itype": "ELLIPSE"
"type": "RECTANGLE",
"stytes":
"Fills":[E
"Hills":
"blendNode": "NORMAL"
"NORMAL", "type" : "IMAGE"
"tyse": LINEAR",
"docurent": ("id": 2:11,
"scalePade"s "FILL",
[.....]
"Iragente"
"3:1": "key"
gradientstops" [....]]
}
"name": "Type-Cover, Gano-Gano,
Library-Sanie",
"description":
"id": Htype
"id": "1:10"
"type": "RECTANGLE", "fills": "blendHode"s "NOWNAL"
"resote": false,
"componentSetle" "4:1",
"Fills": C( "blendHode": "NORMAL",
"docusentation inks': 0},
"docusent": "Sa"s
"scaletode": "FIT"
"sype": "IYAGE"
Export & Update Poth
"type": "scaleHoce": "FILL" Export
Add Definition
s/sset//vgg Assets/s
)1
Imageeeff"
assets/inage /cec/ B8133219
"inagoRef"
Update Path
pep
"styles": Goohh
componentSetss:: (.....),
Components,
Shape Nodes
ImageRef
ComponentSets, Styles;
Figure 25: Illustration of Metadata Refinement.
36

---

Published as a conference paper at ICLR 2026
key": SeoaDo-TDdePPNeeeeeeY
Dedion
"file "elle_ke"" :
"node 1d": "1:124", "complextty": "loM",
"node td":: (882
complexitt" "midd
"motadata htt___yyye_________ee_ _odde_couns": "FRAME":
Taetadata, wttpett___tte__e____eee cop__tooeeccouttt
"FRAME"
"RECTANGLE"; 41,
"GROUP": 4, "TEXI":
6,
"TEXT": 18,
"GROUP": 31,
"IISTANCE": 2
Explore the app
"netadata count_counts' "netadata_rax, "etadatta_rr__dpptt""
"aotadata counts": 95,0
Can Suogle
assets_counts "compneetts": 4, "compoeentSets""
"aotadata, assets, counts
"components":
"comonnentSets"
"styles": "inogeRefs": "sugAssets":
"styles": "Inagelless;"
Cerdiiue
sygtssets":
laat
"file "#7thhehhhhho22ieggirrt"
"node te": "comlexxity" :: "hard", "setadata, wtwpttyye_eeeooeeeeeeeoe sype_node_count"" FRRME"" 55,
"RECTANGLE": 93,
scaice Suerndd
Pinar Sueeneyy
"GROUP: 132,
"INSTANCE": :
"attadata node counts":
depth":
"estadata assets countst:
"compnents""
"componentSets". 8,
"styles's B,
"inagetefs':
"sugAssets":
Figure 26: Illustration of Samples of different Complexities.
37

---

Published as a conference paper at ICLR 2026
rybonduuvs
Design Image
Image-based Direct Prompting
EBC
Figma -based Direct Prompting
F2CAgent
Figure 27: Case Study
38

---

Published as a conference paper at ICLR 2026
Design Image
Image-based Direct Prompting
Nimi
Figma bbased Direct Prompting
F2CAgent
Figure 28: Case Study 2.
39

---

Published as a conference paper at ICLR 2026
Design Image
Image-based Direct Prompting
Anttord
Figma bbased Direct Prompting
F2CAgent
Figure 29: Case Study 3.
40

---

Published as a conference paper at ICLR 2026
Design Image
Image-basee Direct Prompting
bbased Direct Prompting
F2CAgent
Figure 30: Case Study 4.
41

---

Published as a conference paper at ICLR 2026
Design Image
Image-based Direct Prompting
-based Direct Prompting
F2CAgent
Figure 31: Case Study 5.
42

---

Published as a conference paper at ICLR 2026
Mortha Crag
Jacen amading
6475PPG
know
Kamamig in Telp
Japant
popule
SoAk
IND D404
Meswege
Design Image
image-based Direct Prompting
Mortha
3043
th Orti
Japar
0181.PPG
momning
0112.7MC
DUVIO
Nausce
Figma bbased Direct Prompting
F2CAgent
Figure 32: Case Study 6.
43

---

Published as a conference paper at ICLR 2026
Reyiows
Moyle seprrrt
Clata Piptimna
Clano soarge
Mare Keuae
Design Image
image-based Direct Prompting
Revieus
Mayfie
Septimss
Carfe Suptimus
aad sopooope bo sclutt
4.5
George
Carla Geoage
Unee covemne reery
Marrer Benrier
dndriinere consentua
dere
Maren Kander
Figma -baee Direct Prompting
F2CAgent
Figure 33: Case Study 7.
44

---

Published as a conference paper at ICLR 2026
Fund Summary
Summory
Comarroe
Vixter
SIB
315
5/8
F5
Daily Food
Emapddert
Design Image
mmage-based Direct Prompting
Food S Summary
Food
Summary
7874
MIG ECW
2075 ICa!
Daily
Sleep
Water
Breskmeet
5/8
3/5
Daily
Figma -based Direct Prompting
F2CAgent
Figure 34: Case Study 8.
45

---

Published as a conference paper at ICLR 2026
Rubridde Kingtom
Congrats
Vorwi sortte guint cediiies, piase
Rutoids
Bngite
Daay
Design Image
Image-based based Direct Prompting
Rendice Eingrom Strnem
Mariio Rebbids Kingdom
Folrre
Weccing
Share
Congrats jif
Congrata
Planic
Cliim Prize
Figma -based Direct Prompting
F2CAgent
Figure 35: Case Study 9.
46

---

Published as a conference paper at ICLR 2026
Kuleidoscope
Kaloldoscope
Agency/ Portfolio
Design Image
Image-based Direct Prompting
Video Production Studio
Kaleidoscop
500
Agency/ Portfolio
Farta
Figma -base Direct Prompting
F2CAgent
Figure 36: Case Study 10.
47


Reviews:
[{"review_id": "P9bftfbm2o", "reviewer": "Reviewer_EBQS", "summary": "Existing methods generate code solely from images, overlooking that design mockups are typically delivered as Figma files—a widely used front-end design tool. This paper introduces a new task, FIGMA2CODE, pushing design-to-code research beyond image-only approaches toward a multimodal, industry-relevant setting. It is the first to establish a systematic evaluation framework that assesses not only visual fidelity but also code quality in a multimodal context.", "questions": "1. The authors state (Line 240) that the benchmark dataset was constructed via stratified sampling followed by expert selection, with the goal of maintaining balance across key dimensions such as platform, complexity, and content category. However, it remains unclear how this process quantitatively guarantees diversity and coverage. Specifically, how were the strata defined and weighted, and what measures (e.g., entropy, coverage ratio, distribution analysis) were used to verify that the final dataset indeed represents a broad and balanced distribution? Including a concrete analysis or visualization (e.g., distribution plots or summary statistics) would substantially strengthen this claim.\n\n2. The current evaluation setup seems to rely on a single run per model, which may underestimate model performance due to stochastic generation variability. Have the authors considered adopting pass@k metrics (e.g., pass@1, pass@5, pass@10) as done in standard code generation or reasoning benchmarks? Such an evaluation would provide a more robust and statistically grounded assessment of model capabilities, particularly for generative tasks.", "limitations": "", "rating": 6, "confidence": 2, "soundness": 2, "presentation": 3, "contribution": 2, "strengths": "1. The paper is clearly written.\n\n2. The paper presents novelty and comprehensive experiments.", "weaknesses": "1. The Method section requires a more concrete and transparent description, especially within the Metadata Refinement subsection. It would be beneficial to include specific figures, examples, or case studies that illustrate the data-cleaning pipeline in practice. For example, showing how noisy examples are identified, filtered, or corrected would help readers better understand the robustness and reliability of the dataset construction process.\n\n2. The definition of “difficulty” remains unclear. Lines 254–255 suggest that complexity is determined by the interface complexity, but it would strengthen the paper to provide concrete examples or ablation studies that demonstrate how tasks differ across varying difficulty levels. Furthermore, the relationship between task difficulty and model difficulty (as opposed to human preference or perception) should be clarified. It would be helpful to quantify how “difficult” tasks challenge the model’s reasoning or generation capabilities, ideally supported by empirical evidence.\n\n3. A core concern lies in the conceptual positioning of the benchmark. Benchmarks are typically designed to evaluate the ability boundaries of large models under consistent and unconditional setups. However, in this work, the proposed benchmark incorporates conditional inputs intended to assist the model in generating UI code. This design choice seems to blend evaluation with task guidance, potentially compromising the benchmark’s intended diagnostic purpose. The paper would benefit from a clearer justification for this approach—explaining whether the goal is to measure raw capability or conditional adaptability—and from additional discussion on how this aligns with broader benchmarking principles in the LLM community.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "mQCZhhDdX5", "reviewer": "Reviewer_EXnw", "summary": "The paper introduces FIGMA2CODE, a realistic multimodal design-to-code task and benchmark built from public Figma community files. Each example pairs a rendered screenshot with cleaned JSON metadata (hierarchy, geometry, styles) and linked assets (icons/images). From ~2.1k files and ~30k pages, the authors curate a 213-sample benchmark for MLLM evaluation.\n\nThey evaluate 10 state-of-the-art MLLMs with reference-free metrics for visual fidelity (VES via DINOv2; MAE), responsiveness (RUR, APR), and maintainability (STR, AVU). Results show proprietary models lead in visual similarity but lag on responsiveness/maintainability, whereas some open models produce cleaner, more responsive code. An agentic baseline (F2CAGENT) improves fidelity when using both image and metadata, and an ablation over five metadata components quantifies their differing effects (styles/assets critical for fidelity; geometry/hierarchy for responsiveness).", "questions": "- Can the authors perform human ratings and preferences as auxiliary metrics? How well does each of the metrics (VES, MAE, RUR, APR) align with empirical human preferences?\n\n- Can the authors provide any \"smarter\" or more comprehensive evaluations of code quality in addition to the two rule-based maintainability metrics? Any correlation with linter-based or expert maintainability ratings?\n\n- Can the authors report some ablation studies on the proposed agentic workflow?", "limitations": "", "rating": 6, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "- The paper reframes design-to-code as multimodal (image + metadata + assets) rather than image-only; clearly motivated by real Figma workflows\n\n- The paper shows significant effort in data curation and data quality assurance, including heuristic filters, CLIP-based dedup (0.95), expert screening, metadata pruning, asset unification, resulting in self-contained samples.\n\n- Evaluation metrics go beyond fidelity to responsiveness and maintainability; definitions are explicit and implementable.\n\n- Clear, actionable finding: e.g., metadata boosts fidelity but encourages rigid/absolute layouts; multimodality partly mitigates.", "weaknesses": "- While the paper presents a valuable MLLM benchmarking resource, the significance of the Figma2Code task is unclear given the existing commercialized figma-to-code solutions (e.g., Figma’s native export/Dev Mode plugins and third-party tools like Locofy/TeleportHQ). Further discussion is needed to justify how MLLMs may benefit front-end designers beyond existing solutions.\n\n- VES + MAE lack user-centric validation; perceptual ranking or human rater studies would strengthen claims. Both responsiveness and code quality metrics are rather hard-coded and can be “optimized” without genuinely high-quality webpages or maintainable code (e.g., inserting semantic tags mechanically). Calibrate with expert code ratings or lints.\n\n- The core benchmark (213) is relatively small for training-free conclusions and may not capture long-tail UI patterns despite stratified sampling. Recommend expanding the dataset, construct multiple subsets with varying difficulty levels, or reporting variance across multiple random subsets.\n\n- While protocols are unified, randomness of inference-time sampling and absence of statistical significance leave uncertainty about small deltas.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "3TsYQPd4qM", "reviewer": "Reviewer_5rJz", "summary": "The paper proposes a benchmark to evaluate UI code generation reflecting enterprise workflows given Figma artifacts (images and structured metadata) rather than screenshots alone. Across multiple MLLMs, the authors show that models can leverage both image and metadata to get high visual fidelity but still suffer from code responsiveness and maintainability.", "questions": "1. Can code maintainability shortcomings be addressed with explicit and detailed instructions? How about few-shot samples? Generally, how robust are the models to system prompt perturbations?\n2. Are there any human studies that tie proposed metrics to developer experience?", "limitations": "", "rating": 6, "confidence": 3, "soundness": 3, "presentation": 4, "contribution": 4, "strengths": "1. Strong problem formulation. Moving beyond screenshots-only to include metadata that is a part of enterprise UI design process makes the study highly relevant. The benchmark evaluates on axes like code responsiveness and maintainability in addition to visual fidelity.\n2. Dataset creation shows good coverage with thorough automatic filtering and human-in-the-loop checks.\n3. The metrics introduced for each axis are clear and reproducible.\n4. Experiments and ablations are informative. Results show that image + metadata improves visual fidelity. Ablations clearly indicate geometry/hierarchy drive responsiveness and metadata encourages brittle code affecting maintainability. Tables 2 and 3 sufficiently show these patterns across multiple MLLMs.", "weaknesses": "1. RUR and APR metrics don’t guarantee cross-device behavior as code-level proxies can miss real rendered issues like overflow/overlap at narrow viewports, failed wrapping/reflow, aspect-ratio distortions among others. Similarly, STR and AVU might only be superficial and ignore semantic correctness and accessibility (e.g.,  heading hierarchy), overlook architectural signals like specificity, duplication and component reuse.\n2. The MLLMs considered are predominantly closed source. Adding more open-source models can improve reproducibility. Robustness of findings to prompt variations and per-model instruction following quirks (if any; especially with open-source models) and how they are normalized is unclear. \n3. Correlation of the proposed code quality metrics with developer insights and judgements is missing.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "mCFinzXPfp", "reviewer": "Reviewer_NgVv", "summary": "This paper constructs a new benchmark called Figma2Code for the task of converting visual front-end designs into code implementations. \n\nThe main difference as compared to prior works is that prior works only considered image inputs (like screenshots of the webpages) while Figma2Code inputs also include images, assets, and metadata, such that the model can possibly reconstruct the full UI from the input. \n\nThe raw data are crawled from the Figma user community with multiple stages of filtering and additional metadata refinement. The final benchmark contains 213 processed examples. \n\nThe evaluation metrics cover three aspects, including visual fidelity, layout responsiveness, and code maintainability. The authors benchmarked various vision-language foundation models as well as various scaffolds including a simple F2CAgent that does better than naive prompting baselines.", "questions": "- What are you doing with the 2,842 auxiliary samples? Are there finetuning experiments on them?", "limitations": "", "rating": 4, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 2, "strengths": "- I think including real Figma data as the input is a valuable contribution to the community. And I'm reasonably convinced that the authors have produced a high-quality benchmark (despite the final benchmark being a bit small in size). \n\n- The F2CAgent seems to be a simple but effective agent scaffold for this task. \n\n- Quite thorough experiments.", "weaknesses": "- I think you should try to include a few actual examples in the main paper to illustrate both what the benchmark examples look like and also how good the model generations are (I think this would be much more informative than your current Figure 6). \n\n- I'm a little worried about the set of evaluation metrics that you have selected. For example, from Table 2, it looks like these metrics don't necessarily agree with each other (even for metrics in the same category). How do you reconcile this? It'd be nice to have a small-scale human eval to see how well these metrics correlate with human judgement (especially the visual fidelity metrics). \n\n- Do you have more in-depth explanations for why \"current MLLMs still struggle to balance visual fidelity with code quality\"? Do you think there's a way to finetune base models to get better at both? \n\n- While I recognize the value of this new benchmark, I also recognize that the contribution could be limited in terms of novelty. I'm therefore leaning towards a borderline score.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}]

Author rebuttal:

Decision: Accept (Poster)