Ask any frontier model for a landing page and you get the same page. Centered hero, gradient blob behind the headline, three feature cards with rounded corners, a purple-to-blue button, Inter at three weights, and a testimonial section for a product that has no customers yet.
It is competent. It is also instantly recognizable, which is the problem. The output is not bad design. It is average design, arrived at honestly, and this guide is about removing the conditions that produce it.
Last verified against the linked guides on this site. Version-specific details drift — check the vendor docs before relying on an exact flag or limit.
Why asking for a beautiful modern page changes nothing
The default prompt is a pile of adjectives. Clean, modern, premium, sleek, minimal. Every one of those words is satisfied by the page above, so the model has no reason to produce anything else.
Adjectives do not constrain. They describe a region of design space so large that the model falls back to the densest point in it. A constraint is something that makes most outputs illegal: a fixed type scale, three colors and no fourth, a grid the layout must sit on, a banned pattern list. Design with AI works when the prompt eliminates options rather than praising them.
By the end you will have
- A reason, stated mechanically, for why unconstrained AI design converges
- The Design Constraint Block, pasted at the top of every UI prompt
- A three-pass review order that catches the failures in the cheapest order
- A rule for when to stop prompting and draw it yourself
- A named list of patterns to forbid outright
Constrain the system before you describe the screen
Before you ask for a single component, fix the system. A model given a token set will use it. A model given nothing will invent one, and the one it invents is the average of its training data.
Decide and write down, in this order:
| Layer | Decide | Why it goes first |
|---|---|---|
| Type scale | Family, 4 sizes, 2 weights | Typography carries more of the perceived quality than color |
| Color | Background, foreground, one accent, one muted | A fourth color is where taste goes to die |
| Spacing | One base unit, powers of it | Inconsistent rhythm reads as amateur before anyone can say why |
| Shape | One radius, one border treatment | Mixed radii are the clearest tell of assembled-by-prompt UI |
| Motion | What moves, how long, or nothing moves | Unspecified motion becomes fade-in-everything |
Five decisions. Once they exist, the model is generating inside your system instead of drifting toward the mode of the web.
Mechanism dive: why unconstrained AI design converges
A model samples the most probable continuation given the prompt. When the prompt is "design a beautiful SaaS landing page", the probability mass concentrates on the shapes that dominated the training data, and the training data is the public web of the last several years, which was itself heavily influenced by a small number of template ecosystems and component libraries.
So convergence is not a failure of the model. It is the model working correctly on an underdetermined request. The output sits at the centroid of the distribution because the prompt gave it no reason to sit anywhere else.
This tells you exactly where the work is, and it is not in better adjectives. It is in reducing the entropy of the request. Every constraint you add carves away probability mass. "Use these four type sizes" is worth more than three sentences about elegance, because it makes most of the distribution illegal rather than merely undesirable.
The corollary matters too: the model cannot know which part of your design should be surprising. Distinctiveness has to come from a decision you make and it enforces. It will never come from a decision you delegate.
Review in three passes, cheapest first
Reviewing a generated interface in the wrong order wastes the expensive pass on work you are about to delete.
Pass one, structure, no styling. Does the page say the right things in the right order? Read it as an outline. If the hierarchy is wrong, styling it is wasted effort. Most generated pages fail here by putting features before the problem.
Pass two, system compliance. Does every value in the output trace back to a token you defined? Search the diff for hardcoded hex values, one-off pixel margins, and a second border radius. This pass is mechanical and can be done by a script or a second agent.
Pass three, the tell hunt. Now look for the specific patterns that mark a page as generated. This is the pass that needs your eye, and it is worth doing last, on structure you have already accepted.
Forbid these outright:
- Gradient blobs and mesh backgrounds behind text
- Emoji as feature icons
- Three cards of exactly equal weight, when the three items are not equally important
- Testimonials, logos, or metrics that do not exist yet
- Centered everything, including body copy over 60 characters
- The word "seamlessly" and its family, anywhere in the copy
- Icons chosen for decoration rather than distinction
The worked example: a pricing page in three prompts
The first prompt was the constraint block plus one sentence: three tiers, middle one recommended, annual toggle. What came back was compliant and dull, and dull is the correct starting state. Compliant and dull is fixable. Distinctive and off-system is not.
The second prompt fixed hierarchy only, no styling: the recommended tier needed more visual weight than a border color, and the annual saving needed to be a number rather than a percentage badge. Structure changes are cheap while the styling is still plain.
The third prompt introduced the one deliberate deviation, the thing that makes it the site's pricing page and not a pricing page. In this case the tier names came from the product's own vocabulary rather than Starter, Pro, Enterprise, and the comparison table was built to be readable at mobile width first, which forced most of the feature list to be cut. That cut was the actual design work, and no prompt would have proposed it, because deleting your own feature list is not the probable continuation of anything.
Magnet: Design Constraint Block
Paste this above every UI prompt. Fill the brackets with real values from your project before the first generation, not after.
## Design constraints (binding)
Type: [font 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, no exceptions.
Grid: [12] col, max width [1120]px, gutter [24]px.
Motion: [none] / [150ms ease-out on hover only].
## Forbidden
- Gradient or mesh backgrounds behind text
- Emoji as icons
- Fabricated testimonials, logos, metrics, or customer counts
- Centered body copy longer than one line
- A second border radius, a fifth color, or an unlisted font size
- Marketing adjectives in UI labels
## Output rules
- Every color, size, and spacing value must reference a token above.
- If a constraint makes the request impossible, say so and stop. Do not improvise.
- Structure first. No decorative elements until I approve the hierarchy.You should see: a first generation that looks plainer than what the model normally produces, with no hex values in the diff that are not in your list. If the output still contains an unlisted color or a gradient, the block is being ignored, and the fix is to move it into the project's rules file rather than the chat, so it applies on every turn instead of the first one.
Failure modes
| Smell | Result | Repair |
|---|---|---|
| Constraints in the chat, not in the project rules | Compliance decays after two or three turns | Put the block in AGENTS.md or the design tokens file |
| Styling reviewed before structure | Expensive polish on a page you rewrite anyway | Three passes, structure first, always |
| "Make it more premium" as feedback | Model adds gradients and shadows | Name the specific change: weight, spacing, or contrast |
| Generated placeholder social proof left in | You ship fabricated testimonials | Forbid it in the block, grep for it before deploy |
| Four accent colors after six sessions | Nothing on the page has emphasis | Token file is source of truth, CI check for stray hex |
| Distinctiveness delegated to the model | Average output, correctly produced | Choose the one deviation yourself, every screen |
When not to design with AI
- The layout is the product. A novel interaction, a canvas tool, a data-dense workspace. The model has no strong prior for these, and you will spend longer correcting than drawing.
- You do not have a design system yet. Make the five decisions first, by hand, on one screen. Generating before the system exists is how you end up with six systems.
- Brand invention. The look that separates you from competitors is the one thing that cannot come from the middle of the distribution. Direct that yourself, then let the model apply it.
- Accessibility-critical flows. Generated markup is confidently wrong about focus order and labels more often than it is wrong about color. Audit by hand.
path
Turn design rules into enforced rules
Agent OS Setup installs design tokens, repository instructions, and verification so constraints survive every session instead of the first prompt.
The model will always give you the average of what it has seen. The design is whatever you refuse to let it average.
Your next action: fill in the Design Constraint Block with the five system decisions for your current project, move it into your repository instructions rather than a chat message, and regenerate one screen you already shipped. Compare them. The gap is what the constraints were worth.
Related: Agents.md for Next.js Web Projects covers where these rules live so they apply on every turn, and Debug an AI-Written Next.js App covers what to do when the generated markup is wrong underneath.
