How to Design with AI Without Getting the Same Screen Twice

I asked Claude for four versions of the same landing page.
It gave me the same page four times.
Centered hero. Gradient blob. Three equal cards. Different copy, same design.
The problem was not Claude. My brief left every important decision open, so the model returned the safest average of the public web.
“Clean and premium” is not a design direction. It is permission to generate the median.

The fix was five binding decisions:
- Type
- Color
- Spacing
- Shape
- Motion
Once those values were fixed, most possible screens became illegal. That is when the outputs stopped converging.
Below is the exact constraint block I now put in the repo before generating a screen.
Copy this before you generate
DESIGN CONSTRAINTS (binding)
Type: [family]. Sizes: [12/14/16/24/40]px only.
Weights: [400,600] only.
Color: bg [hex], fg [hex], accent [hex], muted [hex].
No other color.
Spacing: multiples of [4]px only.
Radius: [6]px everywhere.
Grid: [12] columns, max width [1120]px, gutter [24]px.
Motion: [none] / [150ms ease-out on hover only].
Forbidden:
- mesh behind text
- emoji as icons
- fabricated metrics or testimonials
- centered body copy longer than one line
- a second radius
If a constraint makes the request impossible, stop.
Do not improvise a new design token.
Structure first.
No decoration until the hierarchy is approved.
Fill every bracket with a real value. Then move the block out of chat and into AGENTS.md, CLAUDE.md, or your token file.
If it lives only in the conversation, it disappears with the conversation.
Why AI keeps returning the same screen
A model samples a probable continuation.
“Make it modern, clean, and premium” names a huge region of the web. The densest point in that region looks familiar:
- centered headline
- short subheading
- glowing gradient
- primary and secondary CTA
- three equal feature cards
- fake social proof
Convergence is the model completing the decisions you left underdetermined.
Adjectives describe the neighborhood. Constraints close roads.
That distinction matters because adding more adjectives rarely moves the output very far. “Elegant, futuristic, sophisticated, polished” still points toward the same high-probability cluster.
A four-value palette and one permitted radius change the sample space. A paragraph about taste does not.
> The model returns the average of what it has seen. The design is what you refuse to let it average.

First, pick the correct design seat
Do not ask one tool to imagine, structure, implement, verify, and hand off the same artifact.
Pick the seat by the job.
Cinematic generation: atmosphere
Use image generation when the surface is the product: an article cover, a mood, a material world, a statue, a particle field, a gold grid.
Verify the silhouette at thumbnail size.
Do not ask this seat to preserve six exact labels, a type scale, or a data-dense contract. That is not what it is good at.
HTML and CSS: exact information
Use HTML and CSS when labels, hierarchy, spacing, or repeated fields must be exact.
This is the right seat for a checklist, comparison, contract, pricing table, or technical plate.
But exact does not mean visually unrelated. If the cover uses black stone and gold geometry, a default Tailwind card underneath it is still the wrong figure.
v0: fast first screen
Use v0 when you need a running sketch quickly.
The URL is the beginning of the design process, not proof that a design system now exists.
Export the useful structure. Bind it to your tokens. Delete the defaults.
Cursor or Claude in the repo: implementation
Use the repo seat when the real tokens, components, constraints, and diffs already live in the project.
The model should read the rules and reuse the primitives. It should not invent a fifth color because one component “needed more contrast.”
Figma: human-editable handoff
Use Figma when a designer needs to inspect and change the artifact without reading CSS.
Round-trip after the screen survives browser verification. Starting in Figma does not solve missing constraints. It only gives the ambiguity handles.
The rule is simple:
> One job per seat. One system across every seat.

The five decisions that make a system
1. Type
Choose one family, a small scale, and two weights.
Do not let the model choose a new size for every semantic nuance. Hierarchy should come from a deliberately small set of contrasts.
Example:
Family: Geist
Sizes: 12 / 14 / 16 / 24 / 40
Weights: 400 / 600
2. Color
Name the background, foreground, accent, and muted value.
Four colors are enough to create hierarchy. The fifth usually appears because the system failed to define a role.
Example:
bg: #0A0A0A
fg: #F4F4F0
accent: #D5A62E
muted: #77776F
3. Spacing
Choose one base unit and use multiples.
This removes the model’s tendency to “eyeball” every gap independently.
The point is not that 4px is universally correct. The point is that 18px, 23px, and 31px need a reason to exist.
4. Shape
Pick one radius and one border treatment.
If cards use 6px corners, buttons use pills, modals use 16px, and badges use 4px, you do not have expressive range. You have four systems negotiating on one screen.
5. Motion
Name what moves and how long it takes, or decide that nothing moves.
“Make it feel alive” invites ornamental motion. “150ms ease-out on hover only” defines behavior.
Empty fields are not flexibility. They are delegated design decisions.
— "Pick the production seat by the artifact you need, then keep one system across every seat."
Generate the boring version first
The first compliant screen should look plainer than the model’s normal output.
That is good.
Dull and systematic is cheap to improve. Distinctive and off-system usually needs a rewrite.
Generate structure before decoration:
Build only the page hierarchy.
Use the binding design constraints in the project rules.
Do not add gradients, illustrations, testimonials, metrics, or motion.
Return:
-
the content order
-
the component tree
-
the implemented screen
-
every token used that is not already defined
If an undefined token is required, stop and ask.
If the model returns a hex value outside the palette or a radius outside the system, do not polish the page. The contract is already broken.
Review in three passes, cheapest first
Most people review generated design backward. They react to polish while the hierarchy is still wrong.
Use this order instead.
Pass 1: structure
Read the screen as an outline.
- Does it say the right things?
- Are they in the right order?
- Does the primary action appear at the right moment?
- Could one section be deleted?
Generated landing pages often explain features before establishing the problem. No shadow adjustment fixes that.
Pass 2: system
Trace every visible decision back to a named token.
Search the diff for:
- a fifth color
- a second radius
- one-off margins
- arbitrary font sizes
- new shadows
- motion outside the rule
If pass two fails, stop. Do not hunt aesthetic tells on top of a broken system.
Pass 3: the tell hunt
Only now use taste.
Look for the habits that reveal an unedited model output:
- gradient blob behind the hero
- three equal cards
- fake testimonials
- decorative dashboard charts
- oversized pill buttons
- the word “seamlessly”
Feedback must name the decision.
“Make it more premium” produces shadows.
“Increase the recommended tier’s typographic weight and reduce the two adjacent tiers’ contrast” produces a hierarchy.

Worked example: one article, not three brands
I ran into the same convergence problem while producing article graphics.
The cover was cinematic: warm black, cracked stone, gold geometry. Then the first inline graphic arrived as a flat dark HTML card. The second looked like a cream technical document.
Each image was acceptable alone. Together, they looked like three products.
The fix was not a better prompt for each image. It was an inheritance rule:
- Lock one visual family.
- Name the forbidden frames.
- Generate the cover in the cinematic seat.
- Seed every inline from the cover.
- Preserve palette, material, typography, and object class.
- Change the composition, not the world.
- Verify every figure at its final article dimensions.
For this piece, the rule became:
Family: monochrome technical blueprint
Palette: warm black, white, restrained gold
Material: grid, vector line, particle field
Typography: condensed white display + small technical labels
Object class: systems diagrams, not glossy dashboards
Forbidden:
- purple gradients
- unrelated cream cards
- copied competitor frames
- generic chatbot mascots
- decorative fake metrics
The useful output was not one prettier image. It was a world the next image had to inherit.
The failure modes that matter
Constraints live in chat
The next session starts from adjectives again. Put the rules in the repo.
Styling starts before structure
You spend the expensive taste pass on a hierarchy you will later delete.
One tool owns every job
Image generation cannot guarantee a six-row receipt. HTML cannot create a convincing stone statue. A fast UI sketch does not invent your brand.
Feedback stays subjective
“More premium” is not actionable. Name weight, spacing, contrast, order, or material.
Placeholder proof survives
Generated testimonials and metrics are not harmless filler once the page ships.
Every inline starts from zero
The article becomes a mood board instead of a system.
The system keeps growing
One new color and radius per session eventually produces the same inconsistency you were using AI to avoid.
When not to use this loop
Do not use it when the layout itself is the product: a canvas tool, a novel interaction, or a dense professional workspace. Drawing the core interaction manually may be faster than correcting a probable template.
Do not use it to invent the brand. The distinguishing decision is precisely the part the statistical median cannot make for you.
Do not trust generated markup unreviewed for accessibility-critical flows. Focus order, keyboard behavior, semantics, error recovery, and reduced-motion support need deliberate verification.
And do not open the model before you can fill the five fields. Make those decisions on one screen by hand first.
The operator loop
Before generating:
- Pick the seat.
- Fill type, color, spacing, shape, and motion.
- Put the constraints in the repo.
- Name what is forbidden.
After generating:
- Review structure.
- Trace the system.
- Hunt the tells.
- Verify at the final size.
- Make every sibling inherit the same world.
A generated screen is not done because it looks expensive.
It is done when every visible decision either traces back to the system or is the one deliberate exception you chose.
Run the constraint block against one screen you already shipped.
Which field is still empty?

Get the next field note
What shipped. What broke. The system behind it.
Get the next one free:
Private alpha channel:
Related articles


AI keeps shipping the same generic UI, here's the cure
i'm going to show you why every AI generated UI on the internet looks like one website wearing 40 different icons, and the simplest unsexiest tool that fixes it for you.

Vibe Coders Are Getting Sued. Here's the EXACT 30-Minute Playbook.
Most vibe coders are still shipping apps with zero security. They focus on features, design, and shipping fast. The boring stuff feels like homework.