Step 4 — The Design
The Designer agent creates the visuals. It looks at our existing games and matches the style — never invents a new one.
Now the visuals.
The Designer agent doesn't invent a new style. It reads our existing games, copies the colors, fonts, and spacing, and applies them to the new game.
This keeps every game looking like it came from the same studio.
The studio design tokens
Every game shares the same atomic design tokens. We never deviate.
Colors: #00ffff (cyan, primary) #ff4466 (pink, accent) #ffcc33 (gold, success) #34d399 (green, OK) #0a0a0f (dark bg)
Font: Space Grotesk (display) Inter (body)
Buttons: sharp corners, 2px border Spacing: 8px / 16px / 24px / 48px Animation: ease-out, 200ms
✓ Same tokens, every game ✓ Players recognize us in 1 second
/tokens
Same tokens, every game.
Our 4 games share the same colors, fonts, and rhythm. That's intentional — players who see one of our games can spot another instantly.
The Designer's first instruction: "use these tokens, not your suggestions."
What the designer produces
A simple HTML mockup. Not Figma. Not a long PDF. Just a webpage that looks like the screen the game will have.
✓ HTML mockup ready ✓ Programmer matches it 1:1 ✓ No "interpretation" step
/mockup
HTML, not Figma.
Why HTML? Because the programmer copies it directly into the game engine. No translation step that loses fidelity.
Mockup looks like the final screen. Programmer matches it. Done.
The 7 mandatory states
Every screen mockup must include all 7 states the player might see. This catches design holes early.
- idle — default
- loading — spinner / skeleton
- error — connection lost
- empty — no data yet
- success — action confirmed
- disabled — button locked
- focus — keyboard nav
✓ All 7 mocked = ready to code ✗ Missing any = back to designer
/states
Mockup all 7 states or it's not done.
Most "I'll figure it out later" bugs come from forgetting empty/error states. The reviewer catches this before code starts.
Designer mocks all 7. Programmer implements all 7. Tester checks all 7.
Real example — BOP mockup conflict
"BOP" should use green for combos because green = success universally.
✗ But our token says #ffcc33 (gold) for success across all games.
# Reviewer responds
"Use the gold token. If we change to green here, players see different colors mean different things across games. Pick one rule, keep it."
# Round 2 — Designer accepts
✓ Use #ffcc33 for combo ✓ Add subtle green border at ±30ms (perfect tap) for differentiation without breaking color rule
✓ Token preserved ✓ Differentiation kept
/case-study
The reviewer keeps the brand consistent.
Without this check, every game drifts a little. After 4 games, "a little" becomes "totally different."
Brand discipline at this step pays back forever — players recognize you across launches.
When you don't need a designer
Some screens are utility — no real design choices to make. Settings menu, "are you sure?" dialog, loading screen. We skip the Designer for those and use the default templates straight from the studio's component library.
Rule of thumb: if the screen has fewer than 5 elements, skip the designer.
Common pitfalls
✗ Inventing new colors instead of using tokens
✗ Skipping the 7 states because "they're obvious"
✗ Sending an idea instead of a mockup
✗ Mocking up Figma when HTML would compile
What you can copy
Even if you don't have a brand:
- Pick 3 colors and 1 font. Use only these for your first 3 projects.
- Mockup screens in HTML or Excalidraw. Skip Figma for v1.
- Always mock all 7 states, even if 5 of them look identical.
- If something doesn't match the tokens, it doesn't ship.
Brand discipline is hard for 1 game and free for the next 5.