Run Three Claude Design Directions Before You Commit to One

Chris Harper

4 min read

Aug 21, 2026 · 12:18 UTC

Workflow

Design

Claude Design

Most designers commit to a direction too early. This three-direction exploration pattern uses Claude Design's canvas for rapid parallel iteration — then a structured comparison prompt to pick the winner before you spec anything out for Claude Code.

Previous: Fix responsive failures before Claude Code handoff · Design ramp-up 11 of 12.

Why three directions, not one iterated

A single prompt to Claude Design produces one solution — which you then refine. That's not iteration; it's proofreading. You're optimizing a single local maximum.

The directions pattern generates genuinely different structural approaches first, evaluates them against explicit criteria, and only then commits to a layout. You can defend the pick to a stakeholder, and you don't discard the best ideas from the directions you didn't choose.

Three is the right number. Two is too few to reveal the tradeoff space. Four creates analysis paralysis. Each direction needs a different starting constraint, not just a different color scheme.

Step 1: Generate three constrained directions

Open a fresh Claude Design canvas and send this in one prompt:

Generate three UI directions for a [your feature description] screen.
Keep them on separate artboard areas so I can compare.

Direction A — Information-first: structure this around data density.
Show as much relevant context as possible before the fold.
Navigation is secondary to content.

Direction B — Action-first: the primary call-to-action is the visual
anchor. Everything else exists to support the decision the user is
about to make.

Direction C — Progressive disclosure: show the minimum needed to start;
reveal detail only as the user engages. Optimise for a first-time user
who doesn't yet know what they need.

Use the same color palette and type scale across all three so we're
comparing layout structure and information hierarchy, not aesthetics.

The constraint per direction forces structural differences. "Round corners vs square corners" is not a direction; "data-dense vs action-anchored vs progressive" is.

Step 2: Score with the evaluation prompt

After reviewing all three, send:

Review these three directions against these criteria:

1. First-time user: which direction minimises time-to-first-meaningful-action?
2. Returning power user: which direction puts repeat-use features closest to reach?
3. Mobile at 375px: which direction degrades least at small viewports?
4. Handoff complexity: which direction has the fewest layout-specific edge cases
   a developer would need to handle?

Score each direction 1–3 per criterion (3 = best). Recommend the winner.
Then identify the single strongest element from each runner-up worth
incorporating into the winning direction.

This does two things: it gives you a defensible scorecard you can show a stakeholder, and it surfaces the best ideas from the directions you're discarding so they don't disappear.

Step 3: Spec the winner, hand off to Claude Code

Once you have a direction, spec it out before touching Claude Code:

Take the winning direction. Expand the primary content area into a
full layout spec:

- Exact spacing between elements (assume an 8px base grid)
- Hover, focus, and active states for all interactive elements
- Empty state: no data yet
- Error state: action failed
- Loading state: data is fetching

Output this as a structured component spec I can hand to a developer.

Then hand that spec to Claude Code directly:

Build this component in React + Tailwind. Here's the spec:
[paste the spec]

Start with the desktop layout at 1280px. Responsive breakpoints come
after the base layout is working and reviewed.

The structured spec gives Claude Code enough to produce a working component, not a layout approximation. "Here's a screenshot, make this" produces a guess. "Here's a spec with states and spacing" produces an implementation.

What this isn't

This pattern is for deciding what to build, not for visual polish. Once you've picked a direction and produced the spec, Claude Design's job is done for this feature. Visual refinement happens in your real design tool and in code review — not by iterating further in the canvas.

The pattern also doesn't replace user research. It accelerates designer decision-making, not user validation. Run usability sessions on the implemented component, not the canvas direction.