How to Prompt AI for UI That Doesn't Look AI-Generated

I have read a lot of UI prompts. Most of them are one sentence long, and most of the one-sentence ones produce the same screen. A centered hero, a purple-to-blue gradient behind it, three feature cards with rounded corners and a soft shadow, and an emoji sitting in front of each card like it is doing something. You have seen this screen. Everyone has seen this screen. It is what the model reaches for when you have not told it anything more specific than make it look modern and clean.

That phrase is not a prompt. It is a wish. The model has no idea what modern means to you, so it falls back to the average of every SaaS landing page it was trained on, which is a very specific and very recognizable average. If you want something that does not look AI-generated, you have to stop describing a mood and start describing a screen.

Why "make it look modern and clean" fails

Vague adjectives fail for a boring reason: they are not information. Modern, clean, professional, sleek, premium. These words carry almost no signal about layout, hierarchy, spacing, or content. When you give the model a word instead of a spec, it has to invent the rest, and it invents the same rest every time, because it is reaching for the statistically safest interpretation of that word across its whole training set.

The statistically safest interpretation of "modern SaaS UI" right now happens to include a lot of things that read as cheap the moment a human looks closely: glassmorphism on every card, a gradient behind every hero, an icon or emoji glued to every list item whether it earns its place or not, dashed borders on empty states for no structural reason. None of these are wrong in isolation. They are wrong because they show up together, reflexively, without anyone deciding they belonged there.

A good prompt removes the guesswork. It tells the model what the screen is for, what is on it, how those things relate to each other, and what to avoid. The more of that you supply, the less room there is for the model to default to slop.

The anatomy of a good UI prompt

There are five things a UI prompt needs that a mood-word prompt never has. Miss any one of them and the model fills the gap with a guess, and its guess is almost always the generic one.

1. Subject

What screen is this, specifically? Not "a dashboard," but "a dashboard for a solo freelancer to see which invoices are overdue." The subject tells the model what actually needs to be on the screen, which starts eliminating decorative filler before it ever gets generated.

2. Structure

Say what the layout is, in plain terms. A left sidebar with navigation and a main content area. A single-column form with a sticky footer. A table with a filter bar above it. If you do not specify structure, the model reaches for the most common structure in its training data, which for a hero section is almost always centered text over a gradient with two buttons under it.

3. Hierarchy

Tell it what matters most on the screen and what matters least. One clear primary action, not four buttons of equal visual weight. A number that should be the biggest thing on the page because it is the thing the user came to check. Hierarchy is the difference between a screen that tells you where to look and one that shouts everything at once.

4. Real content

Feed it actual copy, actual numbers, actual names, not "Lorem ipsum" or "Feature One / Feature Two / Feature Three." Placeholder content lets the model build a screen that only works when everything is a tidy seven characters long. Real content, including the long name that wraps and the empty state with nothing in it, forces a layout that survives contact with your product.

5. Constraints

Say what you do not want. This is the part almost nobody includes, and it is doing more work than any of the others. A short, explicit no-list closes off the exact defaults the model reaches for when it is unsure. More on this below, because it deserves its own section.

The telltale AI-slop patterns, and how to prompt against them

If you have looked at enough AI-generated interfaces, you start recognizing the same handful of tells. Naming them in your prompt, explicitly, is the single highest-leverage thing you can do.

• Purple-to-blue gradients everywhere. Backgrounds, buttons, icon fills, all reaching for the same violet-to-indigo sweep because it reads as "tech" in the training data. If you do not want it, say "no gradients" or name the actual palette you want.
• Glassmorphism on everything. Frosted, semi-transparent panels with a blur behind them, applied to cards that have no reason to float above anything. Say "solid backgrounds, no blur, no glass panels" if that is not the look you are going for.
• Emoji standing in for icons. A rocket next to "Fast," a shield next to "Secure," a chart next to "Analytics." It is the fastest way to make a product look like a hackathon demo. Say "no emoji in the interface" and mean it.
• Dashed borders on empty states and drop zones, used reflexively even when there is no drag-and-drop happening. If the screen has no upload interaction, there is no reason for a dashed border to show up.
• Generic centered hero. Headline, subhead, two buttons, all dead center, gradient behind it. It is the default because it is the safest average, and safest average is exactly what you are trying to avoid.
• Equal-weight everything. Six feature cards, all the same size, same icon treatment, same amount of copy, so nothing on the screen tells the eye where to land first.

None of these patterns are permanently banned from good design. Gradients exist in great products. The problem is that the model reaches for them by default, unprompted, regardless of whether they fit. Naming the pattern in your constraints is how you take the decision back.

First drafts vs. revisions

A first-draft prompt and a revision prompt are different jobs, and treating them the same is where a lot of people get stuck iterating in circles.

A first-draft prompt needs the full anatomy: subject, structure, hierarchy, real content, constraints. You are building the screen from nothing, so the model needs everything it would otherwise have to guess.

A revision prompt should do exactly one thing: describe the gap between what exists and what you want, as specifically as possible. "Make it better" is as useless on a revision as "make it modern" is on a first draft. "The header feels cramped, give the title more room and drop the subtext size by one step" is a prompt the model can actually execute, because it names the problem, the location, and the direction of the fix.

The other habit worth building: revise one thing at a time when you can. A prompt that tries to fix spacing, change the color, restructure the nav, and add a new section all at once gives the model four problems to solve simultaneously, and it will trade off between them in ways you did not ask for. Small, sequential, specific beats one giant paragraph almost every time.

Naming references correctly

"Make it look like Linear" is a common instinct and a weak prompt, because Linear is not one thing, it is a hundred decisions. Which part of Linear do you actually want? The monochrome UI where color is reserved for state, not decoration? The information density in its issue list? The way it uses a single accent sparingly instead of four brand colors fighting for attention?

Naming the specific decision gets you further than naming the brand. "Keep the UI mostly monochrome, save color for state like errors and success, and use one accent color for the primary action only" is a prompt built from an observation about Linear, not a request to imitate Linear. It also survives contact with a codebase that has nothing to do with a project management tool, because it is a principle, not a copy instruction.

This is the same discipline as borrowing structure instead of copying pixels: take the underlying decision a reference makes, describe that decision in your own words, and let the model apply it to your actual screen.

Before and after: four real prompts

Here is what the anatomy looks like applied to actual prompts, not abstractions.

Example 1: a pricing page

BEFORE:
Build a modern pricing page for a SaaS product.

AFTER:
Build a pricing page with three tiers: Starter ($0), Pro ($29/mo),
and Team ($99/mo). Pro is the recommended tier, give it slightly
more visual weight than the other two, not a floating badge or a
scale-up on hover. Each tier lists its actual features as a plain
checklist, no icons next to each line. One primary button per card,
same size, same position. Solid background, no gradients, no glass
panels. Neutral gray and one accent color only, used on the Pro
button and nothing else.

Example 2: an empty state

BEFORE:
Design an empty state for when there are no projects yet.

AFTER:
Design the empty state for a project list. There are no projects yet.
Show a short headline ("No projects yet"), one line of supporting text
explaining what a project is in this product, and a single primary
button ("New project"). No illustration, no icon, no dashed border
around the container since nothing here is drag-and-drop. Keep it in
the same content width as the populated list state, not centered in
the full viewport.

Example 3: a dashboard card

BEFORE:
Make a nice looking stats card for the dashboard.

AFTER:
Build a stat card showing Monthly Recurring Revenue: $18,420, up 4.2%
from last month. The dollar figure is the largest text on the card.
The percentage change sits below it in a smaller size, green if
positive, red if negative, no icon next to it. Card has a solid
background and a 1px border, no shadow, no gradient fill. If four of
these cards sit in a row, they must all be the exact same height
regardless of label length.

Example 4: a hero section

BEFORE:
Create a clean, modern hero section for our landing page.

AFTER:
Build a hero section, left-aligned not centered. Headline: "[actual
headline]". One line of supporting copy under it, then a single
primary button, no secondary ghost button next to it. Right side of
the hero holds a real screenshot of the product at 1x, not a
stylized mockup or floating browser chrome. No gradient background,
no blurred shapes behind the text. Background is a solid color from
our palette.

Notice what the "after" versions have in common. Every one of them names the actual content, states the structure instead of a mood, and closes off at least one specific default the model would otherwise reach for. None of them are longer than a few sentences. Specific is not the same as long.

Where I put this into practice

I ended up building Krit largely because I got tired of writing these prompts from scratch every time and watching the result drift back toward the same defaults. Krit is the design layer for agent-built apps: an infinite canvas where an AI agent, Claude Code, Cursor, or anything MCP-capable, designs real, interactive screens directly, with your brand captured as a set of rules the agent actually follows instead of a moodboard it politely ignores. When you are done, it exports to HTML/CSS, React, Next.js, or Vue.

The part most relevant to this post is /prompts, a library of real prompts we have used, each one paired with the actual UI it produced. It exists because reading a rule about prompting is one thing, and seeing the exact sentence that produced a specific, non-generic screen is another. If you want worked examples beyond the four above, that is where I would point you.

If you are earlier in this than a single prompt problem, that is, trying to figure out your whole approach to building UI without a design background, I wrote about that more broadly in How to Build a Good UI Without a Designer. And if you are choosing which AI tool to build the UI with in the first place, I covered the landscape in the best AI tools for building a product.

The short version

Stop describing a mood. Describe the subject, the structure, the hierarchy, feed it real content, and name what you do not want. Revise one specific gap at a time instead of restating the whole brief. When you reach for a reference, name the decision it makes, not the brand. And build a short list of the patterns you never want to see again, purple gradients, glass everywhere, emoji as icons, dashed borders with no drag-and-drop behind them, a dead-centered hero, because naming them is the fastest way to stop getting them.