Describing UI Components to AI

What This Guide Is For

The main reason AI-built interfaces disappoint is not model weakness. It is ambiguous instructions. Good UI prompting is mostly naming, constraints, and acceptance criteria.

Name The Component, Then Name The Behavior

Do not stop at “add a card” or “make a nicer nav.”

Better:

“Add a sticky header with a compact mobile menu.”
“Use a 3-column card grid on desktop and stack to 1 column on mobile.”
“Add hover, focus, active, disabled, and loading states for the CTA button.”

The more the interface depends on behavior, the more you should describe behavior directly.

Add Constraints Early

Useful constraints:

mobile-first or desktop-first
full-width or contained layout
one primary CTA only
dark or light theme with specific tone
avoid glossy gradients, avoid rounded-everything, avoid dashboard clutter

The negative constraints are often as useful as the positive ones.

State And Interaction Terms That Matter

If the element changes, name the state:

default
hover
focus
active
selected
disabled
loading
error
success

If the page adapts, name the breakpoints or at least the intended behavior across desktop and mobile.

Use Acceptance Criteria

This is the easiest upgrade for better outputs.

Example:

Build a pricing section with three plan cards.

Acceptance criteria:
- exactly three cards
- one card visually marked as recommended
- on desktop show cards in one row
- on mobile stack cards vertically
- every CTA button has hover and focus states
- no fake testimonials or invented feature badges

When To Use Reference Language

Reference language works best when it is specific about the trait you want:

“Notion-like spacing”
“Linear-style compact navigation”
“editorial landing page, not startup SaaS dashboard”