How to make Claude Code better at UI design

To make Claude Code better at UI design, give it persistent frontend rules, a reusable UI workflow, focused product references, and a visual check it can run or inspect.

Claude Code can read a codebase, edit files, and run development commands. It still needs the product and design decisions that are not present in the repository. The quality improves when you make those decisions explicit and ask Claude to verify the rendered result.

This Guide configures Claude Code for repeatable UI work, then uses that setup to build one team invitation workflow.

Before you start

You need:

• Claude Code installed and authenticated
• an existing frontend project
• the project’s normal development, lint, type, test, and build commands
• access to the running application
• one InterfaceKit product reference
• a way to capture or inspect the page at 1440px, 768px, and 390px

Check the installed version:

claude --version

Start Claude Code from the project root so it can discover the correct project instructions:

cd /path/to/your-project
claude

Replace /path/to/your-project with the real project directory.

Claude Code’s official overview describes its terminal, IDE, desktop, and web surfaces. The setup below uses the terminal terminology, but the same project files can guide other Claude Code surfaces.

Step 1: Give Claude a specific UI task

Do not begin with “redesign the app” or “make the UI beautiful.”

Define one user, outcome, workflow, and state set:

Route: /settings/team
User: An organization owner
Outcome: Invite a teammate with the correct role
Primary action: Invite teammate
Data: Name, email, role, invitation status, invited date
Required states:
- Loading members
- No members
- Populated member list
- Invite form open
- Invalid email
- Duplicate invitation
- Sending
- Invitation sent
- Request error
- Permission denied
Breakpoints: 1440px, 768px, 390px
Must preserve: Existing routes, API contracts, analytics, and keyboard behavior

This is the task contract. It prevents Claude from substituting a generic team dashboard for the real workflow.

Step 2: Put durable rules in CLAUDE.md

Claude Code reads project instructions from CLAUDE.md or .claude/CLAUDE.md. Its official memory documentation recommends using these files for facts and rules that should apply across sessions.

Keep the root file short. Include conventions Claude cannot safely infer:

# Frontend

- Reuse components in `src/components` before adding new ones.
- Use tokens from `src/styles/tokens.css`.
- Do not install another UI or icon library without approval.
- Preserve route, data, analytics, and accessibility behavior during visual work.
- Review changed UI at 1440px, 768px, and 390px.
- Make loading, empty, error, success, disabled, and permission states reachable.
- Run `npm run lint`, `npm run test`, and `npm run build` before finishing.
- Report the commands run, results, screenshots reviewed, and remaining gaps.

Replace the paths and commands with the real ones from the project.

If the repository already has AGENTS.md, Claude’s documentation says a project CLAUDE.md can import it:

@AGENTS.md

# Claude Code

- Use plan mode before changing a multi-file frontend workflow.

Do not import a file that does not exist. Do not copy the same rule into several instruction files. Conflicting instructions make the expected behavior harder to understand.

Inside Claude Code, run /context and confirm the intended project file appears under memory files.

Step 3: Scope frontend rules to frontend files

UI rules do not need to fill the context of a backend-only task.

Claude Code supports path-scoped files under .claude/rules/. Create .claude/rules/frontend-ui.md:

---
paths:
  - "src/**/*.{js,jsx,ts,tsx,css}"
  - "app/**/*.{js,jsx,ts,tsx,css}"
---

# Frontend UI

- Build from the page frame toward local components.
- Use real product content before tuning layout.
- Keep one clear primary action for each state.
- Prefer spacing, alignment, and type over unnecessary containers.
- Preserve visible focus and keyboard operation.
- Check long content and intermediate widths.
- Compare the final render with the supplied product reference.

Adjust the path patterns to match the repository.

The root CLAUDE.md should contain rules that always matter. The path-scoped file should contain rules relevant when Claude reads or edits frontend files. The task prompt should contain details that matter only to the current workflow.

Step 4: Create a Claude Code UI design skill

A skill is useful when the same multi-step workflow keeps returning. Claude Code loads a project skill from .claude/skills/<skill-name>/SKILL.md when it is relevant or when you invoke it directly.

Create .claude/skills/ui-implementation/SKILL.md:

---
name: ui-implementation
description: Build or improve product UI using project components, supplied references, responsive renders, and evidence-based corrections.
---

# UI implementation workflow

1. Read the product contract and applicable project instructions.
2. Inspect the route, component system, tokens, and verification commands.
3. Map the supplied InterfaceKit references to existing project code.
4. List missing product decisions before editing.
5. Build the page frame and content hierarchy.
6. Implement the real workflow and required states.
7. Apply foundations through the project token system.
8. Render at 1440px, 768px, and 390px.
9. Compare structure, hierarchy, density, components, states, and styling.
10. Fix concrete differences and rerender.
11. Run the project checks.
12. Report evidence and remaining gaps.

Do not add product sections, component libraries, or visual foundations that
are not supported by the task, repository, or supplied references.

The official Claude Code skills documentation explains the project path and SKILL.md format.

This Claude Code UI design skill is useful because it defines a repeatable process. A skill containing “make it clean, modern, and premium” would still leave Claude to invent the page.

Start a fresh Claude Code session after adding or changing project setup. Ask Claude to list the applicable instructions and skill before implementation.

Step 5: Choose one InterfaceKit system

Browse InterfaceKit and choose a product reference with the right workflow and density.

For team settings, collect:

• application frame
• settings navigation
• page header
• member list or table
• invite form
• role selector
• dialog or drawer
• notices and error feedback
• typography, spacing, color, border, and radius foundations

Create a short reference map:

Do not mix attractive pieces from unrelated systems. Claude can reproduce each local pattern while the final page still lacks a shared visual logic.

Step 6: Give Claude focused files and images

Claude Code supports @ references for files and accepts pasted or dragged images. Its official best practices recommend pointing Claude to specific sources and giving it a check such as a build or screenshot comparison.

Reference the smallest useful set:

Read:
- @CLAUDE.md
- @docs/team-invitation-contract.md
- @src/routes/settings/team.tsx
- @src/components/Button.tsx
- @src/components/Dialog.tsx
- @src/styles/tokens.css

Also inspect the supplied InterfaceKit page-frame, resource-list,
form, dialog, and foundation references.

Paste the relevant reference screenshots into the session. Label each screenshot with its purpose:

Reference A: page frame and header alignment
Reference B: member list density and row actions
Reference C: invitation dialog and validation
Reference D: mobile settings navigation

Do not attach old alternatives “in case they help.” Competing screenshots create competing instructions.

Step 7: Start in plan mode

Use plan mode for a multi-file UI workflow:

claude --permission-mode plan

Then give Claude a bounded inspection task:

Use the ui-implementation skill.

Inspect the team settings route, existing components, tokens, product contract,
and supplied InterfaceKit references. Do not edit.

Return:
1. The current workflow and data path.
2. Components and foundations to reuse.
3. Reference patterns mapped to project code.
4. Missing product decisions.
5. State transitions for invitation.
6. Responsive behavior at 1440px, 768px, and 390px.
7. Accessibility risks.
8. An implementation and verification plan.

Do not add sections that the product contract does not require.

Review the plan before allowing implementation.

Reject vague steps such as “improve styling.” Ask Claude to name the files, components, states, and evidence involved. Correct false assumptions while the work is still a plan.

Step 8: Build in three reviewable passes

Use separate Claude UI design prompts for structure, behavior, and visual foundations.

Pass 1: Frame and hierarchy

Implement only the team settings page frame and static content structure.

Reuse the existing application shell.
Apply the supplied settings navigation, content rail, page-header alignment,
member-list structure, and responsive regions.
Use realistic member and invitation content.

Do not connect the invitation request or tune decorative details yet.
Render at 1440px, 768px, and 390px.
Report hierarchy, overflow, and reuse problems.

The page should communicate its purpose, current members, and primary action before visual polish.

Pass 2: Workflow and states

Implement the invitation workflow through the existing API and permission patterns.

Support loading, no-members, populated, form-open, invalid-email,
duplicate-invitation, sending, invitation-sent, request-error,
and permission-denied states.

Keep each state reachable for review.
Preserve focus when the dialog opens and closes.
Prevent duplicate submission while sending.
Do not introduce new visual foundations.

Interact with each state. Do not accept a checklist saying the states exist without a route, fixture, story, or control that displays them.

Pass 3: Foundations and polish

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

Compare the current renders with the labeled references.
Correct component density, hierarchy, alignment, and responsive behavior.
Preserve the verified workflow.

Rerender at 1440px, 768px, and 390px.
List every correction and its evidence.

Keep this pass focused on the visual system. Do not let a styling request replace working data with static examples.

Step 9: Make the product states reachable

Create a review matrix before declaring the page complete:

Ask Claude to use the project’s existing test-data approach. If none exists, review a proposed local-only mechanism before it adds one.

Step 10: Use screenshots as evidence

Capture the current page and the reference at comparable sizes.

Review in this order:

1. Page frame.
2. Information hierarchy.
3. Working-area position.
4. Content density.
5. Component choice and composition.
6. Responsive behavior.
7. Typography and spacing.
8. Color, borders, radius, shadow, icons, and motion.

Give Claude one correction set at a time:

Compare the current 768px render with Reference A and Reference B.

Observed differences:
1. The member list starts too far below the page header.
2. The invite action wraps onto a separate line at 740px.
3. Rows are too tall, so only four members fit in the first viewport.
4. Role and status have equal emphasis, but role is the important comparison.

Fix these differences without changing the route, data flow,
component APIs, desktop layout, or verified states.

Rerender at 768px and 700px. Report what changed.

“Make it cleaner” gives Claude another open design task. Measurements, relationships, and reference evidence narrow the correction.

Step 11: Verify behavior and code

Ask Claude to run the exact checks recorded in CLAUDE.md.

The final report should include:

• files changed
• components reused
• components or variants added
• states reviewed and how they were reached
• viewport sizes inspected
• screenshots compared
• keyboard workflow result
• lint, type, test, and build commands with results
• deliberate deviations from the reference
• anything that remains unverified

Claude should show command output or other evidence instead of saying the checks passed.

The official Claude Code best-practices guide recommends giving Claude a verification signal it can read and asking it to show evidence. For UI, that signal includes the running workflow and screenshots as well as code checks.

Step 12: Test the system on a second route

Apply the same settings frame, foundations, form controls, notices, and responsive rules to role management or invitation detail.

Ask Claude to report:

• what it reused
• which existing variant needed extension
• which new decision was unavoidable
• whether any page-local styles can now be removed

A strong first page can still be a one-off. A second route shows whether Claude built a product system.

What to do when Claude UI still looks generic

Should you use a Claude UI builder?

A visual builder can be useful for fast concepts. Claude Code is a better fit when the deliverable must live in an existing repository and reuse its components, data, routes, and checks.

If you search for a way to make Claude Code build better UI with a builder, first decide which artifact owns the product. An editable concept and a production implementation can both be useful, but an unclear handoff creates two sources of truth.

Should you copy Claude UI advice from Reddit or GitHub?

Reddit can surface useful complaints and prompt ideas. GitHub can show real CLAUDE.md, rule, skill, component, and verification patterns.

Do not copy either source without checking the context.

For Reddit advice, turn the claim into a testable rule. “Claude uses too many cards” becomes “containers need to communicate a real group, state, or interaction.”

For GitHub examples, inspect the repository structure, dependencies, maintenance status, and license. A good Claude Code UI design prompt from another project may refer to components and commands that do not exist in yours.

The best reusable material explains why a decision belongs in the product. It does not only show an attractive screenshot.

Direct answers about Claude for UI design

How do I make Claude Code build better UI design?

Give Claude one product workflow, short project instructions, path-scoped frontend rules, a UI implementation skill, one InterfaceKit system, reachable states, screenshots, and exact verification commands.

Is Claude Code good for UI design?

Claude Code is useful for implementing UI in a real codebase because it can inspect files, edit components, and run development commands. It still needs product context, visual references, and human review for decisions the code does not contain.

Does a Claude Code UI design skill help?

Yes, when the skill defines an inspect, plan, implement, render, compare, correct, and verify workflow. A list of style adjectives does not provide the same value.

Can a Claude Code UI design agent work on its own?

It can complete bounded implementation work when the product contract, permissions, context, and acceptance checks are clear. Keep a person responsible for product priority, accessibility judgment, and the decision to ship.

Can Claude generate UI?

Claude can generate UI code and revise it from files, prompts, and images. The output becomes more dependable when it applies an existing interface system and verifies the running result.

Claude Code UI checklist

• Claude Code starts from the project root.
• The task defines one user, outcome, workflow, and state set.
• CLAUDE.md contains short, durable, project-specific rules.
• Frontend-only rules are scoped under .claude/rules/.
• The UI skill defines a repeatable workflow.
• /context shows the intended project instructions.
• One InterfaceKit system owns the visual direction.
• Reference files and screenshots are focused and labeled.
• Claude inspects and plans before a multi-file edit.
• Structure, behavior, and styling are separate passes.
• Every product state is reachable.
• Desktop, tablet, mobile, and intermediate widths are reviewed.
• Corrections cite visible evidence.
• Keyboard behavior and accessibility are checked.
• Project commands run and their output is reported.
• A second route tests whether the system is reusable.

Continue with How to prompt AI for UI design, or compare the same workflow in Codex, Gemini, Kimi, or Cursor.

Explore InterfaceKit kits before starting the next Claude Code UI task.