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.
Part 1 set up the mental model. Part 2 produced fourteen variations on a private URL. Part 3 is where design exploration turns into something real users see on the home page. That transition is where most AI workflows fall apart - and where a small amount of discipline pays back every hour you saved earlier.
The rules are the same ones any developer uses. You do not need to know how to write a pull request from scratch - Claude can draft one for you. You just need to know what a good one looks like when you read it, and what to check before a developer clicks merge.
What this part gets you
Picking a winner (or two, or none)
Fourteen variants is a menu, not a ranking. The point was never to pick the most beautiful one - it was to have enough variety that the right answer for the job can reveal itself against the wrong ones. Before you pick, re-anchor on the brief.
Who will see it?
Returning visitors on mobile? New visitors on a desktop homepage? A variant that works for one can fail for the other.
What action do you want?
Awareness, click-through, dismiss-and-remember? Each has a different shape of ideal component.
What must not happen?
Does this block content? Compete with the nav? Break on a slow connection? Rule out candidates that break the host page.
When we ran through these three questions for the TJUG case study, the answer was surprising. The most visually striking variants - Neon, Ambient Hero, Split Gradient - were impressive as hero surfaces, but the home page already had a hero. What was missing was a low-friction, dismissible signal above the nav. That is V8, the Announcement Strip.
You do not have to pick just one
Wiring it into the actual website
Once you’ve picked a direction, the next step is putting it on a real page. You do not scope the work - you describe the outcome. Claude Code figures out what has to change and does it.
The brief we sent
Add V8 to the landing page so it sticks to the top above the top nav, and only gets displayed if there is an event scheduled on Meetup. Also make it dismissible, and remember the dismissal until a new event is scheduled.
That single sentence was the whole brief. Claude Code was smart enough to turn it into working production code, including a handful of technical decisions most designers would have to escalate to a developer:
Fetching the next event at the right time
Claude made sure the banner checks Meetup for an upcoming event before the page renders, so there is no flash of empty banner on load.
Keeping it fresh
If Meetup schedules or cancels an event while someone is on the page, Claude re-checks in the background so the banner stays accurate.
Getting the sticky layout right
Banner and nav had to scroll together as one. Claude spotted a subtle CSS issue that would have silently broken the sticky behavior and fixed it before anyone asked.
Remembering each dismissal
On dismiss, Claude saved a flag in the browser keyed to this event. When Meetup schedules the next one, the banner reappears — no server work, no repeat nagging.
None of this was in the brief. Claude Code picked it up because it read the rest of the site and made the right call. This is the moment designers consistently underestimate.
You do not need to review the engineering
The handoff pack - what goes in a PR
A pull request is where design work becomes a conversation with engineering. The PR body is the single artifact the reviewer reads before anything else. Make it obvious what changed, why, and how to verify it. Claude can draft the whole thing; your job is to make sure the content matches what you actually did.
Title - one line, imperative, specific
Bad: "Update hero." Good: "Ship V8 - sticky event announcement banner on the home page." The reviewer should know exactly what merges.
Summary - three to five bullets
What the user sees. What the code introduces. Any behavior changes. Skip implementation detail - the diff has that.
Test plan - a checklist a reviewer can run
One line per scenario. "Banner renders when Meetup has an event." "Dismiss persists after reload." "Does not render on /contact." This is your proof that you tested.
Screenshots - before and after
Two images, side by side when possible. Desktop and mobile if the breakpoints matter. A reviewer should see the visual change in two seconds.
Linked issue or brief
If there was a ticket, link it. The PR becomes part of the design decision record and will be findable by the next person who asks "why is this here?"
Ask Claude to draft the PR body
Once the work is done, the prompt is literally: “Draft a pull request description for this branch. Include a summary, a test plan, and a screenshot placeholder.” Claude reads the commits and writes the PR description in about thirty seconds. You review and publish.
Two lists - yours, and the developer’s
A PR goes through two reviews: yours (before you publish) and a developer’s (before they merge). They look at different things. Run your list first so the developer’s list has less to catch.
Your checklist (the designer's)
The developer's checklist
These checks follow you
If a check fails, ask Claude to fix it
What happens after merge
Merging is not the end of the job - it is the start of observation. The first 24 hours after a change lands are when you learn whether the decision held up. Three things to watch:
Check production yourself
Five minutes after merge, open the site in an incognito window. Walk through the flow you shipped. Things that looked fine on localhost occasionally misbehave on production because of CDN caching or environment differences. Catch it now, not next week.
Look at the data, not just the pixels
Is click-through changing? Dismissal rate? Bounce? Analytics is the other half of the feedback loop. If a variant is beautiful and nobody interacts with it, that is data about the direction, not about the component.
Capture what you learned
Drop a short note in the design channel: what you shipped, what surprised you, what you would do differently. Future-you and the next designer benefit more from the note than from the artifact.
The payoff compounds
What the three parts gave you
Zoom out. The series covered three things:
A mental model
Branches as sandboxes, commits as snapshots, GitHub Desktop as your review window. Enough to follow any engineering conversation without the jargon.
A repeatable loop
Brief → generate → review → iterate → ship. Every step has a shape and a signal for when to move on. You can run this on any component, any project.
A handoff discipline
The PR body, the test plan, the two-list review. The difference between a fun experiment and a change that ends up in production.
None of it depends on command-line fluency. None of it depends on knowing React. It depends on the three skills designers already have: a clear brief, a strong review eye, and the discipline to not ship something you have not actually seen.
When in doubt, ask Claude first
Keep the cheat sheet nearby
The Claude Code Cheat Sheet for Designers is meant to live in an always-open tab. Copy-ready prompt patterns for the seven most common design tasks, the nine slash commands worth remembering, and links to the UI/UX skills on GitHub worth bookmarking. Return to it often.
You finished the series
Now go make something
Pick a component on your current project that has been bothering you. Open Claude Code, brief it with one sentence, and see what happens. The first session is the scariest. After that it is just another tool in the kit.