Claude Code prompts for UI that produce better screens

The best Claude Code prompts for UI name the exact screen and state, give the real content, point at the components and tokens to reuse, say what must not change, and ask for something you can look at before the code ships. “Make the dashboard look better” leaves every decision to the agent. “On /settings, when there are no teammates, show a card that explains why and a primary Invite button using our Button component” leaves almost none.

This guide gives a structure for UI prompts, prompts you can copy, and a few habits that keep results consistent from one session to the next.

Why vague UI prompts give generic screens

A coding agent fills every gap in a prompt with a guess. For UI work the gaps are large: spacing, hierarchy, copy, which component to reuse, what happens with long text or no data. When the prompt says little, the agent falls back on common patterns: centered cards, placeholder text, a new button style next to the one you already have.

Three gaps cause most of the trouble:

• No location. “The button” can match a dozen places. The agent picks one, or changes a shared component and affects every screen.
• No states. You ask for a list and get the filled list. The empty, loading and error states stay whatever the code already did, often nothing.
• No boundaries. Without “only this screen” or “do not change the API”, the agent may refactor more than you wanted to review.

The five parts of a good UI prompt

Part	Question it answers	Example
Where	Which screen, route, component, state?	“The invoice list at /invoices, empty state”
What	What should the user see or be able to do?	“A short explanation and a Create invoice button”
Content	What are the real texts and data?	“Title: No invoices yet. Button: Create invoice”
Constraints	What must it reuse or respect?	“Use EmptyState and the spacing variables, no new colors”
Check	How will you judge the result?	“Tell me how to see it at 1440 and at 390 px wide”

Put together:

On /invoices, when the user has no invoices, the page is blank.
Show an empty state instead: title "No invoices yet", one sentence
"Invoices you create or import appear here.", and a primary
"Create invoice" button that opens the existing create dialog.
Use the EmptyState component in src/components/EmptyState.tsx and
the existing spacing variables. Do not change the filled list or
the API. When done, list the files you changed and tell me how to
reach this state locally.

It is longer than a one-line request, but each sentence removes a guess you would otherwise correct afterwards.

Point at the code, not only at the idea

Claude Code reads your repository, so name files instead of describing them. An @ reference such as @src/components/Button.tsx puts the file in the conversation. Naming the component you want reused is the simplest way to stop the agent from creating a near duplicate.

Rules you repeat in every session belong in a project CLAUDE.md (at ./CLAUDE.md or ./.claude/CLAUDE.md), which Claude Code loads at the start of every session. The Claude Code memory documentation recommends keeping it short and concrete enough to verify:

## UI conventions
- Colors, spacing and radii come from src/styles/tokens.css. Never hardcode hex values.
- Buttons: use <Button variant="primary|secondary|ghost">, never a raw <button> with classes.
- Every list screen has empty, loading and error states.
- Check every change at 390px wide.

“Use the Button component” is a rule the agent can follow and you can check. “Keep the design consistent” is neither. If your tokens are scattered, design tokens an AI coding agent can follow explains how to gather them.

Ask for every state, not only the happy path

Most defects in generated screens live in states nobody asked for. Name them in the prompt:

• empty: no data yet, or a search with no result;
• loading, and what shows while it waits;
• error, with the real message and a way out;
• long content: a 40-character name, 200 rows, a price with many digits;
• permissions: what a viewer sees compared with an admin.

A sentence as short as “Also handle the empty, loading and error states, and tell me how to see each one” changes the result more than any adjective. The UI states checklist gives a fuller list to paste into a prompt or a CLAUDE.md.

Show a picture when words are not enough

For layout and visual style, an image often beats a paragraph. Claude Code accepts images: drag and drop one into the window, paste it with Ctrl+V (Alt+V on Windows), or give its path. Then say what to take from it:

Here is a screenshot of a pricing table we like. Match its layout
(three columns, the middle one highlighted) but keep our fonts,
colors and Button component. Do not copy its texts.

Without the last two sentences, the agent may reproduce the reference too literally, fonts and copy included.

Plan first for changes that touch shared UI

When a change affects a shared component, a layout used by many pages or the design tokens, ask for a plan before any edit. In plan mode Claude Code reads the code and proposes changes without editing your source. Press Shift+Tab to cycle to it, or prefix a single prompt with /plan:

/plan I want the sidebar to collapse to icons below 1024px.
List the components you would change, the screens affected,
and anything that could break on mobile.

You approve the plan, or keep planning and say what to change. Reading a ten-line plan is faster than reviewing a diff that went in the wrong direction. The permission modes documentation lists the approval options.

Iterate with one change per message

Once a first version exists, the best follow-up prompts are small and specific:

• “Make the Save button full width on mobile only.”
• “Move the error message above the form, keep its text.”
• “The card padding is too tight: use the next spacing step up.”
• “Propose three variants of this header and let me choose before you code.”

Refer to elements by the names they have in your code or on screen (“the Save button in the footer”), not by position, so the request still makes sense after the layout moves. One change per message makes each result easy to judge, and easy to undo when it is wrong. When a message holds five requests, the agent is more likely to miss one. How to write a change request for an AI coding agent goes deeper on scope and on defining done.

Prompting against screens instead of code

The hardest part of a UI prompt is naming the place precisely. agentappbuilder turns that part into a URL: your agent draws each state of each screen as a frame on a canvas, or captures your running app so you can import the screens into the prototype, and every frame has its own address. You paste it with the change:

https://app.agentappbuilder.com/f/<token> Make the Save button full width and show the error message above the form.

Your agent adds a new version of that frame, you compare it with the previous one side by side, and it codes the version you chose only when you say “apply”. You can also ask for 2 to 4 variants and pick one on the canvas, or change a color or a padding yourself in the frame. Working with your agent lists the prompts, and the canvas shows versions, compare and editing.

With or without a canvas, the rule is the same: say where, say what, give the real content, set the limits, and ask to see the result before it ships.