Mock up better UI before you build

---
name: ui-variations
description: Use when someone wants to rethink, restyle or compare layouts for an existing screen before it is built — "show me some variations", "let's rethink this page", "mock up a few options", often with a screenshot of the current UI.
---

# UI Variations

## Overview

Put the current screen and 3 real alternatives side by side on a Design canvas artifact, let the person pick, then spread the pick across every mode of the screen before a line of app code changes.

**Core principle: the mockups are only useful if they are faithful.** Read the real component before drawing anything, so every field, label and brand token on the board exists in the app.

## Process

**Read the source first.** Find the component(s) behind the screenshot. Note every field, its copy and placeholder, the submit label, the per-mode branches (e.g. a switch (type) that renders different fields), and the brand tokens: accent color, fonts, radii. Don't draw from the screenshot alone; it shows one state of one mode.

**Create the canvas.** Artifact action: "quickstart", intent: "design" → publish with the Design type_url, a title, and auto_open: "after_first_write". Follow the type's instructions for the file layout.

**Draw four boards** at the real window size (e.g. 1280×820), in one row or a 2×2 grid:

**A — Current**: today's screen redrawn faithfully. It's the baseline.

**B, C, D**: three *different ideas*, each one you can name in a few words ("prompt-first composer", "split: media | brief", "one drop zone"). Three tweaks of the same layout don't count.

Draw every board in the same state so they compare fairly: empty for forms, realistic data for screens that are always populated (settings, dashboards). Use [PLACEHOLDER]s rather than inventing numbers. An idea that only makes sense filled in can break the rule.

Tabs or sub-pages: draw the tab the person is looking at. If a direction merges or removes the tabs, say so on that board's title.

Size: the host window's real content size if the code sets one (e.g. BrowserWindow width/height); otherwise 1280×820.

**Generate the boards with a small script** in the scratchpad: a shared head, icons, row/field/button helpers, and a page() wrapper. That keeps the boards consistent and makes iterating cheap.

**Reply briefly**: the link, one line per direction, and what the boards don't show (static comps; which modes aren't covered yet). It isn't a queue item or plan until they pick.

**After the pick, expand it across the modes.** Work out from the code which modes share a form. List each group once, e.g. "C1 — Talking head (and Clean cut, Clips…)". Leave out modes the product hides. Add a new row under a title1 note. Fold in any renames they asked for.

**Iterate.** Before republishing, read each board you'll change, because the person may have edited it. Send only the files you changed. Send canvas.json only when boards are added, moved or retitled. Re-read it right before you send it.

**Hand off to code** only after sign-off. Then it's a normal fix-queue item or plan.

## Common mistakes

| Mistake | Instead |
|---|---|
| Drawing from the screenshot | Read the component; screenshots hide other modes and fields |
| B/C/D are spacing tweaks | Three different ideas, each nameable |
| Mixed states across boards | Same state everywhere unless the idea needs it filled |
| Every option visible at once (a crowded board) | One primary drop or field per mode; tuck optional inputs into slim rows that expand on use |
| Silently fixing an inconsistency you spot (e.g. a mode's form contradicts its description) | Name it in the reply as a question |
| Screenshotting or re-reading the canvas to check it | Don't verify unless asked |
| Starting the code change on "I like C" | Expand C across the modes first; build after sign-off |