To explore UI design directions with Claude Code, fix everything that isn’t a design decision (content, data, functionality, components), then ask for a small number of variants that differ on purpose: different type, layout and density, each anchored to its own reference. Build them side by side in the real app, compare them against the same criteria, and combine the strongest decisions. Three well-defined directions teach you more than twenty loose ones.
Why one direction is often too early
The first version an agent produces anchors everyone. Feedback becomes “tighten this, move that”, and the design converges on a refinement of whatever came out first, which is usually the most predictable option. Designers explore alternatives early for exactly this reason. With an agent, alternatives are cheap to build, so the cost of not exploring is mostly habit.
More variants don’t automatically mean better design. Ten random variants are hard to compare and mostly differ in noise. The value comes from controlled differences you can learn from.
Keep the requirements fixed
Before generating anything, write down what every direction must share. Otherwise you’ll be comparing different products, not different designs.
# Fixed across all directions
- Content: content/pricing.md, used exactly
- Data and behaviour: plan toggle (monthly / yearly), 3 plans,
comparison table, FAQ
- Components: src/components/ui for controls (Button, Switch,
Accordion, Table). Layout and styling may differ.
- Accessibility: WCAG 2.2 AA contrast, keyboard access, visible focus
- Responsive from 360px
- No new dependenciesDefine three directions that differ on purpose
Choose the axes you want to learn about, typically typography, layout and density, and make each direction a coherent position on them. Anchor each one to a reference, so the difference is something concrete rather than adjectives. Our guide to using visual references explains how to say what each reference contributes.
# A: Editorial
- Type: serif display headings, generous sizes, strong contrast
- Layout: single column, plans stacked vertically with long
descriptions; comparison below
- Density: low. Lots of whitespace.
- Reference: refs/editorial.png (take the type scale and rhythm)
# B: Instrument
- Type: one sans family, small sizes, tabular numbers everywhere
- Layout: plans as columns of one table, comparison merged in
- Density: high. Hairlines instead of boxes.
- Reference: refs/instrument.png (take the table structure)
# C: Product-led
- Type: neutral sans, medium sizes
- Layout: plan cards with a product screenshot per plan showing
what you get
- Density: medium
- Reference: refs/product-led.png (take how screenshots are framed)Build them side by side
Build each direction as its own route in the real app, so they share data, components and the browser you’ll judge them in. One prompt per direction keeps each coherent:
Read docs/directions/fixed.md and direction A in
docs/directions/directions.md. Build it at
app/explore/pricing/a/page.tsx. Follow the fixed requirements
exactly; everything else should follow direction A, even where it
feels unusual. Don't borrow from B or C. When done, screenshot it
at 1440 and 390 wide.For larger experiments, Claude Code can run parallel sessions in git worktrees (claude --worktree pricing-a), so each direction is built in isolation on its own branch. For a single page, separate routes are simpler. Either way, keep the explorations out of production: unlinked, excluded from search, and removed once a decision is made.
Compare fairly
Put the three side by side at the same widths, with the same content. Judge them against criteria written down before you look, so the most polished variant doesn’t win by default:
- Can a visitor find and compare the plans quickly?
- Is the recommended plan clear without being pushy?
- Does it hold up at 360px?
- Does it feel like this product, or like a template?
- Which typography, layout and density decisions are strongest, separately?
Score decisions, not variants. B might have the best table while A has the best typography. Ask Claude for a structured comparison, then make the call yourself:
Compare directions A, B and C using the screenshots. For each of
typography, layout, density, and mobile behaviour, say which
direction handles it best and why, citing what's visible. Don't
pick an overall winner.Combine the strongest decisions
Write the final direction as a short list of decisions, each traced to where it came from, then build it once more from scratch rather than editing one variant. Editing tends to drag in the rest of that variant’s choices.
# Final direction
- Typography from A: serif display headings, sans body
- Layout from B: plans as columns of one comparison table
- Density between B and C: 44px rows, hairline dividers
- Mobile from C: plans become stacked cards with the key features
- Keep: tabular numbers (B), screenshot for the top plan only (C)Then delete the exploration routes, and record the final direction where future work will see it, so the decision outlives this session.
Mistakes to avoid
- Variants that differ only in colour. Colour is the easiest thing to change later and the least informative to explore.
- Moving requirements. If content or features differ between variants, the comparison is meaningless.
- Judging in a static mock-up. Build in the real app with real content and look at real widths.
- Letting the agent choose. It can describe trade-offs well. The judgement of what’s right for the product is yours.
Explore with control
Exploration works when it’s controlled: fixed requirements, a few directions that differ on purpose, criteria set in advance, and a final design assembled from the best decisions. That final direction is part of your product’s taste; see how to give AI coding agents better design taste for keeping it. For a full page built this way, see how to build a SaaS landing page with Claude Code.
In Attuna, which is in development, a chosen direction lives with the project, so the next agent session starts from it instead of from the average.