Claude Code UI design that fits your product

Claude Code writes interface code quickly, but without direction it reaches for the same safe defaults every time. Three things change the result more than any styling instruction: the decision the screen has to support, the components it must reuse, and a finish line it can check.

Example task used in this guide: reorganize an account settings page that has grown into one long column of forms, so people can find and change a setting in seconds.

Start from the code you have

Before asking for a redesign, have Claude Code read the page, the components it uses, your spacing and color tokens, and where the data comes from. Then agree on what people actually come to the page to do. For settings, it's usually one thing at a time: change a password, turn off an email, find the delete button.

That changes the design question. The problem with the "before" page above isn't that it looks plain. It's that every form is open at once, so nothing can be found by scanning. The fix is structure: group related settings, show each one as a short row with its current value, and open a form only when someone asks for it.

Give CLAUDE.md a few firm rules

CLAUDE.md in your project root is loaded at the start of every Claude Code session. Keep the UI part short and checkable. "Make it modern and clean" gives Claude nothing to verify; "show state in words, not only color" does. A starting point:

## UI work

- Reuse existing components and design tokens. Name the files you'll reuse before editing; don't create new versions of existing components.
- Every screen has one main job. Make that action the most visible thing on the screen; everything else is quieter.
- Design every state: empty, loading, error, long text, many items, small screens.
- Show state in words, not only color ("Overdue", not just a red dot).
- When a layout decision is unclear and UXKIN is connected, look up real references first and say which ones you used.
- Done means: rendered, checked at 390px and 1440px wide, usable by keyboard.

Task details, like "settings need a danger zone", belong in the prompt for that task, not in CLAUDE.md. Before it edits anything, ask Claude to name the files it will reuse. If it plans a brand-new form component when one already exists, stop it there.

Ask one reference question

References are most useful when they answer one specific question. For this task, a good one is: how do well-made apps group settings and show a setting's current value without opening a form? With UXKIN connected, Claude Code can call find_ui_references with "settings screen" and get real flows such as adjusting feed settings or text size, with every screen linked.

Ask it to pick two, say what each does about grouping and row layout, and state which decisions it's adopting. It should take patterns, not someone else's logo, colors or navigation. If nothing relevant comes back, it carries on with your own system; the task never waits on a reference.

Check the rendered result

Code that compiles isn't a finished screen. Have Claude Code run the page and check it the way a person would:

• At a phone width (390px) and a desktop width (1440px).
• Using only the keyboard: can you reach and open every setting?
• Each state: saving, a failed save, a successful change, and an account with nothing to show (no other devices, no notifications).
• That the delete action is clearly separated and asks for confirmation.

Ask for a one-line reason for each change. If a reason doesn't match what you see on screen, that's the thing to fix next.

Set up UXKIN in Claude Code

The quickest way is the setup prompt from the Agent SDK tab: paste it into Claude Code and it does the steps below itself. To do it by hand:

1. Install the no-ui-slop skill

npx skills add https://uxkin.com --skill no-ui-slop -g -a claude-code -y

It installs to ~/.claude/skills/no-ui-slop, where Claude Code picks it up in every project.

2. Connect the UXKIN MCP server

Replace YOUR_UXKIN_TOKEN with the token from your setup prompt. --scope user stores it in your own Claude Code settings, available in all your projects and never in the repository.

claude mcp add --scope user --transport http uxkin https://uxkin.com/mcp --header "Authorization: Bearer YOUR_UXKIN_TOKEN"

Sharing the setup with a team? Commit a .mcp.json that reads each person's token from their own UXKIN_TOKEN environment variable, so no token ever lands in the repo:

{
  "mcpServers": {
    "uxkin": {
      "type": "http",
      "url": "https://uxkin.com/mcp",
      "headers": {
        "Authorization": "Bearer ${UXKIN_TOKEN}"
      }
    }
  }
}

The first time each person runs claude in that project, Claude Code asks whether to use the servers in .mcp.json. Until they approve, claude mcp list shows UXKIN as “Pending approval”.

3. Check it

Run claude mcp list in your terminal, or type /mcp inside a session. You should see uxkin connected with find_ui_references and find_ui_materials. No need for a test search: your next UI task is the test.

A prompt you can use

Adapt it to your own page. It sets the decision, the components, one reference question and a finish line:

Reorganize our account settings page. Right now every form is stacked in one long column and people can't find what they need.

First, list the components and tokens you'll reuse. Then:
- Group settings into a few clear sections (profile, security, notifications, danger zone).
- Show each setting as a short row with its current value and one action. Open the form only when someone chooses to change it.
- Keep destructive actions (delete account) separate and behind a confirmation.

If UXKIN is connected, use find_ui_references for "settings screen" and pick two references. For each, say what it does with grouping and row layout, and which of those decisions you're adopting.

Build it with loading, error and success states. Render it, check it at 390px and 1440px, try it by keyboard, and fix what you find. Explain each change in one line.

Questions