How to make Cursor better at UI design

To make Cursor better at UI design, define the product workflow first. Store stable frontend guidance in a scoped Project Rule, package the repeatable process as an Agent Skill, select one coherent InterfaceKit system, and review the running application with Cursor’s browser and Design Mode.

Cursor can inspect a repository, edit files, run commands, control a browser, and apply feedback to selected page elements. Those tools make the correction loop faster. They do not tell Cursor who the user is, which actions matter, or which states the product must support. You still need a clear product contract and observable checks.

This Cursor UI design tutorial builds a notification-routing page for a software workspace. The workflow uses current Cursor features and terminology from the official documentation. Cursor 3.11.25 and Cursor Agent are installed in our environment, but we did not run this full editor, browser, and Design Mode workflow end to end. Verify it in your own project before adopting it as a team standard.

What you will build

The finished page lets a workspace admin:

1. See the notification rules that affect the team.
2. Filter rules by event, channel, and status.
3. Open a rule without losing list context.
4. Create or edit a rule.
5. Send a test notification before saving.
6. Disable a rule with clear confirmation.

The page must support loading, no rules, no filter results, request error, details open, invalid form, test pending, test success, test error, save pending, save success, disable confirmation, and permission denied.

This is a useful Cursor AI UI design test because it combines a dense list, a form, several action states, permissions, and responsive behavior. A styled dashboard shell is not enough.

Before you start

You need:

• the current Cursor editor
• a frontend repository that runs locally
• the route and data flow for the target workflow
• the project’s development, lint, type, test, and build commands
• realistic fixtures for every required state
• one relevant system from the InterfaceKit library
• permission to use Cursor’s browser tools in the workspace

Open the repository root in Cursor. Confirm that the application starts and that you can reach the target route before asking Agent to change it.

If you use Cursor Agent from the terminal, record its version:

cursor-agent --version

The terminal agent is useful for repository work, but the later Design Mode steps require the Cursor editor and its running browser view.

Step 1: Write the product contract

Do not start with “design a modern notification settings page.” Write the decisions the interface must express:

Route: /settings/notifications
User: A workspace admin responsible for team notifications
Outcome: Find a notification rule, verify its destination, and update it safely
Primary action: Save rule
Secondary actions: Send test, disable rule
Data:
- Rule name
- Event
- Channel
- Destination
- Status
- Last triggered time
- Last delivery result
Rules:
- Only admins can create, edit, or disable rules
- A rule needs one event, one channel, and one valid destination
- A test must use the unsaved form values
- Saving and testing cannot submit twice while pending
- Disabling a rule requires confirmation
Required states:
- Loading
- No rules
- Populated list
- No filter results
- Request error
- Rule open
- Invalid form
- Test pending
- Test success
- Test error
- Save pending
- Save success
- Save error
- Disable confirmation
- Permission denied
Breakpoints: 1440px, 768px, 390px
Must preserve: Existing routes, API contracts, analytics, and keyboard behavior

The contract gives Cursor a product problem. Without it, Agent may invent summary cards, charts, or settings that have no role in the workflow.

Step 2: Define done before changing code

Turn the contract into checks:

• Rule name, event, channel, destination, status, and last result are easy to scan.
• Filters stay visually connected to the list they change.
• Opening a rule preserves enough list context to continue working.
• The form explains validation beside the field that needs attention.
• A test clearly uses the current unsaved values.
• Pending test and save actions cannot submit twice.
• Disable confirmation names the rule and consequence.
• Read-only users can inspect rules and understand why editing is unavailable.
• Loading, empty, no-results, error, pending, success, and permission states are reachable.
• Long rule names and destinations do not break the layout.
• The workflow works with a keyboard.
• Information priority survives all three target widths.
• Project checks pass.

These checks define the result. “Clean UI” does not.

Step 3: Add scoped Cursor UI design rules

Cursor Project Rules live under .cursor/rules/ and use .mdc files. Rules can apply always, attach to matching files, or load when their description matches the task. Cursor’s official Rules documentation explains the activation options and also supports root and nested AGENTS.md files.

Create .cursor/rules/frontend-ui.mdc:

---
globs: "src/**/*.{tsx,jsx,css,scss}"
alwaysApply: false
---

- Inspect existing routes, components, tokens, and fixtures before editing.
- Use the current styling system and design tokens.
- Do not add a UI, CSS, or icon library without approval.
- Preserve route, data, analytics, and accessibility behavior.
- Build structure and workflow before surface polish.
- Make loading, empty, error, success, disabled, and permission states reachable.
- Review changed UI at 1440px, 768px, and 390px.
- Keep temporary review screenshots out of version control.
- Run the project lint, type, test, and build commands before finishing.
- Report checks, renders reviewed, deliberate deviations, and remaining gaps.

Change the glob and commands to match the project.

This rule is scoped to frontend files. Backend tasks do not need UI review instructions in every prompt. If the repository already uses AGENTS.md across several tools, keep the shared rules there and use the Cursor rule only for Cursor-specific behavior.

Do not put the notification-page contract in the rule. A durable rule explains how UI work is done. A task prompt explains what this page must do.

Step 4: Create a Cursor UI design skill

Use an Agent Skill for the workflow you want Cursor to repeat across features. Cursor automatically discovers skills from .cursor/skills/ and .agents/skills/.

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

---
name: ui-implementation
description: Build or improve product UI with project components, focused references, reachable states, responsive renders, and evidence-based correction.
---

# UI implementation

1. Read the product contract and applicable project rules.
2. Inspect the route, components, tokens, data conventions, and checks.
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 workflow and every required state.
7. Apply foundations through the existing styling system.
8. Run the application and review 1440px, 768px, and 390px.
9. Compare structure, hierarchy, density, components, states, and styling.
10. Fix concrete differences and rerender.
11. Run project checks and review the diff.
12. Report evidence, deliberate deviations, and remaining gaps.

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

Cursor’s Agent Skills documentation defines the SKILL.md format and the supported project paths. Cursor can select a skill when its description matches the task. You can also mention the skill by name when you want to make its use explicit.

A Cursor UI design skill should own a repeatable process. It should not be a long list of style words such as “minimal,” “premium,” and “futuristic.”

Step 5: Select one InterfaceKit system

Choose an InterfaceKit system with settings, rule management, or operations patterns close to the feature.

Collect only the references needed for this workflow:

Use one coherent system. Combining unrelated screenshots can give Cursor conflicting rules for spacing, density, component shape, and typography.

Create a short reference map before implementation:

Settings frame -> existing SettingsLayout
Filter toolbar -> InterfaceKit filter block + existing SearchField
Rule list -> InterfaceKit resource list + existing StatusBadge
Rule details -> InterfaceKit side panel + existing FormField
Disable flow -> existing ConfirmDialog
Feedback -> existing Toast and InlineNotice

This tells Cursor where to reuse project code and where the external reference supplies missing layout logic.

Step 6: Start in Plan Mode

Cursor’s Plan Mode researches the codebase, asks clarifying questions, and produces a reviewable plan before writing code.

Select Plan Mode from the Agent mode picker and use this prompt:

Use the ui-implementation skill and applicable frontend rules.

Read the notification-routing product contract. Inspect the current settings
route, data flow, shared components, tokens, fixtures, and project checks.
Review the supplied InterfaceKit references.

Do not write code yet.

Map each product requirement to current code and a selected reference.
List missing decisions, reusable components, required fixtures, affected tests,
and commands needed to run and verify the route.

Return a four-pass plan:
1. Structure
2. Behavior
3. Reachable states
4. Visual correction

Stop for review after each pass.

Review and edit the plan before building. Reject or revise a plan that:

• adds sections not found in the product contract
• creates new primitives before inspecting existing ones
• changes data behavior during a visual task without a reason
• treats the populated desktop state as the whole feature
• postpones accessibility and responsive behavior until the end
• has no rendered browser checks

If the result later drifts far from the target, Cursor’s documentation recommends returning to the plan, refining it, and building again instead of stacking vague correction prompts.

Step 7: Build the UI in four passes

Pass 1: Structure

Build the settings frame, page header, filter region, rule list, details region, and responsive order.

Review:

• heading and action priority
• grouping and reading order
• list density
• the relationship between list and details
• what collapses or moves at tablet and mobile widths

Keep this pass runnable. Do not spend it tuning minor color values.

Pass 2: Behavior

Connect the real list, filters, form, test action, save action, disable flow, and permissions.

Review:

• which values are editable
• what the test action sends
• what happens while requests are pending
• how validation and server errors differ
• where focus moves after opening, saving, and closing
• whether analytics and API contracts remain intact

Pass 3: Reachable states

Use the project’s normal fixture, story, query, or test mechanism to make each state available on demand.

If a state cannot be opened on demand, the browser review is incomplete.

Pass 4: Visual correction

Apply the selected InterfaceKit foundations through the current token and CSS system.

Compare in this order:

1. Page structure
2. Information hierarchy
3. Density
4. Component selection
5. Typography
6. Spacing
7. Color, borders, radius, and icons

This keeps surface polish from hiding a weak workflow.

Step 8: Use Cursor’s browser for UI testing

Can Cursor do UI testing? Yes. Cursor Agent’s built-in browser can open pages, click and type, scroll, capture screenshots, read console output, and inspect network activity. The documentation also describes accessibility checks and visual regression workflows.

Ask Agent to start the app with the project’s real command, then open the local route:

Start the application and open /settings/notifications in Cursor's browser.

Test the normal workflow with a keyboard:
1. Filter rules.
2. Open one rule.
3. Change the destination.
4. Send a test.
5. Save the rule.
6. Open and cancel disable confirmation.

Check browser console errors and failed network requests.
Do not submit destructive or production actions.
Report failures before editing.

Browser actions require approval by default. Keep that setting for unfamiliar code and sites. Do not give Agent unattended browser access to production accounts or sensitive data.

Run a repeated viewport and state matrix:

Browser automation can prove that controls work and reveal console or network failures. It cannot decide whether the page hierarchy is right without the product contract and references.

Step 9: Correct the page with Design Mode

Cursor’s Design Mode lets you select an element in the running app and send its page and code context to Agent. It also supports multi-select and drawing over a frozen viewport.

Use Design Mode after the workflow exists:

1. Select the rule list and details panel together.
2. Ask Cursor to preserve list context when details open.
3. Draw around a crowded mobile action region.
4. Name the exact reference pattern Cursor should apply.
5. State the behavior that must remain unchanged.

Example:

At 390px, the selected rule name, destination, and status compete for one row.

Use the supplied compact resource-row pattern:
- Keep rule name and status visible.
- Put destination on a second line.
- Move test and disable into the existing overflow menu.
- Keep edit as the primary action.
- Preserve keyboard access and current handlers.

Do not create a separate mobile-only rule component.
Rerender at 390px and 768px after the change.

For a relationship problem, select both elements. For a regional spacing problem, draw around the region. Element selection makes the feedback more precise, but the prompt still needs the product reason and acceptance check.

Step 10: Make Cursor better at UI design with CSS

If the structure and behavior are correct but the page still looks generic, give Cursor a constrained CSS correction task:

Review the selected page against the supplied InterfaceKit foundations.

Use existing tokens and styles. Do not add a CSS framework or hard-coded
parallel palette.

Check:
- content width and region gaps
- heading and body type relationships
- row height and control density
- border contrast
- radius consistency
- focus visibility
- hover, disabled, error, and success states
- wrapping and overflow at 390px

List the mismatches before editing. Fix confirmed mismatches, then rerender the
same data and states at 1440px, 768px, and 390px.

Do not ask Cursor to “improve the CSS” across the whole page. That request often produces local values, extra effects, and one-off overrides. Ask it to trace each correction back to an existing token, component, or selected reference.

If Agent changes a shared token, review every component that consumes it. A small CSS edit can have a larger product effect than the changed file suggests.

Step 11: Review code separately from the rendered UI

Use Cursor’s Agent Review on the local changes after the visual passes. A code review can catch regressions, unsafe logic, duplicated components, and missing tests.

Keep the two reviews separate:

• Browser and Design Mode review the running product.
• Agent Review examines the code change.
• Project tests, type checks, and builds verify the repository.

A clean diff does not prove the UI works. A good screenshot does not prove the implementation is safe.

Which Cursor model is best for UI design?

There is no permanent best Cursor model for UI design. Cursor supports several models and changes the available set over time. Its models and pricing documentation also shows that model choice affects usage and cost.

Test the current models with the same small UI task:

Use Auto when you want Cursor to route the task, or select a model when you need a reproducible comparison. Record the Cursor version, model, prompt, files, data, and acceptance checks. “Best Cursor model for UI design” only means something when the test is repeatable.

How to customize Cursor UI

“Customize Cursor UI” can mean two different things.

If you mean the product you are building, use Project Rules, Agent Skills, Design Mode, selected references, and browser checks as described in this Guide.

If you mean the Cursor editor itself, use Cursor and VS Code settings, themes, layout controls, and keybindings. Project UI rules do not change the editor interface. That is a separate task from designing your application.

Can Cursor design UI?

Cursor can design and refine UI through code. It works best when the repository contains the product facts and design system it needs, and when the result can be reviewed in a running browser.

A complete Cursor UI design workflow is:

1. Define one user outcome.
2. List content, actions, rules, states, and breakpoints.
3. Load scoped rules and one relevant skill.
4. Map InterfaceKit references to existing code.
5. Review a plan.
6. Build structure, behavior, states, and styling separately.
7. Test the workflow in Cursor’s browser.
8. Correct spatial issues with Design Mode.
9. Review the code and run project checks.

That is how to build UI with Cursor without reducing the task to one large Cursor UI design prompt.

Test the system on a second route

Apply the same frame, filters, rule status, feedback, and foundations to /settings/notification-deliveries.

The second page should show recent delivery attempts and their results. Review any new component or token introduced to make it fit. If Cursor produces a different shell, spacing scale, or status language, the first page did not create a reusable system.

Cursor UI verification checklist

• The exact Cursor version and model are recorded
• One user outcome and product contract are defined
• The frontend Project Rule is scoped to the right files
• Cursor discovers the ui-implementation skill
• One coherent InterfaceKit system is mapped to existing code
• The plan was reviewed before implementation
• Structure, behavior, states, and styling were separate passes
• Every required state can be opened on demand
• Cursor’s browser tested the real workflow
• Design Mode corrections name evidence and preserve behavior
• 1440px, 768px, and 390px renders were reviewed
• Keyboard behavior and focus visibility were checked
• Agent Review and project checks pass
• Deliberate deviations and remaining gaps are reported

Use How to prompt AI for UI design when the product contract still needs work. Use How to audit and fix AI-generated UI when Cursor has already produced a page that needs repair.

For another coding tool, follow the comparable workflow for Claude, Codex, Gemini, or Kimi.