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.”
“Keep logic intact. Restore handlers, links, routing, and forms. Make only the visual changes needed.”
“Reuse existing components, tokens, and styling patterns already used in this repo. Don’t introduce new conventions.”
“Show me exactly which file(s) render this screen/section and highlight the main component responsible.”
“Explain this error simply. Fix it step by step. Do the setup work for me where possible and tell me what changed.”
“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
Do designers need to learn coding to use Cursor well?
Not in the traditional “become a software engineer” sense.
But designers do need to learn how codebases work: how projects run locally, how components are organized, how to make safe UI changes, and how to review diffs before accepting them. The goal is not mastering programming theory. The goal is shipping design changes reliably.
Is Cursor only useful for vibe coding and prototypes?
No. That’s the most common starting point, but it’s not where the biggest value is.
The real leverage comes when designers use Cursor in existing product repos and for Figma → production code translation. That’s where agentic workflows reduce handoff time, speed up iteration, and help designers ship without breaking logic.
What is the best Cursor workflow for product designers?
The best workflow is a combination of three modes:
- Greenfield vibe coding for fast prototyping
- Existing repo editing for real product work
- Figma → code translation for accurate implementation
If you only learn vibe coding, you’ll get fast at mockups. If you learn all three, you’ll get fast at shipping.
How can designers avoid breaking functionality when using Cursor?
Use a few rules consistently:
- Say “keep logic intact” in your prompts
- Make small diffs
- Reuse existing components and tokens
- Review changes before accepting
- Test the UI locally in Cursor preview (links, buttons, forms, responsive states)
Cursor is powerful, but you still need to constrain it.
Should designers use Cursor’s Visual Editor or just chat prompts?
Both.
Use chat prompts to make structural changes, refactors, or multi-file updates. Use the Visual Editor to fine-tune spacing, hierarchy, typography, and layout details. The strongest workflow is hybrid: AI for speed, visual editing for precision.
Do I need Git to use Cursor as a designer?
You do not need to know Git commands to start.
For team/product work, you still need the workflow concepts: branches, commits, and pull requests. Cursor can help you perform many of those steps, but you should understand what they mean and why they protect your team.
What should a designer review before accepting Cursor changes?
At minimum, check:
- Were any links/handlers removed?
- Did Cursor refactor logic you didn’t ask it to change?
- Does the UI still work locally?
- Do hover/focus/responsive states still behave correctly?
- Does the change match the design system patterns already in the repo?
You’re not just reviewing visuals. You’re reviewing shipping risk.
