Git, Claude Code, and why a designer should care
The mental model, the tooling, the first session.
Generating design variations — the TJUG case study
One countdown card, 14 variations, real feedback loops.
From 14 variants to a shipped component
Narrowing down, wiring the winner into production.
If you have ever opened a Figma file, changed a shadow on the hero card, and then wished you could see that change rendered in the actual product — this guide is for you. Claude Code turns that wish into a very short feedback loop. It takes plain-English instructions and applies them directly to the codebase so you can explore design decisions at the speed you think.
You do not need to learn how to use a terminal, and you absolutely do not need to memorize Git commands. You need a mental model, a visual tool to review changes, and enough prompt vocabulary to ask for what you want. That is Part 1.
The short version
A branch is a sandbox. Claude Code does the work inside the sandbox. GitHub Desktop shows you what Claude changed, file by file, before anything is shared. If a change looks wrong, you ignore it and ask again. Nothing on the real product moves until you and a developer both say yes. That is the whole safety model.
Why Git matters (and why you can mostly ignore it)
Git is a memory system for files. Every time you or Claude change something, Git takes a snapshot called a commit. You can rewind to any snapshot, start a new timeline from it, or merge two timelines together. Those parallel timelines are called branches. A pull request is how a branch gets reviewed and merged back into the main timeline.
main
The live, trusted version of the project. Everyone sees it.
feature branch
A sandbox copy where Claude does the work. Affects no one but you.
commits
The snapshots Git takes of each change. Reviewable, undoable.
pull request
A formal "please merge this sandbox" — a developer reviews before it goes live.
You will hear all four words constantly. Internalize this row and you can follow any engineer conversation. You do not need to type a single command to work with them.
Here is the part that matters: when you work with Claude Code, you always work on a branch. If the output is wrong, you throw the branch away. Nothing on main changes until a pull request is merged. You cannot accidentally break the live product — the system literally does not let you.
Claude handles the branch for you
git anything. Claude Code creates the branch automatically at the start of a task, and commits as it goes. Your job is to describe the work and review the result. The Git mechanics stay invisible.GitHub Desktop — your window into the changes
You do not have to rely on the terminal to see what Claude did. GitHub Desktop is a free app from GitHub that lists every changed file, shows you the exact lines that were added or removed, and lets you send the branch up for review with a button. It is the designer-friendly surface over everything Git does.
- ☑components/Hero.tsxM
- ☑components/Hero.module.cssM
- ☑public/images/hero-bg.pngA
24 const heading = useMemo(() => (− <h1 className="text-5xl font-bold">Join our community</h1>+ <h1 className="text-5xl font-bold">+ Welcome to the <RotatingWord words={words} />+ </h1>28 ), [words]);Your project
The repository you are working in.
Your branch
Your sandbox. Switch with one click.
Changed files
Every file Claude edited, listed here.
The exact lines
Red is removed, green is new. Read before approving.
Push
Sends your branch to GitHub for review.
Three things to know when you open GitHub Desktop for the first time:
- 1
The left pane is your review queue
Every file Claude edited appears here. Click one to see the diff on the right. Uncheck a file to exclude it from the commit — a fast way to cherry-pick what you like.
- 2
The right pane is the source of truth
Red lines were removed, green lines were added. You do not need to understand the syntax — scan for obvious mistakes, hardcoded text that looks wrong, or missing alt text on images.
- 3
The commit box is your message to the team
Claude usually writes this for you. Read it. If the message says something different from what you asked, the change may not match your intent.
You can skip this entirely
What Claude Code actually is
Claude Code is Anthropic’s coding assistant. You open it inside a project, describe what you want in plain English, and Claude reads the relevant files and edits them. It pauses before every change so you can approve or reject it.
Think of it as a very patient junior developer who has already read the entire codebase, will never miss a typo, and asks permission before doing anything risky.
The three tools you will have open
Claude Code
Runs inside your editor. You type a request, it writes the code.
GitHub Desktop
Free, visual, and designed for people who do not want to type commands.
Browser
Chrome with the preview URL open. Claude can even drive Chrome for you.
Your first session, in designer terms
Forget about commands. The actual rhythm of working with Claude Code is five steps, and only the middle three involve you at all:
Claude creates a safe sandbox
A new branch is made automatically. Nothing you do here can affect the live product.
You describe what you want
Plain English. "Rework the hero to use a rotating word, keep everything else the same." Files, outcomes, constraints.
Claude previews every change
You see a diff for each file before it is written. Approve the good ones, reject the wrong ones, redirect when needed.
You review the final result in the browser
Claude tells you how to see the live preview (usually http://localhost:3000 or similar). Click around, check edge cases.
A developer opens the pull request
Click "push" in GitHub Desktop to send the branch up. A developer does a final review and merges. Done.
Steps 1, 3, and 4 are automatic or visual — no typing required. Only steps 2 and 5 need attention from you.
You will be asked for permission a lot — that is the point
What a good prompt looks like
Vague prompts produce vague code. The best prompts from designers we have watched share three things: a precise target, a clear outcome, and an optional constraint. Here is the pattern:
> In components/Hero.tsx, replace the static headline with a rotating word carousel. Use the existing useRotatingWords hook if it exists. Keep the typography and colors unchanged.
I’ll start by reading components/Hero.tsx and searching for useRotatingWords.
[Claude reads two files, previews a 14-line edit, asks permission to write]
The target
"in components/Hero.tsx" beats "in the hero area" every time.
The outcome
What should a user see after the change? Be specific about the visual, not the code.
The constraint
"Keep the typography and colors unchanged" prevents Claude from drifting into a redesign.
Copy-ready prompts are on the cheat sheet
Safety rails you should never switch off
Every designer we have onboarded has, at some point, wondered whether they can skip a confirmation dialog or auto-approve everything. You can. You should not. Here is the shortlist of habits we hold everyone to:
- 1
Read the diff before you approve it
Claude shows you what it is about to change. Scan the filenames and line counts. If you only asked about the hero and 12 files are changing, something is off — decline and reprompt.
- 2
Trust the branch, not your memory
If something breaks, do not try to fix it manually. Ask Claude to revert. The whole point of working on a branch is that nothing is permanent until it is merged.
- 3
Never merge your own pull request
A developer does the final review. It is not a gatekeeping ritual — it is a second pair of eyes on code that is going to run for real users.
- 4
Ask before anything destructive
If Claude suggests resetting the project, deleting files, or force-pushing a branch, pause. Destructive commands are impossible to undo. Drop the suggestion into #engineering and wait for a nod.
- 5
If you did not read it, you did not review it
Clicking "approve" without scanning the diff is not review, it is clicking. Treat Claude like a thoughtful junior who sometimes misreads the brief — the review is where you catch it.
What this actually produces
Enough theory. The screenshots below are all from a single Claude Code session where a designer asked for variations of a countdown card on the Tampa JUG community site. The full case study is Part 2, but here is a preview of what one session can produce in under an hour:
These are not mockups. They are production React components.
.tsx file in the project. They render with live event data pulled from Meetup’s API. Swapping the home page from one variant to another is a one-line change. That is the leverage Claude Code gives you.Where AI gets it wrong (and why that is fine)
Honesty check. In the same session that produced the screenshots above, Claude also made three mistakes worth calling out. None of them reached production, but all three are instructive.
Mistake 1 — Wrong aspect ratio
The poster got cropped on five variants
Claude assumed the Meetup event poster was 16:9. It is actually square-ish, so the top and bottom were sliced off. The fix took one prompt: "replace the cropped fit with a contained fit and add a blurred backdrop to fill the empty bars." Caught in review, not in production.
Mistake 2 — Off-brand palette
The Magazine variant used a cream background
Claude interpreted "editorial magazine aesthetic" too literally and reached for a print-warm cream. On inspection, it was off-brand. One sentence redirected it to the brand neutral. Again, caught in review.
Mistake 3 — Overconfident self-review
It thought the first five variants were good
Claude self-evaluated the first pass as polished. A human spot-check disagreed — the cropping, the weak hierarchy on two of the five, all needed rework. The lesson: every Claude-generated batch needs a human review pass, no matter how confident the model sounds.
The rule is the same rule you already use
The cheat sheet lives on its own page
Everything you need as a quick reference — the nine slash commands worth remembering, copy-ready prompt patterns for seven common design tasks, and links to the UI/UX skills on GitHub we recommend bookmarking — is on a dedicated page so you can keep it open in a tab.
Next up
Part 2 — Generating design variations (the TJUG case study)
One countdown card, fourteen variations, real feedback loops. Watch the same component redesigned end to end, including the moments Claude got it wrong.