How to Make Claude Design Better UIs and Websites
Claude produces better interface designs when you give it references, explicit constraints, and concrete feedback at each step. Here is a practical approach for UI and website work, from the first prompt to a reviewed result.
Updated 4 min read
Claude produces better interface designs when you give it a reference, a written set of constraints, and concrete feedback at each revision step. The quality gap between a first attempt and a polished result is almost entirely in the specificity of what you ask for — and in recording the approved decisions so they do not get re-argued in later sessions.
Keeping approved design decisions and the revision plan in a shared place means the next session picks up the right constraints without you re-explaining them. fenbs stores those decisions outside any chat, so they are available whether you continue in Claude, switch to another tool, or hand the work to a colleague.
Start with a reference, not a description
Describing a design in words gives Claude latitude to interpret. A reference removes most of that latitude. Upload a screenshot of a site you admire and say what specific quality you want Claude to match: the spacing, the typographic hierarchy, the color restraint, the button treatment. One clear reference is more reliable than a detailed description without one.
If you cannot share a specific reference, use a named convention: "use a card layout with 16px gaps and no border radius" gives Claude something concrete to follow rather than inferring what you mean by "clean" or "modern."
Write the constraints before the first prompt
Write down your design constraints before you start: typeface, type scale, color palette (hex codes if you have them), spacing system, breakpoints if responsive, and any accessibility requirements. Paste these at the top of the first prompt, or into a Project instruction if you are using Claude Projects.
Claude treats written constraints as rules and departs from them only when you implicitly override them. A pasted color palette stops Claude from inventing colors. A named typeface prevents it from substituting a different one in a later revision.
Separate the content pass from the design pass
Asking Claude to write the copy and design the interface in one step produces output where the design choices depend on the content choices, and both are locked together. Separate them: finalize what the page says, then use that fixed content in a design prompt. This gives you a stable subject for the design work and makes revision easier.
Give concrete feedback, not vague adjectives
Vague feedback produces vague revisions. "Make it look less cluttered" gives Claude no specific action. "Increase the vertical spacing between sections from 24px to 48px and remove the decorative border on the card component" gives it two exact changes with no room for interpretation.
Work through one layer at a time: layout first, then type, then color. Changing all three at once makes it hard to know which change fixed which problem. It also makes the revision history harder to follow when you want to go back.
Record approved decisions before moving on
When you approve a design decision — the header layout, the button color, the spacing system — write it down before moving to the next element. Oral approvals in a chat disappear into the history. A written decision can be pasted back into any future prompt as a constraint.
This is especially important for recurring work. If the same design language applies across multiple pages or screens, approved decisions are the starting constraints for every new page.
Keep approved design decisions where every session can find them
Add your approved design choices as Decisions in fenbs — the typeface, the color palette, the spacing rules, the approved component treatments. Every connected AI session reads them first, so the next revision starts from the right constraints rather than re-litigating choices you already made. Create a free account and add the first two or three decisions from today's session.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Use a review step before you accept the output
Before accepting a design output, ask Claude to review its own work against the constraints you gave it: "Check this against the spacing rules and the color palette I specified. List anything that does not match." This catches drift from your requirements and makes Claude explain its own decisions before you adopt them.
Then review it yourself in the environment where users will see it: a real browser at typical screen widths, not a screenshot in the chat. Colors render differently, text wraps differently, and interactive states only appear when you test them.
When Claude design output still does not look right
If the output consistently misses the mark despite specific prompts, the gap is usually in the reference material. A screenshot of the exact treatment you want — even from your own earlier work — closes the gap faster than further description. Claude Code can also apply design changes directly to your files, rather than producing HTML for you to copy.
How to do this with fenbs
- Create a free account and add the design project.
- Before the first prompt, write your design constraints — typeface, palette, spacing, breakpoints — as a Decision in fenbs. Label it a standing rule so every session starts from those constraints.
- After each approved design step, add the approved treatment as a new Decision. Include what was approved and what alternatives were rejected.
- Keep the revision plan as a task in fenbs. Each open revision point is a subtask. When a revision is approved, mark it done and note the final value.
- When you hand the work to a developer or a different AI tool, share the fenbs project so they start from the same approved decisions.