How to get good UI from AI

To get good UI from AI, decide the product before asking the AI to design the interface.

Give the agent a clear user outcome, real content, one coherent interface system, required product states, and observable checks. Build the page in reviewable passes. Then inspect the running result at desktop, tablet, and mobile sizes.

The AI should spend its effort applying known decisions and implementing the workflow. It should not have to invent the audience, page structure, visual language, content, and behavior from one vague prompt.

This Guide builds a new product page. If you already have a generic interface, use How to make UI not look AI-generated instead.

What you will build

The running example is an API-key management page for a developer product.

The finished workflow lets an organization owner:

1. Review existing keys.
2. Create a named key with a permission level.
3. Copy the secret once.
4. Revoke an existing key after confirmation.
5. Understand loading, empty, error, success, and permission states.

The method works for other product workflows such as paying an invoice, inviting a teammate, exporting customers, or resolving a failed payment. Keep one workflow as the unit of work. Do not ask the AI to generate the full product at once.

Before you start

You need:

• a running application or a defined starting stack
• the route where the workflow will live
• the project’s existing components and tokens, if they exist
• realistic content and example data
• one relevant InterfaceKit reference
• access to the application at 1440px, 768px, and 390px
• the project’s normal lint, type, test, and build commands

If the project is new, decide the framework, routing, data approach, and styling system before the visual implementation. A UI task should not silently become an architecture migration.

Step 1: Define the product contract

Start with the user’s job, not a page type.

Weak:

Build a beautiful modern API dashboard.

Strong:

User: An organization owner
Outcome: Create and manage API keys without exposing a secret twice
Primary action: Create API key
Secondary actions: Copy new secret, revoke existing key
Data: Name, prefix, permission, creator, created date, last used date
Rules:
- Only owners can create or revoke keys
- The full secret appears once after creation
- Revocation is permanent
- A user cannot revoke a request twice
Required states:
- Loading
- No keys
- Populated list
- Create pending
- Create error
- Secret created
- Revoke confirmation
- Revoke pending
- Revoke error
- Permission denied
Breakpoints: 1440px, 768px, 390px
Must preserve: Existing routes, authentication, analytics, and API contracts

This is the product contract. It tells the AI which information matters, which actions have consequences, and which states change the interface.

Do not add visual adjectives yet. “Clean,” “premium,” and “modern” cannot replace these decisions.

Step 2: Define what done means

Turn the contract into observable acceptance checks.

For the API-key page:

• The existing keys and their permission levels can be scanned.
• Owners can open the create flow from the page header.
• The create action cannot submit without a valid name and permission.
• The new secret is clearly marked as visible once.
• Copy feedback is announced and does not replace the secret.
• Revocation names the affected key and explains that the action is permanent.
• Non-owners can understand why management actions are unavailable.
• Loading, empty, error, and pending states do not move the whole page unexpectedly.
• The workflow can be completed with a keyboard.
• The page works at the three target widths.
• The project’s required checks pass.

These checks give the agent a definition of done. They also give you a stable review standard when the first render looks convincing but the workflow is incomplete.

Step 3: Inspect the project before editing

If an application already exists, ask the coding agent to inspect it before creating anything.

Read the project instructions and inspect the target route.
Do not edit yet.

Find:
- the application shell and page frame
- existing button, field, select, table, dialog, notice, and toast components
- design tokens and theme variables
- route and data-loading conventions
- authentication and permission helpers
- existing test and build commands

Map the API-key workflow to reusable project code.
List conflicts, missing information, and components that truly need to be added.

Review the answer. Correct wrong assumptions before implementation.

This step prevents a common failure: the agent builds a second component system because the prompt never told it to find the first one.

Step 4: Choose a reference by behavior

Browse the InterfaceKit library and choose one system with similar product behavior and density.

For API-key management, look for:

• a product application frame
• a settings or resource-list page
• a compact data list or table
• a creation dialog or drawer
• a destructive confirmation
• notices and feedback
• responsive examples

Do not choose a reference only because its brand looks appealing. A visual style can be attractive while its page structure is wrong for the workflow.

Create a small reference map:

One coherent reference is more useful than a folder of disconnected screenshots.

Step 5: Package only the context this page needs

Give the AI enough context to make the right decisions without burying the task.

Use four layers:

1. Product context: user, outcome, data, rules, and required states.
2. Application context: routes, components, tokens, API contracts, and verification commands.
3. Interface context: page frame, workflow block, local components, and foundations from one system.
4. Task context: the exact pass to complete now and what must not change.

For the first pass, the context package might contain:

Product
- api-key-page-contract.md
- api-key-example-data.json

Application
- src/layouts/SettingsLayout.*
- src/components/Button.*
- src/components/Dialog.*
- src/components/FormField.*
- src/styles/tokens.*

InterfaceKit
- application-frame reference
- settings resource-list block
- dialog and notice components
- typography and spacing foundations

Paths are illustrative. Use the real paths in your project.

Do not attach every available reference. Extra context can introduce competing patterns and make it harder to tell which source owns a decision.

Step 6: Plan the workflow before generating UI

Ask the agent to map the interface states and actions:

Using the product contract and selected references, plan the API-key workflow.
Do not edit yet.

Return:
1. Page regions in reading order.
2. Components reused from the application.
3. New components or variants that are necessary.
4. State transitions for create and revoke actions.
5. Responsive behavior at 1440px, 768px, and 390px.
6. Accessibility risks.
7. Verification steps.

Do not add dashboard metrics, activity feeds, charts, or navigation that the
product contract does not require.

A useful plan should explain where each decision came from. If it introduces a section with no product or reference source, remove that section before code exists.

Step 7: Build the page in three passes

Trying to generate UI design with AI in one large task makes review harder. Structural, behavioral, and visual problems become mixed together.

Use three passes.

Pass 1: Page frame and hierarchy

Build the shell, content rail, page header, primary action position, working area, and responsive regions.

Implement only the API-key page frame and static content structure.

Reuse the existing application shell and components.
Follow the supplied InterfaceKit content rail, page-header alignment,
working-area position, and density.

Use realistic API-key content.
Do not connect mutations or tune decorative details yet.

Render at 1440px, 768px, and 390px.
Report overflow, hierarchy, or component-reuse problems.

Review whether the page’s purpose, information, and main action are clear without relying on color or polish.

Pass 2: Workflow and states

Connect the real data and behavior.

Implement the API-key workflow using the existing data and permission patterns.

Add loading, no-keys, populated, create-pending, create-error,
secret-created, revoke-confirmation, revoke-pending, revoke-error,
and permission-denied states.

The full secret must appear only in the created state.
Name the key in destructive confirmation.
Preserve focus when dialogs open and close.
Make every state reachable for review.

Do not add new visual foundations.

Check the state transitions in the running app. Reading the code is not enough.

Pass 3: Foundations and polish

Apply the selected visual system after the workflow is correct.

Apply the supplied InterfaceKit typography, spacing, color roles,
borders, radius, and elevation through the project’s existing token system.

Correct component density and hierarchy against the reference.
Do not add local values when an existing token or variant expresses the role.
Preserve all verified behavior.

Render and compare the page at 1440px, 768px, and 390px.
List the evidence for each correction.

This order stops a polished screenshot from hiding missing behavior.

Step 8: Use real content early

Placeholder content produces false confidence. It is usually short, balanced, and free of difficult cases.

Use content that exercises the layout:

Also test:

• a very long key name
• a missing last-used value
• several permission labels
• enough records to scroll
• an error message with a recovery action
• a user without management permission

Realistic content helps the AI choose useful widths, wrapping behavior, labels, and hierarchy. It is part of the design input.

Step 9: Make every state reachable

A required state is not verified if nobody can display it.

Use the project’s existing fixture, story, preview, test-data, or development-state approach. If the project has no such mechanism, ask the agent to propose the smallest local-only method and keep it out of production behavior.

Create a review matrix:

Record the real route, fixture, or control used for each state. “Implemented in the component” is not enough.

Step 10: Design responsive behavior deliberately

For each region, decide what happens when space changes.

Do not make these choices from screen width alone. Preserve the sequence the user needs to complete the task.

Drag through intermediate widths after checking 1440px, 768px, and 390px. Toolbars and tables often fail between named breakpoints.

Step 11: Review accessibility as behavior

Visual quality does not prove that the interface can be used.

For this workflow, verify:

• the page has one clear heading
• every field has a persistent label
• validation identifies the field and explains recovery
• focus moves into a dialog and returns to the trigger
• destructive confirmation names the key
• pending actions cannot submit twice
• copy and success feedback are announced appropriately
• color is not the only sign of permission or error
• keyboard focus remains visible
• the key list retains meaningful structure for assistive technology

Use the project’s accessibility checks and review the relevant WCAG 2.2 criteria. Automated checks can catch some issues. Complete the main workflow with a keyboard as well.

Step 12: Correct with evidence

“Make it better” asks the AI to guess again.

Use a correction format with four parts:

Observed problem:
At 768px, the create action wraps below the page description and pushes
the key list below the first viewport.

Reference:
The supplied settings header keeps supporting copy to one short line and
places the action beside the title group.

Required change:
Shorten the description at this width and keep the action aligned with
the title group.

Constraints:
Do not change the route, button component, action label, or desktop layout.
Rerender at 768px and 700px.

This turns visual review into a bounded implementation task.

Correct issues in this order:

1. Missing or wrong behavior.
2. Page structure and hierarchy.
3. Responsive failure and overflow.
4. Component misuse.
5. Typography and spacing.
6. Color, borders, radius, shadow, icons, and motion.

Step 13: Save the decisions that should repeat

When the page passes review, consolidate what it introduced:

• token mappings
• canonical component variants
• the settings page frame
• form and dialog behavior
• responsive rules
• state fixtures or previews
• deliberate deviations from the reference

Remove temporary components and duplicate styles created during exploration.

Then apply the same system to one related route, such as webhook management. A second page reveals whether the first task created reusable rules or only one carefully tuned composition.

How to make AI websites look good

AI websites look good when their visual choices reinforce a clear purpose.

Use real content, a page structure suited to the task, one interface system, consistent components, and deliberate responsive behavior. Decoration should support those decisions. It cannot replace them.

For a marketing site, visual expression may carry more weight. For an operational interface, clarity, density, state handling, and trust may matter more than large type or animation. “Good” depends on the audience and outcome.

How to make AI websites look better

If the first result already exists, improve the quality of the review loop:

1. Name the visible problem precisely.
2. Identify the product or reference rule it violates.
3. Request one bounded correction.
4. Preserve behavior that already works.
5. Rerender the affected widths and states.

Do not restart the page every time it feels wrong. Repeated regeneration can trade one set of arbitrary decisions for another.

How to make a beautiful website with AI

Define beauty in terms that can guide a decision.

Examples:

• calm through restrained color and stable layout
• precise through compact type, aligned data, and consistent control sizing
• expressive through deliberate type contrast, artwork, and motion
• trustworthy through clear content, visible status, and careful confirmation

Choose the qualities that fit the product, then connect them to a coherent reference and observable interface rules. Beauty comes from the relationships across the page, not from stacking effects.

How to improve UI using AI

Use AI where it can reduce production and review effort:

• inspect an existing component system
• map a workflow to reusable patterns
• implement repeated states
• generate realistic edge-case content
• compare renders with references
• find inconsistent tokens or duplicate components
• apply focused corrections across routes

Keep product priority, evidence, accessibility judgment, and the decision to ship explicit. Using AI for UI design works best when the team owns those decisions and the agent makes them visible in the implementation.

Final verification

• The product contract names the user, outcome, data, actions, rules, states, and constraints.
• Acceptance checks describe observable behavior.
• Existing components and tokens were inspected before new ones were created.
• One coherent InterfaceKit system owns the visual direction.
• The page was built in structural, behavioral, and visual passes.
• Realistic content and difficult lengths were reviewed.
• Every required state is reachable.
• Desktop, tablet, mobile, and intermediate widths were checked.
• The main workflow works with a keyboard.
• Corrections cite product or reference evidence.
• Project lint, type, test, and build commands pass.
• Reusable decisions were consolidated.
• A second route or workflow tests consistency.

That is how to build UI with AI without asking one prompt to invent the whole product.

Continue with How to prompt AI for UI design for reusable task structures. To understand why weak inputs produce generic results, read Why AI is bad at UI design.

Explore InterfaceKit libraries and give the AI a coherent product system to work from.