Design
Cursor for Designers Tutorial #2: Edit UI Safely in an Existing Product Repo
Most Cursor tutorials for designers stop at greenfield prototypes.
Real product designers don’t.
They inherit codebases, work inside existing systems, and need to make UI changes safely without breaking functionality. That’s where many designers freeze—and it’s exactly where Cursor can become useful if you use it with the right guardrails.
This tutorial is Part 2 of a 3-part Cursor for Designers series:
- Part 1: Greenfield / vibe-coding UI workflows
- Part 2: Working inside an existing product repo (you are here)
- Part 3: Figma → production code translation
You can start here even if you haven’t read the others. This guide is fully standalone.
In this tutorial, you’ll learn how to use Cursor to clone a repo, run local UI, map the project structure, find the right components, and ship a real design change—without requiring terminal or Git-command fluency upfront.
This Cursor tutorial is for you if:
- Your team gives you a repo link and asks for UI changes
- You need to tweak the existing product UI safely
- You want to use Cursor’s Visual Editor on a real app
- You're nervous about breaking functionality
Start with Part 1 first if:
- You've never run a local app before
- You've never used Cursor's built-in preview or Visual Editor
- You want greenfield confidence before touching an inherited codebase
If your workflow starts in Figma and you mainly need implementation accuracy, you can also skip ahead to Part 3.
What you'll learn in Part 2
In this tutorial, you’ll learn how to:
- Ask Cursor to clone a repo and open it
- Ask Cursor to install dependencies and run local dev
- Open the app in Cursor’s built-in preview
- Map the project structure in designer-friendly language
- Find the exact component behind visible UI
- Make safe edits with Visual Editor + constrained prompts
- Ask Cursor to create a branch, commit, and draft a PR
- Run a designer QA pass before shipping
And by the end, you’ll have a repeatable workflow for making real UI changes in real codebases.
What you'll ship by the end
By the end of this tutorial, you’ll have:
- A real repo running locally inside Cursor
- A meaningful UI improvement inside that codebase
- A saved, reviewable change
- A PR-ready summary of what changed and what stayed intact
Demo repo for this tutorial
To keep this designer-friendly, use a repo that is:
- One app
- Npm-friendly
- Visually rich enough to practice real UI changes
Recommended demo repo
next-shadcn-admin-dashboard
https://github.com/arhamkhnz/next-shadcn-admin-dashboard
If you’re using your own team’s repo instead, the workflow is the same. For the purposes of this tutorial, we’ll use the repo above. It’s a great place to start.
Workflow #2 — Working in an existing product repo with Cursor
This is where designers usually freeze. Lets fix that.
Step 1 — Prompt Cursor to clone the repo and open it
Create a new workspace in Cursor. Then in the agent pane, prompt:
“Clone this repo into my workspace and open it: https://github.com/arhamkhnz/next-shadcn-admin-dashboard”
If you want extra guidance:
“Clone this repo for me and explain what you’re doing at each step in designer-friendly language.”
If the repo doesn’t open automatically, follow Cursor’s on-screen instructions to do so, or run this command:
- Cmd+Shift+P → “Shell Command: Install 'cursor' command in PATH”.
✅ Checkpoint: The repo is present in your workspace and open in Cursor.
Step 2 — Prompt Cursor to install dependencies and start local dev
Prompt:
“Install dependencies and get the local dev server running for this project. Use Cursor’s built-in workflow and tell me the localhost URL when it’s ready.”
If something errors:
“Fix this step by step. Assume I’m a designer. Do the setup work for me and explain the issue simply.”
✅ Checkpoint: Cursor gives you a localhost URL (often http://localhost:3000).
Step 3 — Open localhost in Cursor's built-in preview
Stay inside Cursor. You app probably automatically opened to the right of the Agent window. If it didn’t, do this:
- Press** Ctrl+Shift+P** to open the Command Palette
- Type Simple Browser: Show and run it.
- Enter the localhost url you requested in Step 3. For our demo app, this is
http://localhost:3000** .**
✅ Checkpoint: You can see the running app inside Cursor.
This is a major milestone: you can run and view local UI without leaving the editor.
Step 4 — Ask Cursor to explain the repo structure like a designer
Prompt:
“Explain this project structure like I’m a product designer. Where are pages/routes defined? Where are UI components? Where are shared layout wrappers? Where are styles controlled?”
You’re not trying to memorize every folder.
You’re building a mental map:
- Where screens live
- Where shared UI lives
- Where layout patterns come from
- Where styling conventions are coming from
✅ Checkpoint: You can answer:
- Where pages live
- Where shared components live
- Where styles/patterns are defined
Step 5 — Open the CSS Inspector
Look for the three icons in the menu of the live preview pane. Click the sidebar icon to open the CSS inspector. You can also press the cursor icon beside it and then select any UI element.
✅ Checkpoint: You can edit the UI and see the result live in Cursor preview.
Step 6 — Make one real UI improvement (AI + Visual Editor hybrid)
Pick one improvement to practice safely:
- Increase information density slightly
- Reduce visual noise
- Improve typography hierarchy
- Tighten spacing rhythm across cards
- Make the screen feel more enterprise
Example prompt:
“Make this dashboard section feel more enterprise. Increase density slightly. Improve typography hierarchy. Reduce visual noise. Keep logic intact. Minimal diff.”
Then use Visual Editor for the final details:
- Spacing rhythm
- Alignment
- Card padding consistency
- Label vs metric emphasis
✅ Checkpoint: The UI looks better and behaves the same.
Step 7 — Ask Cursor to create a branch (no Git commands required)
Prompt:
“Create a new branch for this change called
dashboard-density-pass.”
Or:
“Create a branch for a dashboard UI refinement. Choose a clean branch name and tell me what it is.”
This gives you a safe workspace without requiring command syntax.
✅ Checkpoint: Cursor confirms the branch is created.
Step 8 — Run a designer QA pass before shipping
Prompt:
“Give me a quick test checklist for this change, focused on what a designer should verify before shipping.”
Then check manually in Cursor preview:
- Nav links
- Buttons
- Layout at narrower widths
- Obvious visual regressions
If something breaks:
“Something changed visually but now X is broken. Find the minimal fix and keep the design improvements.”
✅ Checkpoint: Your change is visually improved and functionally stable.
Step 9 — Ask Cursor to commit the change
Prompt:
“Create a commit for these changes with a clear message focused on UI refinement.”
If you want a PR summary starter too:
“Create the commit and give me a short summary I can use in a PR description.”
✅ Checkpoint: You have a saved, reviewable change.
Step 10 — Ask Cursor to draft the PR description
Prompt:
“Draft a PR description for this change with: what changed, what stayed intact, and what reviewers should look at.”
Good PR descriptions should include:
- What changed (2–4 bullets)
- What stayed intact (for example: logic/routes/handlers unchanged)
- What to review (specific screens/components)
- Before/after screenshots (you add these)
✅ Checkpoint: You have a handoff-ready PR description.
This is what makes engineers trust designer-led changes.
Common failures in existing repo workflows (and what to say)
If Cursor rewrote the entire file
“Undo the refactor. Restore the original structure. Apply only minimal visual changes.”
If Cursor changed logic when you only asked for UI updates
“Keep logic intact. Restore handlers, links, routing, and forms. Make only the visual changes needed.”
If Cursor invented new styling patterns instead of reusing the system
“Reuse existing components, tokens, and styling patterns already used in this repo. Don’t introduce new conventions.”
If you can’t find the component that renders a section
“Show me exactly which file(s) render this screen/section and highlight the main component responsible.”
If local dev won’t start
“Explain this error simply. Fix it step by step. Do the setup work for me where possible and tell me what changed.”
If desktop looks right but mobile broke
“Identify which responsive classes are affecting this layout. Propose the minimal fix that preserves desktop and improves mobile.”
What you just learned in Part 2
You now know how to:
- Go from repo link → running local UI
- Map a codebase like a designer
- Find the exact UI you want to edit
- Make safe UI changes with Cursor + Visual Editor
- Save a reviewable change
- Prepare a clean PR description
That is real product work.
You don’t need to be a full-time engineer to contribute meaningfully in a production codebase—but you do need a repeatable workflow, good guardrails, and the discipline to protect logic while improving UI.
What to read next in the series
Go to Part 1 if…
- You want a simpler way to practice Cursor’s chat + Visual Editor loop
- You want greenfield confidence first
- You want to build speed without inherited system complexity
Go to Part 3 if…
- Your day-to-day starts in Figma
- You need a production-safe workflow for translating design specs/screenshots into real UI
- Your main bottleneck is handoff drift
Cursor for designers series
- Part 1: Greenfield / Vibe-Coding UI Workflows
- Part 2: Working Inside an Existing Product Repo (you are here)
- Part 3: Figma → Production Code Translation
Where Cursor starts to break down for teams
Cursor is strong for helping designers operate inside real codebases.
But once multiple people need to collaborate on frontend changes—designers, PMs, engineers, stakeholders—the workflow can start to feel cramped because the center of gravity is still the codebase and diff review.
That usually shows up as:
- Screenshot-heavy review loops
- Extra translation work for non-dev reviewers
- More tooling overhead on designers than teams expected
If your team is hitting those limits, a visual-first development platform like Builder.io can be a better fit. Builder is designed around visual collaboration and production UI workflows, which makes it easier for non-engineering collaborators to review and participate without living in repo-first tooling.
You’ll see the strongest case for this in Part 3, where Figma-to-code and design-system alignment become the main job.
FAQ: Coding in Cursor for Designers
Can a designer make UI changes in a production codebase without being a developer?
Yes — with the right workflow. The key is using constrained prompts ("keep logic intact," "minimal diff"), working in a separate branch, and reviewing changes in Cursor's built-in preview before committing. You don't need to write code from scratch. You need to direct AI safely and verify what it does.
How do I find which component controls a specific part of the UI in Cursor?
Ask Cursor directly: "Show me exactly which file renders this screen and highlight the main component responsible." Cursor can trace visible UI back to the source file, which removes one of the biggest blockers designers face in unfamiliar codebases.
How do I clone a GitHub repo in Cursor without using the terminal?
Create a new workspace in Cursor, then prompt the agent: "Clone this repo into my workspace and open it: [repo URL]." Cursor handles the clone through its agent workflow. If the folder doesn't open automatically, use Cmd+Shift+P → "Shell Command: Install 'cursor' command in PATH" to finish the setup.
What prompts should designers use in Cursor to avoid breaking functionality?
Three prompts do most of the work: "Keep logic intact" scopes the change to UI only. "Minimal diff" prevents Cursor from over-refactoring. "Reuse existing components, tokens, and styling patterns already in this repo" stops it from inventing new conventions. Use all three together on any UI change in a real codebase.
How do I create a Git branch in Cursor without knowing Git commands?
Prompt Cursor: "Create a new branch for this change called [branch-name]." Cursor creates the branch through its agent. You get the safety of a proper branch workflow without needing command syntax. For team work, make sure you understand what branches are for — Cursor can execute them, but you need to understand why they matter.
What should a designer include in a PR description for a UI change?
Prompt Cursor: "Draft a PR description for this change with: what changed, what stayed intact, and what reviewers should look at." A good PR description covers what changed (2–4 bullets), what was explicitly left untouched (logic, routes, handlers), which screens or components to review, and before/after screenshots you add manually. This is what gets engineers to trust and merge designer-led changes.
How do I run a QA pass on UI changes as a designer before shipping?
Prompt Cursor: "Give me a quick test checklist for this change, focused on what a designer should verify before shipping." Then manually check in Cursor's built-in preview: nav links, buttons, form behavior, layout at narrower widths, hover and focus states, and any obvious visual regressions. You're not just checking that it looks right — you're checking that it still works.
What's the difference between using Cursor's Visual Editor vs chat prompts for UI changes?
Chat prompts are best for broader changes: refactoring structure, adjusting multiple files, or making sweeping visual updates. The Visual Editor is best for precision work: tightening spacing, fixing alignment, adjusting padding on individual elements. The most effective workflow uses both — chat for speed and scope, Visual Editor for the final pass.
What happens if Cursor rewrites more than I asked it to?
Prompt: "Undo the refactor. Restore the original structure. Apply only the minimal visual changes I asked for." Cursor over-generating is the most common failure mode in existing repos. Keeping prompts narrow, reviewing diffs before accepting, and using "minimal diff" language reduces how often it happens.
When does working in Cursor start to break down for design teams?
Cursor works well for individual designers making UI changes in a codebase. It starts to strain when multiple people — designers, PMs, engineers, stakeholders — need to collaborate on frontend changes, because the review loop stays codebase-centric. Screenshot-heavy reviews, extra translation work for non-dev reviewers, and tooling overhead are the common signs a team has outgrown a repo-first workflow.
Share
