How to compare design variants before writing any code

To compare design variants well, build two to four versions of the same screen state that differ on one decision, look at them side by side at real device size with real content, judge them against criteria you wrote down first, and choose one before any code is written. The comparison is cheap at the prototype stage and expensive after. With a coding agent, producing the variants takes minutes, so the real work is setting up a fair comparison and making a clear choice.

Why compare variants before code

The first idea is rarely the best one, but it is the one that gets built when nobody asks for an alternative. Once it is coded, it collects tests, reviews and screens that depend on it, and moving away from it feels like waste.

Comparing variants early fixes three problems:

• Anchoring. Seeing two or three options side by side makes the weak points of each one visible. A single mockup only invites small corrections.
• Vague feedback. “I don’t like it” becomes “B reads faster than A because the total is at the top.”
• Late reversals. A direction chosen on a prototype is a decision. A direction discovered in code review is a rewrite.

Coding agents change the economics. Asking for three layouts used to mean hours of design work. Now the agent writes three HTML frames in the time it takes to read one. What stays scarce is your attention, so spend it on judging, not on producing.

How many variants, and what should differ

Two to four variants is the useful range. One is not a comparison, and past four the differences blur together.

Decide what the round is about before asking for anything. Each round should explore one decision:

Decision	Example variants
Layout	Filters in a side panel, in a top bar, or in a drawer
Hierarchy	Total at the top, or line items first and total at the bottom
Density	Comfortable cards, or a compact table
Primary action	One large button, or an inline action per row
Navigation	Tabs, a segmented control, or separate screens
Copy	A short title with a subtitle, or a single descriptive title

Keep everything else identical: same data, same texts, same colors, same device size. If variant B also happens to use a different font, you will not know whether you prefer its layout or its typography.

Make variants comparable

A comparison is only fair when the variants show the same situation. A few rules help:

1. Same state. Compare the filled list with the filled list. If the empty state matters, make it a separate round, or ask for each variant in both states.
2. Same realistic data. Use real labels and plausible content, including the awkward cases: a long name, a price with many digits, a list of 40 items.
3. Real device size. A phone layout judged on a desktop monitor at full width tells you nothing. Render each variant at the size it will ship at.
4. Short labels. Call them A, B and C, or name them after their idea (“Side panel”, “Top bar”). You will refer to them in conversation.
5. One sentence of rationale each. Ask the author, human or agent, to state what the variant optimizes for. It keeps the comparison about goals, not taste.

The states that break designs are often not the default one, so the UI states checklist is worth running on the winner before you choose.

Criteria for judging the variants

Write the criteria before you look. Otherwise the most polished variant wins, even when it solves the wrong problem.

A short checklist that works for most screens:

• Can a first-time user find the primary action in under three seconds?
• Does the most important number or status stand out?
• Does it still work with the longest realistic content?
• Does it stay consistent with the components the app already has?
• How does it look in the empty and error states?
• Are tap targets and contrast acceptable?
• What does it cost to implement, given the current code?

Score each variant against the list, or simply rank them. The goal is a sentence you can write down: “We chose B because the total is visible without scrolling and it reuses the existing table component.”

Asking a coding agent for variants

Be explicit about the decision, the constraints, and the fact that you want prototypes, not code. For example:

Prototype three variants of the Invoices screen, filled state, at phone size.
Explore only where the filters go: A in a top bar, B in a bottom sheet,
C as chips above the list. Keep the same data, texts and colors in all three.
Give each variant a one-sentence rationale. Do not modify the app code.

Then look at them together and answer with a choice, or with a new round. Avoid “take the header of A and the list of C” as a single instruction: it produces a fourth design you have not seen. Ask for that combination as a new variant and compare it with the others.

Refine, merge or start another round

After the first round, one of three things happens:

• One variant wins. Choose it and move on. Keep the others in the history in case the decision is revisited.
• One is close. Ask for a second round based on it, varying the detail that still bothers you.
• None works. That is useful information: the decision you explored was not the real problem. Reframe the round around a different decision.

Record why you chose, next to the choice. Six weeks later, “why is the total at the top?” has an answer. If you want the whole history of a screen to stay readable, it helps to treat every change as a version rather than overwriting the prototype.

Comparing variants in agentappbuilder

agentappbuilder is a canvas where Claude Code prototypes the screens of your app as HTML frames. When you ask for several directions, the agent proposes 2 to 4 variants of one state as a round, labelled A, B, C and D by default. The canvas shows one card per variant, side by side, each with a Choose button. Compare opens two versions of the same state next to each other; while variants wait, it starts with the first two.

A few details make the comparison hold:

• Until you choose, a state that already had a version keeps it active, so nothing changes by accident.
• The agent does not implement a state while its variants wait for your choice, and it never chooses in your place.
• The variants you did not choose stay in the list of versions.
• To refine a variant, the agent sends a new round based on it rather than overwriting the choice.

The Variants section of the canvas docs describes each control, and Working with your agent has the prompts for the full loop, from variants to code.

After the choice

Once a variant is chosen, it becomes the design to build. Keep the code change separate from the exploration: ask the agent to implement the chosen version only, run your checks, and review the result against the prototype, screen state by screen state. The review of UI changes made by an AI agent is easier when you know exactly which version was supposed to ship.

Comparing variants is a small habit: one decision per round, same data, written criteria, a recorded choice. It costs a few minutes per screen and saves the rewrites that come from building the first idea by default.