← AI Workflow Guides

Describing UI Components to AI

Use clearer UI language, state descriptions, constraints, and acceptance criteria so AI tools build the interface you intended.

Level Beginner
Time 15 minutes
Tools covered: Lovable , Replit , Cursor
ui-design getting-started prompting web-development acceptance-criteria context-packs
Updated April 4, 2026

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.

Freshness note: This guide was refreshed on April 4, 2026 to align with the current Signal Lens prompt library and builder-first versus repo-first workflow guidance.

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
  • preserve static architecture if this is a site refresh
  • draft the UI spec first if implementation should happen elsewhere

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

Give The Model The Right Evidence

For interface work, context is often:

  • screenshots or links
  • brand notes
  • content hierarchy
  • current stack or builder
  • constraints from the existing system

If the task belongs in a builder-first workflow, say that. If the task belongs in a repo-first workflow, say that too. The same design request should not be answered the same way in both lanes.

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”

Do not rely on a reference name alone. State what you are borrowing from it.