Chapter 03 — Building with Claude | The Designer Who Codes

The right mental model

Claude is not a vending machine. You don't put in "make me a website" and get back a perfect finished product. It's more like working with a very fast, very capable junior developer who needs clear direction.

You are the creative director. You have the vision, the taste, the understanding of the user. Claude has the technical knowledge to implement things quickly. The best results come from back-and-forth — you set the direction, Claude drafts, you react, Claude adjusts. Three rounds of iteration almost always produces better work than one perfect prompt.

💡 The mindset shift

Stop trying to write perfect prompts

New Claude users spend a lot of time trying to write the "perfect" prompt that gets a perfect result in one shot. That's not how it works — and that's not how even senior developers write code. The power is in iteration. Get something on screen fast, then describe what's wrong and improve it. Move like a creative director: react, direct, refine.

How to prompt for UI

The best prompts for UI describe things visually and functionally, not technically. You don't need to know CSS property names to describe what you want. Talk like a designer.

❌ Weak prompt

"Make a button"

This gives Claude almost no information. It will produce something technically valid but visually generic. You'll be back in a minute asking it to "make it look better."

✓ Strong prompt

"Make a primary call-to-action button"

"Make a button with a bright yellow background (#f5e642), dark text (almost black), Inter font, bold weight, slightly rounded corners (6px), and a smooth hover effect where the background lightens slightly. It should say 'Get Started'. Make it feel high-quality and confident, not generic."

The elements of a strong UI prompt:

What it looks like — colors, fonts, spacing, shape, visual style
What it does — hover effects, click behavior, any animation
What style/tone — "editorial and bold", "clean and minimal", "playful and rounded"
What constraints — "single HTML file", "no JavaScript", "use Inter font", "dark background"
What to avoid — "don't use drop shadows", "no bright colors", "keep it simple"

The iteration loop

This is the actual workflow you'll use 90% of the time:

1. Prompt — describe what you want to build
2. Get code — Claude generates HTML/CSS
3. Open in browser — paste code into VS Code, open in Chrome
4. Spot issues — something looks wrong, doesn't match your vision, or needs refinement
5. Describe it in plain English — tell Claude exactly what to fix
6. Repeat — 3 to 5 rounds of this gets you somewhere great

💬 How to describe problems

Plain language works perfectly

You don't need to know the CSS property name to describe the problem. "The button is too close to the title" = increase margin-top. "The text is hard to read" = increase contrast or font size. "The card feels cramped" = increase padding. Describe what you see and what you want — Claude translates it into code.

// After getting the first draft, these are real prompts that work:

"The button is too close to the heading above it. Add more space between them."

"The card feels too narrow on desktop. Make it wider, up to 600px max."

"The font looks too light and hard to read. Make the body text brighter."

"The hover effect on the button is too subtle — make it more noticeable,
 maybe a slight scale up or a brighter background."

"This looks good on desktop but I think it'll break on mobile.
 Can you add media queries to make it stack vertically on screens under 768px?"

How to read error messages without panicking

Things will break. This is completely normal — it happens to every developer, every day. The skill isn't avoiding errors; it's knowing what to do when you see them.

"The page is blank" — The HTML file likely has a structural error (a missing tag, a broken link to the CSS file). Open DevTools (Cmd + Option + I), click the Console tab, and look for red error messages.
"The styles aren't applying" — Your CSS file isn't linked correctly, or the class name in HTML doesn't match the class name in CSS (check for typos — class="Card" and .card are different).
Red errors in the Console — Read it first. Errors follow a pattern: what went wrong, which file, which line. A TypeError: Cannot read properties of undefined means you're accessing something that doesn't exist yet. A 404 means a file path is wrong. Try to understand what it's saying before reaching for Claude — you'll get faster at this faster than you think.

🎯 The key move

Read the error, then debug it — with or without Claude

Spend 5 minutes trying to understand what the error is saying before asking Claude. What file? What line? What type of error? You'll often find it yourself — and when you don't, you'll be able to explain it clearly. Claude is a great debugging partner, but the goal is to need it less over time, not more.

You need: The in-page IDE below

1

The code below has exactly 3 bugs. Some are HTML mistakes. Some are CSS mistakes. None produce a loud red console error — they silently break the visual result.
2

Click ▶ Run to see the broken result. Then read the code carefully — line by line — and find what is wrong. Fix each bug and re-run until the card looks correct: yellow title, styled button, proper footer placement.
3

No hints. This is the core skill — reading code and reasoning about why something is not working. You will use it every time Claude gives you code that does not look right.

✦ Own your code

Can you explain every line?

Before moving on: pick any 5 lines from the code above and say out loud what each one does. Not the general idea — the specific line. If Claude ever gives you code like this, hold it to this standard before you use it. If you cannot explain a line, you cannot debug it.

Giving Claude the right context

Claude doesn't remember your previous conversations (unless you're in a Project). Every new chat is a fresh start. This means you need to treat each conversation like briefing a new collaborator — give them the context they need.

The most common mistake: asking Claude to change something without giving it the current code. "Add a dark mode" is useless context-free. "Here's my current HTML and CSS [paste] — can you add a dark mode toggle that switches between light and dark using a button?" is actionable.

Here's my current HTML and CSS:

[paste your entire code here]

---

I want to [describe the change].
Specifically: [describe what it should look like/do].
Please give me the updated full file.

Always ask for "the updated full file" — this way you don't have to manually merge changes. Claude rewrites the whole thing and you replace your file with the new version.

You need: Figma (free account) Claude (free — claude.ai) VS Code Chrome

1

Open Figma and create a new file. Create a frame at iPhone 14 size: 390 × 844px. Using just rectangles and text, sketch a simple landing page layout: a nav bar at the top, a big headline, a subtitle, and a "Get Started" button. This is a lo-fi sketch — it doesn't need to look great.
2

Take a screenshot of your Figma frame (in Figma: select the frame → right-click → "Copy as PNG", or use Cmd + Shift + 4 on your Mac to screenshot the screen).
3

Open claude.ai. Click the paperclip icon to attach your screenshot. Then type: "Build this as a single HTML and CSS file. Use a dark background (#0a0a0a), white text (#f0f0f0), Inter font from Google Fonts, and a yellow (#f5e642) accent color for the button. Make it responsive for mobile. The CSS should be inside a <style> tag in the same file."
4

Paste Claude's code into a new index.html file in VS Code. Open it in Chrome. Look at it critically — what's not right? What doesn't match your design sketch?
5

Do at least 3 rounds of iteration. For each: describe one specific thing that needs to change. Paste your current code into Claude with the context. Get the updated file. Replace and reload. By round 3, it should look meaningfully better than round 1.

Key takeaways

You're the creative director — Claude is the implementer. Set direction, iterate on the details.
Describe things visually ("the button is too close to the title") not technically.
Always paste your existing code when asking Claude for changes — never ask without context.
Error messages aren't failure — they're clues. Copy them and paste into Claude.
3–5 rounds of iteration almost always produces better work than one "perfect" prompt.
Ask for "the updated full file" so you don't have to manually merge changes.