# ๐ŸŽจ DesignGym 2.0 โ€” Teaching an LLM to Think Like a Designer > *What if a machine didn't just generate a layout โ€” but learned how to improve one?* --- ## The Big Idea Imagine a blank canvas. On it, you can place anything โ€” a headline, a hero image, a call-to-action, a sofa, a warehouse shelf, a hospital bed, a circuit component. **The problem of arrangement is universal.** DesignGym 2.0 asks a radical question: **Can we train an LLM to reason about space โ€” iteratively, purposefully, the way a designer does?** Not a one-shot generator. Not a template-picker. An *agent* that looks at a layout, diagnoses what's wrong, chooses a meaningful edit, and gets better over time through feedback. That's what this project is. And it's bigger than posters. ![DesignGym architecture](assets/Architectural_Diagram.png) *Figure 1 โ€” End-to-end architecture: the OpenEnv-compliant DesignGym environment, the heuristic planner that bootstraps SFT data, the SFT adapter that locks in the action interface, and the GRPO trainer that learns design preference from verifiable reward.* --- ## ๐ŸŒ The Vision: A Canvas Is a Universal Problem Here's what hit me building this: **graphic design is just one instance of a much deeper problem.** Every time humans arrange objects under constraints to serve a goal, they are solving a layout problem: - ๐Ÿ›‹๏ธ **Interior Design** โ€” furniture in a room, flow, light, balance - ๐Ÿญ **Warehouse Planning** โ€” shelf placement, picking efficiency, safety zones - ๐Ÿฅ **Hospital Floor Plans** โ€” patient flow, emergency access, quiet zones - ๐Ÿ’ป **UI Dashboards** โ€” information hierarchy, click efficiency, accessibility - ๐Ÿ–ฅ๏ธ **Chip Placement (VLSI)** โ€” routing, thermal zones (a billion-dollar optimization problem) - ๐Ÿซ **Classroom Seating** โ€” learning groups, teacher sightlines, collaborative zones - ๐Ÿช **Retail Layouts** โ€” foot traffic, product discovery, impulse zones - ๐Ÿ“ฐ **Editorial Design** โ€” reading order, visual weight, column balance - ๐Ÿ™๏ธ **Urban Zoning** โ€” density, transit access, green space allocation The abstract structure is always the same: $$\text{objects} + \text{constraints} + \text{goals} \rightarrow \text{optimized arrangement}$$ DesignGym proves this framework works for graphic design. The architecture is a foundation for **any domain where arrangement matters**. --- ## ๐Ÿ”— Project Links | Resource | Link | |---|---| | ๐ŸŒ **Environment (HF Space)** | [DesignGym Environment Server](https://huggingface.co/spaces/yashvyasop/DesignGym) | | ๐Ÿ’ป **GitHub Repo** | [canboyedits/DesignGym](https://github.com/canboyedits/DesignGym) | | ๐Ÿง  **SFT Trained Adapter** | [designgym2-sft-qwen05-lora](https://huggingface.co/yashvyasop/designgym2-sft-qwen05-lora) | | ๐Ÿ““ **GRPO Training Notebook** | [grpo_train_colab.ipynb](https://colab.research.google.com/drive/1jw1waO-bc0Mk3U7-RBbomsIGFBWvA0aW?usp=sharing) | | ๐Ÿ““ **SFT Training Notebook** | [SFT_training_script.ipynb](https://colab.research.google.com/drive/1ZtjQSen19Sdmx8FOXvM-nb_AFDSNM_1C?usp=sharing) | | ๐Ÿ““ **Evaluation Notebook** | [evaluate_base_vs_sft.ipynb](https://colab.research.google.com/drive/1U1t9GVkc8sk2BeYCxoDnlHV1WMjYCpv1?usp=sharing) | | ๐Ÿ“Š **Training Logs** | [HF Training Job](https://huggingface.co/jobs/yashvyasop/69ed7b02d70108f37acdf597) | --- ## ๐Ÿค” Why Not Just Generate the Layout? Because that's not how it works in the real world. A good designer doesn't conjure the final poster from thin air. They start somewhere, step back, ask *"what's wrong here?"*, make a targeted edit, look again, and repeat. The process is: ``` bad layout โ†’ structural choice โ†’ placement โ†’ refinement โ†’ polish โ†’ final design ``` DesignGym 2.0 formalizes that process as a **reinforcement learning environment**. The agent learns the *workflow of design*, not just the output. This matters because layout improvement is an **optimization problem**, not a generation problem. And RL is the right tool for optimization. --- ## ๐Ÿ”ฌ Round 1 โ†’ Round 2: What Changed? | Area | DesignGym Round 1 | DesignGym 2.0 | |---|---|---| | Core goal | Optimize layouts with structured actions | Learn the *process* of design over multiple phases | | Task style | Short-horizon layout refinement | Long-horizon planning + instruction following | | Agent behavior | Local edit selection | Structure โ†’ placement โ†’ refinement โ†’ polish | | Reward | Geometry + aesthetic deltas | Delta-aware, instruction-aware, phase-aware | | Learning | Environment-ready foundation | SFT + GRPO training pipeline | | Evaluation | Layout quality + validity | Base vs heuristic vs SFT vs GRPO comparison | Round 1 answered: *Can layout design be a real RL environment?* Round 2 answers: *Can an LLM learn to act like a designer?* --- ## ๐Ÿงฉ The Environment: How It Works ### State Each design is a canvas of normalized elements. Every element $b_i$ has geometry: $$b_i = (x_i,\; y_i,\; w_i,\; h_i), \quad \text{where all values} \in [0,1]$$ A layout is: $$L = \{b_1, b_2, \dots, b_n\}$$ The state given to the agent includes: task ID, step count, current score, best score so far, instruction score, phase score, metric vector, weakest metrics, focus elements, action history, full geometry, and current phase. The agent can reason not just about *what* the layout looks like but *where it is* in the design process. The RL loop: $$s_t \;\xrightarrow{\;a_t\;}\; s_{t+1},\; r_t$$ ### Actions The action space spans both pixel-level and structural edits โ€” because real design isn't just moving boxes: **Primitive actions:** `move`, `resize`, `align`, `distribute`, `snap`, `swap_z` **Structural actions:** `apply_template`, `promote`, `reflow_group`, `anchor_to_region`, `finalize` For example: - *"Make the title louder"* โ†’ `promote` - *"Clean up the spacing"* โ†’ `distribute` or `reflow_group` - *"Move the CTA to the footer"* โ†’ `anchor_to_region` - *"Choose a stronger layout"* โ†’ `apply_template` ### Hard Constraints The feasible layout space is: $$\mathcal{F} = \{L \mid L \text{ satisfies margin, size, ratio, and region constraints}\}$$ Only $L \in \mathcal{F}$ are accepted. Invalid actions are rejected โ€” forcing the agent to learn *legal creativity*. --- ## ๐ŸŽฏ Solving Aesthetics: The Math of "Good Design" This is where DesignGym gets serious. Rather than asking *"does it look good?"* (subjective), we ask *"what makes it measurably good?"* (computable). My research into computational aesthetics โ€” from Birkhoff's 1933 aesthetic measure $M = O/C$ to modern Visual Moment Equilibrium models โ€” confirmed that most design quality signals are **mathematically expressible**. DesignGym implements seven of them: ### The Composite Score $$U(L) = \sum_{k=1}^{K} \lambda_k \, g_k(L), \quad g_k(L) \in [0,1],\; \sum_k \lambda_k = 1$$ Each $g_k$ is an independent, interpretable aesthetic signal. Together they give a holistic quality score $U(L) \in [0,1]$. --- ### 1. Overlap โ€” *Do elements collide?* $$g_{\text{overlap}}(L) = \exp\!\left(-\frac{\sum_{i 0$. This enforces long-horizon behavior and prevents the agent from prematurely declaring victory. --- ## ๐ŸŽ“ Training Pipeline: From Language to Design Policy ``` Base Model โ†’ Heuristic Planner โ†’ SFT Model โ†’ GRPO Model ``` ![Heuristic planner output](assets/Heuristic_Output.png) *Figure 2 โ€” The heuristic planner solving an episode end-to-end. It diagnoses the weakest metric, picks a phase-appropriate action, applies it, and re-scores โ€” generating the (state โ†’ action) pairs we use as SFT training data. This is how the agent gets a warm start without human labels.* ### Why SFT First? The base model (Qwen 0.5B) understands design language but cannot speak the *environment's action format*. It says things like: > *"Move the title higher and make the CTA stronger."* Semantically meaningful โ€” but not executable. The environment needs: ```json { "action_type": "anchor_to_region", "element_id": "cta", "region": "lower_right" } ``` **SFT teaches the model the interface.** The goal is not creativity โ€” it's action correctness. Result: `valid_json_rate: 0%` โ†’ `valid_json_rate: 100%`. That's not a fine-tune. That's a capability phase transition. ![SFT training metrics](assets/SFT_plot_collage.png) *Figure 3 โ€” SFT training evidence on Qwen-0.5B: loss converges cleanly, validity rates jump to 100%, and the action distribution learned by the model mirrors the heuristic teacher. After SFT the model can act in DesignGym; before SFT it cannot.* ### Why GRPO After? Once the model can act, GRPO teaches it *which valid action is better*. GRPO uses environment reward directly โ€” no static labels, no human annotation on every trajectory. The loop: 1. Sample multiple candidate actions 2. Execute them in DesignGym 3. Score each with the verifier 4. Increase probability of higher-reward actions 5. Decrease probability of lower-reward actions This works because DesignGym has **verifiable rewards** โ€” the environment is the oracle. No reward model needed. The learning story: $$\text{Language Model} \;\xrightarrow{\;\text{SFT}\;}\; \text{Action Model} \;\xrightarrow{\;\text{GRPO}\;}\; \text{Design Policy}$$ --- ## ๐Ÿ“Š Results: Evidence of Learning ### Training-time evaluation (Colab) | Policy | Final Score | Instruction Score | Valid JSON | Early Finalize | |---|---|---|---|---| | **Base** Qwen 0.5B | 0.6948 | 0.5360 | **0%** | 100% | | **SFT** Qwen 0.5B | 0.7101 | 0.6263 | 100% | 0% | | **SFT @ Best-of-4** | 0.7057 | 0.6672 | 100% | 0% | | **GRPO** Qwen 0.5B | 0.6717 | 0.5483 | 98% | 67% | | **GRPO @ Best-of-4** โ˜… | 0.6781 | **0.5817** | **100%** | **17%** | โ˜… = shipped headline configuration. Baseโ†’Final pipeline gain on instruction score: **+8.5%**, on valid JSON: **0% โ†’ 100%**, on premature finalizes: **down 83%**. ### Post-deployment benchmark (36 episodes, 3 tasks ร— 3 seeds ร— 4 backends) After fixing the deployment honesty bug (the original Space silently used base Qwen via the HF Router instead of the LoRA adapters), we ran a full deterministic benchmark locally on MPS (Apple M1): | Backend | Instruction Score | Total Reward | Avg Time | LLM Steer Rate | |---|---|---|---|---| | Heuristic | 0.5564 | 1.588 | **0.0s** | โ€” | | Base (no LoRA) | 0.5367 | 1.679 | 11.5s | 100% | | **SFT Fine-tuned** | 0.5557 | 1.789 | 16.8s | 100% | | **GRPO Fine-tuned** | **0.5599** | **1.854** | 12.0s | 100% | **Honest takeaway:** The heuristic is a strong baseline (written with full knowledge of the reward function). SFT's main contribution is the 0% โ†’ 100% valid JSON phase transition. GRPO accumulates the most per-step reward and shows the strongest instruction scores on the hardest task (dense_flyer: 0.687 vs heuristic 0.624). The adapter lift over base is small (+0.5โ€“2%) at 0.5B scale โ€” a larger base model (3B+) would likely show bigger gains. More GRPO training budget (current: ~200 steps on free Colab) is the clearest path to improvement. For the full honest analysis, see the [Findings page](web/findings.html) in the live demo. The most important result is the jump from **0% to 100% valid actions**. That's the model crossing from "knows about design" to "can act in a design environment." GRPO then learns *which* valid actions are better โ€” a harder problem that continues to improve with more training. The infrastructure and reward signal are proven. ![Finetuned output](assets/FT_Output.png) --- ## ๐Ÿ› ๏ธ Tasks Supported **`poster_basic_v1`** โ€” Headline hierarchy, hero image placement, CTA placement, clean spacing, reading order. **`editorial_cover_v1`** โ€” Masthead preservation, headline stack, visual balance, editorial hierarchy. **`dense_flyer_v1`** โ€” Crowded layout repair, support group reflow, spacing under density, caption alignment. Three very different design problems. A model that improves across all three has learned *general layout reasoning*, not template memorization. --- ## ๐Ÿ”ฎ How Big Can This Get? The framework underlying DesignGym isn't about posters. It's about this general structure: $$U(L) = \lambda_1\, g_{\text{efficiency}} + \lambda_2\, g_{\text{safety}} + \lambda_3\, g_{\text{accessibility}} + \lambda_4\, g_{\text{aesthetic}}$$ Swap the metrics. Swap the domain. The agent still learns to optimize arrangement through sequential decision-making. **Interior Design:** `empty room โ†’ zoning โ†’ furniture placement โ†’ spacing โ†’ style polish` **VLSI Chip Placement:** `component placement โ†’ routing โ†’ thermal zones โ†’ signal integrity` **Warehouse Logistics:** `shelf placement โ†’ picking paths โ†’ safety zones โ†’ density optimization` **Hospital Layout:** `patient flow โ†’ emergency access โ†’ staff circulation โ†’ quiet zones` **UI Design:** `information hierarchy โ†’ click paths โ†’ accessibility โ†’ responsive stability` The same RL loop. A different reward function. **The canvas is always the problem, and the canvas is everywhere.** --- ## ๐Ÿ—๏ธ Architecture ``` . โ”œโ”€โ”€ client.py # OpenEnv client interface โ”œโ”€โ”€ inference.py # Policy inference runner โ”œโ”€โ”€ models.py # Typed action/observation models โ”œโ”€โ”€ notebooks/ โ”‚ โ”œโ”€โ”€ grpo_train_colab.ipynb # GRPO training โ† start here โ”‚ โ”œโ”€โ”€ SFT_training_script.ipynb # SFT training โ”‚ โ””โ”€โ”€ evaluate_base_vs_sft_designgym2.ipynb โ”œโ”€โ”€ training/ โ”‚ โ”œโ”€โ”€ grpo_train.py # GRPO training script โ”‚ โ”œโ”€โ”€ generate_sft_data.py # SFT data generation โ”‚ โ””โ”€โ”€ run_grpo.sh # Smoke test runner โ”œโ”€โ”€ server/ โ”‚ โ”œโ”€โ”€ app.py # FastAPI wrapper โ”‚ โ”œโ”€โ”€ DesignGym_environment.py # Core environment logic โ”‚ โ”œโ”€โ”€ rewards.py # Reward functions โ”‚ โ”œโ”€โ”€ phases.py # Phase-aware logic โ”‚ โ””โ”€โ”€ requirements.txt โ”œโ”€โ”€ data/sft/ # SFT train/eval data โ”œโ”€โ”€ assets/ # Plots and diagrams โ”œโ”€โ”€ web/ # Demo web UI โ”œโ”€โ”€ Dockerfile โ”œโ”€โ”€ pyproject.toml โ”œโ”€โ”€ openenv.yaml # OpenEnv manifest โ””โ”€โ”€ README.md ``` --- ## โšก OpenEnv Compatibility DesignGym is fully OpenEnv-compatible: `reset()`, `step(action)`, typed models, FastAPI server, Docker + HF Space deployment, deterministic seeded episodes. --- ## ๐Ÿš€ Running It **Install:** ```bash pip install -e . openenv validate python server/app.py ``` **Docker:** ```bash docker build -t designgym-env . docker run --rm -p 8000:8000 designgym-env ``` **Inference:** ```bash HF_TOKEN=your_token \ API_BASE_URL=https://router.huggingface.co/v1 \ MODEL_NAME=meta-llama/Llama-3.1-8B-Instruct:scaleway \ DESIGNGYM_TASK=poster_basic_v1 \ python inference.py ``` --- ## ๐Ÿงช What's Next - **Image-Aware Reward** โ€” Saliency maps, OCR regions, protected focal zones - **Preference-Trained Reward Model** โ€” Learn from human pairwise layout comparisons - **Style-Conditioned Design** โ€” Luxury, editorial, minimal, corporate as goal inputs - **Interior DesignGym** โ€” Same framework extended to room/furniture layout - **Multi-Agent Critique** โ€” Designer agent proposes โ†’ Critic agent diagnoses โ†’ Designer improves - **Multi-Page Layout** โ€” Magazines, slide decks, reports, product catalogs --- ## ๐Ÿ’ก The Bottom Line Design is usually treated as subjective and unteachable by machine. DesignGym proves that's not true. Many aspects of layout quality are **computable, verifiable, and learnable**. And because the underlying framework is general, the same approach extends to any domain where arrangement matters. The final vision: models that don't just generate designs โ€” but **learn how to improve them**, step by step, the way a skilled designer does. > A good designer does not just produce a layout. > A good designer repeatedly diagnoses, edits, compares, and improves. > > **DesignGym 2.0 teaches that process to a machine.** --- *Built for the OpenEnv Hackathon ยท India 2026* *Math rendered with [KaTeX](https://katex.org/) / [MathJax](https://www.mathjax.org/)*