Design in code
Make your first UI change in a real repo, from setup to a merged pull request.
You can make UI changes to a live product without writing code from scratch. What matters is understanding what each step does and why. That understanding is what keeps you safe, so this guide stays plain and explains the why as it goes.
Think of the codebase like a shared Figma file that's also live for its users. Four habits keep you safe:
- Work on your own copy, never the shared version directly.
- Start with the frontend, where you're strongest and changes are safest.
- Keep each change small, so it's easy to review and to undo.
- Let someone review it before it goes live.
One rule: don't touch the backend by accident. If a change turns out to need backend work, pause and bring in an engineer.
One note up front. This guide is a designer's path, not an engineering rulebook. Teams set things up differently, so when something touches access, setup, or safety, check the specifics with your engineers.
Work through the pages below in order, or jump to the part you need.
Draft 1, last updated 24 July 2026.
Introducing Git
The handful of Git words you'll hear, and what each one means.
Step 0: Prep guardrails
Work with your engineer to make sure the repo has guardrails before you build.
Step 1: Set up
Get your AI tools and the product repo onto your computer. You do this once, when you first join a repo.
Step 2: Plan
Start from the problem, pick your mode, and decide how much to plan.
Step 3: Build
The build loop, step by step, and how to keep an eye on the basics.
Step 4: Ship
Commit, open a pull request, get it reviewed, and merge.
Help and prompts
What to do when something breaks, where to go next, and prompts you can copy.