How to prompt AI for UI design

Prompt AI for stronger UI with a five-part workflow that defines the product, maps references, stages implementation, tests states, and corrects the render.

To prompt AI for UI design, do not ask for a finished page in one vague instruction. Use a short sequence of prompts that defines the product, maps the available code and references, builds in stages, tests every important state, and corrects the running interface with visible evidence.

The best UI design AI prompt is specific about the user and workflow before it says anything about style. “Make it modern” leaves the page structure, content, actions, states, and responsive behavior open to guesswork.

This Guide gives you a reusable five-prompt method and a complete example for a bulk refund review queue. The method works with coding agents such as Claude Code, Codex, Gemini, Kimi Code, and Cursor. Each tool has different file, skill, planning, and browser controls, so adapt the delivery mechanism while keeping the product information stable.

What a good prompt must answer

Before asking AI to design the interface, answer these questions:

Decision	Question
User	Who is using the page?
Outcome	What must the user finish?
Content	What information supports that outcome?
Actions	What can the user do?
Rules	What permissions and business limits apply?
States	What can load, fail, be empty, or succeed?
Reference	Which interface system should guide the result?
Constraints	Which code and behavior must remain?
Verification	How will you prove the page works?

If several answers are missing, the AI must invent them. A detailed style paragraph does not repair a missing product decision.

The five-prompt workflow

Use five focused prompts instead of one oversized request:

Define: Turn the product idea into a clear contract.
Map: Connect the contract and references to the existing repository.
Build: Implement structure, behavior, and styling in reviewable passes.
Test: Make every important state reachable and verify the workflow.
Correct: Compare the render with the references and fix visible differences.

Each prompt has one job and one result you can review. If the result is wrong, correct that stage before moving on.

Before you start

You need:

a real route or workflow to build
the repository that owns the interface
the project’s normal development and check commands
realistic data or fixtures
one relevant system from the InterfaceKit library
a way to review the running page at desktop, tablet, and mobile widths

Do not begin by collecting style adjectives. Begin with the user’s task.

Prompt 1: Define the product contract

The first prompt should ask the AI to expose missing product decisions, not write code.

Use this template:

Help me define one product workflow before we design or write code.

Feature:
[Name the page or workflow]

Known user:
[Who uses it]

Known outcome:
[What the user must complete]

Known constraints:
[Business, permission, technical, or legal limits]

Do not propose a visual style or implementation yet.

Return:
1. The primary user outcome in one sentence
2. Required content and data
3. Primary and secondary actions
4. Business and permission rules
5. Required loading, empty, error, success, disabled, and edge states
6. Responsive risks
7. Unanswered product questions

For the running example:

Help me define a bulk refund review workflow before we design or write code.

Known user:
A support operations lead reviewing refund requests.

Known outcome:
Find eligible requests, inspect evidence, and approve or reject them safely.

Known constraints:
- Refunds above $500 need a second approver.
- A request can change while it is open.
- Decisions require a reason.
- Only leads can approve.

Do not propose a visual style or implementation yet.

Return the outcome, content, actions, rules, states, responsive risks, and
unanswered product questions.

Review the answer. Remove invented features and resolve questions that would change the workflow.

The finished product contract might be:

Route: /refunds/review
User: A support operations lead
Outcome: Find an eligible refund request and record a safe decision
Primary action: Approve or reject request
Secondary actions: Filter requests, open evidence, add reason
Data:
- Customer
- Request amount
- Order
- Request age
- Eligibility result
- Risk flags
- Evidence
- Current reviewer
- Decision history
Rules:
- Approval requires a reason
- Refunds above $500 require a second approver
- Only leads can approve or reject
- A changed request must be reloaded before a decision
- A pending decision cannot submit twice
Required states:
- Loading
- No requests
- Populated queue
- No filter results
- Request error
- Request open
- Evidence loading
- Permission denied
- Stale request
- Decision pending
- Decision success
- Decision error
Breakpoints: 1440px, 768px, 390px
Must preserve: Existing routes, APIs, analytics, permissions, and keyboard behavior

That contract gives every later prompt a stable source of truth.

Prompt 2: Map the contract to code and references

The second prompt tells the agent to inspect before editing.

Choose one InterfaceKit system with a workflow and density close to the product. For the refund queue, collect:

application frame
filter toolbar
dense resource list or table
status and risk treatments
details panel
evidence region
approval form
confirmation and feedback patterns
typography, spacing, color, border, and radius foundations

Then use:

Read the product contract and inspect the repository files that own this route.
Review the supplied InterfaceKit references.

Do not edit yet.

Return a reference map with:
- each product region
- the existing component or pattern to reuse
- the InterfaceKit reference that guides it
- required data and states
- responsive behavior
- missing decisions or implementation risks

Then propose separate passes for structure, behavior, states, and visual
correction. Include a review stop after each pass.

A useful map looks like this:

Product region	Existing code	InterfaceKit reference
Page frame	`OperationsLayout`	Application frame
Queue controls	`SearchField`, `FilterMenu`	Filter toolbar
Refund queue	`ResourceTable`	Dense resource list
Eligibility	`StatusBadge`, `InlineNotice`	Status and risk treatment
Request details	`DetailsPanel`	Side panel
Decision form	`FormField`, `ConfirmDialog`	Approval and confirmation
Feedback	`Toast`, `ErrorState`	Pending, success, and error states

Correct the map before the agent builds. If it chooses the wrong component or invents a new page section, later CSS prompts will not fix the foundation.

Prompt 3: Build in four passes

Ask the agent to keep each pass runnable and stop for review.

Pass 1: Structure

Implement the structure pass only.

Build the existing application frame, page header, queue controls, queue
region, details region, and responsive content order.

Use the approved reference map and existing components.
Do not connect decision mutations or tune minor visual details yet.

Run the page at 1440px, 768px, and 390px.
Report changed files, structural decisions, and unresolved questions.
Stop for review.

Review hierarchy, grouping, reading order, and action priority. Do not debate a two-pixel spacing difference while the details panel is in the wrong place.

Pass 2: Behavior

Implement the behavior pass.

Connect the real queue, filters, request details, evidence, reason field,
approve action, reject action, permission rules, and stale-request handling.

Preserve API contracts, analytics, and keyboard behavior.
Prevent duplicate pending submissions.

Run the main workflow and report behavior changes and failures.
Stop for review.

Review what each action changes, who can use it, and how the interface behaves while requests are pending.

Pass 3: States

Implement the required product states using the project's existing fixture,
story, query, or test mechanism.

Make these states reachable on demand:
loading, no requests, no filter results, request error, evidence loading,
permission denied, stale request, decision pending, decision success, and
decision error.

Do not simulate only visual appearance. Preserve the state behavior a real user
would encounter.

List how to open each state and stop for review.

If a state cannot be opened, it cannot be reviewed.

Pass 4: Visual system

Apply the selected InterfaceKit foundations through the existing project
tokens and styles.

Preserve the approved structure and behavior.
Do not add a new UI, CSS, or icon library.

Compare hierarchy, density, component shape, typography, spacing, color,
borders, radius, icons, focus, hover, disabled, error, and success states.

Render 1440px, 768px, and 390px. Report remaining differences.
Stop for review.

Separating the passes keeps a visual correction from silently changing the product workflow.

Prompt 4: Test states and responsive behavior

Use a state matrix instead of asking the agent to “test everything.”

State	What must remain visible	Main failure to catch
Loading	Stable page frame and queue shape	False empty state
No requests	Clear explanation	Unnecessary create action
No filter results	Active filters and reset	Lost original queue
Request error	Failed region and retry	Whole page replaced
Evidence loading	Request facts and progress	Blank details panel
Permission denied	Read-only evidence and reason	Dead decision controls
Stale request	Changed facts and reload action	Decision on old data
Decision pending	Request, choice, and progress	Duplicate submission
Decision success	Recorded decision and next action	Ambiguous confirmation
Decision error	Preserved reason and retry	Lost user input

Then prompt:

Test the refund review workflow at 1440px, 768px, and 390px.

At each width, open the required states from the state matrix.
Use realistic long customer names, large amounts, long decision reasons, and
several risk flags.

Check:
- information priority
- horizontal overflow
- wrapping and truncation
- filter and queue relationship
- details-panel behavior
- dialog size
- focus order and visible focus
- pending-action protection
- error recovery

List failures by product impact before editing.
Fix confirmed failures, rerun the same matrix, and report evidence.

The same data and states should be used before and after a correction. Otherwise, the comparison is weak.

Prompt 5: Correct the rendered interface

The correction prompt should name visible differences, their evidence, and the behavior that must remain.

Weak:

Make it cleaner and more premium.

Strong:

Correct the current refund queue against the supplied InterfaceKit references.

Confirmed differences:
1. The queue rows are taller than the reference, so fewer requests are visible.
2. Risk flags compete with the refund amount instead of supporting it.
3. Opening details removes the queue context at 768px.
4. The decision reason is below the action instead of before it.
5. At 390px, secondary row actions force horizontal scrolling.

Fix these differences with existing components and tokens.
Keep the API flow, permissions, analytics, and keyboard behavior unchanged.
Do not introduce a separate mobile-only queue.

Rerender the same populated, stale-request, and decision-error states at
1440px, 768px, and 390px. Report what changed and what still differs.

How do you improve UI using AI after the first implementation? Give the agent the current render, the target reference, and a list of observable differences. Keep the product behavior fixed while the agent corrects confirmed gaps.

How to prompt AI for a better UI aesthetic

An aesthetic prompt is useful only when it describes design relationships the agent can inspect.

Translate vague words into evidence:

Vague request	Useful instruction
Make it clean	Remove repeated labels, preserve whitespace between regions, and reduce row noise without hiding required data
Make it modern	Use the current type scale, compact controls, clear focus states, and the selected system’s border and radius rules
Make it premium	Improve typography, alignment, density, and interaction feedback without adding decorative gradients or effects
Make it bold	Increase contrast in the primary hierarchy and action, not every heading and card
Make it minimal	Remove elements that do not support the workflow, while preserving state and permission explanations

Then use a prompt such as:

Improve the UI aesthetic without changing the approved workflow.

Use the supplied reference as the source for typography, density, spacing,
borders, radius, and interaction states.

First list:
- repeated or unnecessary elements
- weak hierarchy
- inconsistent component treatments
- local values that should use existing tokens

Make only evidence-backed changes. Preserve required content, accessibility,
responsive behavior, and product states. Rerender the same review matrix.

A better aesthetic comes from coherent decisions, not a longer list of mood words.

Complete UI design AI prompt

If your tool or task needs one initial prompt, use this compact version:

Build the bulk refund review workflow at /refunds/review.

User and outcome:
A support operations lead needs to find an eligible request, inspect evidence,
and approve or reject it safely.

Data:
Customer, amount, order, request age, eligibility, risk flags, evidence,
current reviewer, and decision history.

Rules:
- Approval and rejection require a reason.
- Refunds above $500 require a second approver.
- Only leads can decide.
- Changed requests must reload before a decision.
- Pending decisions cannot submit twice.

References:
Use the supplied InterfaceKit operations frame, filter toolbar, resource list,
status treatment, details panel, form, confirmation, and feedback patterns.
Preserve their hierarchy, density, typography relationships, spacing, borders,
radius, states, and responsive logic.

Constraints:
Inspect and reuse the existing routes, components, tokens, data layer, fixtures,
analytics, and tests. Do not add a new UI, CSS, or icon library. Preserve
semantic HTML, keyboard behavior, and visible focus.

States:
Loading, no requests, no filter results, request error, request open, evidence
loading, permission denied, stale request, decision pending, decision success,
and decision error. Make each state reachable.

Process:
Inspect before editing. Return a reference map and plan. Build structure,
behavior, states, and visual correction as separate passes. Stop for review
after each pass.

Verification:
Run the real workflow and project checks. Review realistic data and all required
states at 1440px, 768px, and 390px. List issues before fixing them. Report
evidence, deliberate deviations, and remaining gaps.

This prompt is complete because it contains product and verification information. Its length is a result of real decisions, not filler.

Use a UI prompt generator as a worksheet

A UI prompt generator can help you remember the fields, but it cannot choose the product priority or verify the result.

Use this generator template:

Feature: [route and name]
User: [specific role]
Outcome: [one finished task]
Primary action: [one action]
Secondary actions: [supporting actions]
Data: [required information]
Rules: [permissions, validation, business limits]
States: [loading, empty, error, success, disabled, edge cases]
Reference: [exact system, components, and foundations]
Reuse: [routes, components, tokens, data, tests]
Do not change: [contracts and behavior to preserve]
Breakpoints: [target widths]
Checks: [workflow, accessibility, responsive, test, build]
Evidence: [renders, screenshots, logs, test output]

Fill every bracket with project facts. If you cannot fill a field, ask a product question instead of letting the generator invent the answer.

A UI prompt generator should produce a draft contract. It should not produce an unreviewed design brief full of random sections and style trends.

What to learn from Reddit prompt examples

Searches such as “how to prompt AI for better UI Reddit” can surface useful experiments, screenshots, and before-and-after prompts. Treat them as examples, not universal recipes.

When reviewing a community prompt, ask:

Does it name a real user outcome?
Does it show the source interface and final render?
Does it include product states or only the happy path?
Does it preserve an existing design system?
Does it show mobile behavior?
Does it report which tool and model were used?
Can you see the code, checks, or workflow behind the screenshot?

Copy the useful structure. Do not copy another product’s brand, content, or visual adjectives and expect the same result.

How to prompt AI to get better results

Better results come from reducing unresolved decisions and improving feedback.

Use these rules:

Give one prompt one main job.
Put product facts before visual preferences.
Name exact files, components, and references.
Ask the agent to inspect before editing.
Define required states and make them reachable.
Review structure before styling.
Use real renders and observable differences for correction.
Preserve data, permissions, analytics, and accessibility.
Run the same checks after every material change.
Report uncertainty instead of hiding it.

If the output is far from the target, return to the contract or reference map. Repeating “make it better” usually adds patches to the wrong foundation.

Adapt this into a Claude UI design prompt

For Claude Code, keep the same contract, references, states, and checks. Put stable repository instructions in the project’s supported instruction file, invoke the team’s UI skill, and name the exact files Claude should inspect.

Start with:

Use the repository's UI implementation skill and applicable project
instructions.

Read the refund-review contract and inspect the files that own the route,
components, tokens, data, fixtures, and tests.

Do not edit yet. Return the reference map, missing decisions, implementation
passes, and verification plan.

The product prompt stays stable. The tool-specific controls change. Follow the full Claude Code UI design workflow for current instruction, skill, planning, and verification details.

Prompting checklist

Use How to get good UI from AI for the complete workflow around the prompt. Use How to make UI not look AI-generated when the first implementation already feels generic.

Adapt the method to Claude Code, Codex, Gemini, Kimi Code, or Cursor.