Claude Code Is a Brilliant Junior Designer. That’s Exactly the Problem.

How I run a full double diamond with Claude Code, and the supervision it takes.

I run my whole design process through Claude Code now. Research, synthesis, design system work, prototypes, and final handoff to Figma over MCP.

The speed is real. Work that took two weeks takes a few days.

But it isn’t that simple

The independence is not. Every hour I save on making things, I spend part of it back on checking things. Read the output. Question the reasoning. Catch the drift. Skip that and you ship confident nonsense, fast.

Here is the process, and where I step in.

Why the terminal and not the chat window

Chat is a conversation. Claude Code can make the designs. So it works off your real transcripts and your real spacing scale, not off a summary you pasted in.

My folder looks like this:

/research        transcripts, notes, survey exports
/design-system tokens, component specs, usage rules
/synthesis clusters, HMWs, problem statement
/prototype the working build
CLAUDE.md standing rules for the project

CLAUDE.md matters most. It holds the rules I got tired of repeating:

• exact type scale
• exact spacing tokens
• never invent a colour
• cite the transcript line for every insight

Diamond One (Problem Space)

Discover

What I use it for:

• Interview synthesis. It reads twelve transcripts faster than I read two.
• Competitor analysis. Teardowns against criteria I set. Step counts, hierarchy, empty states, friction points.
• Workshop prep. Activity plans, timeboxes, stimulus, synthesis templates.

Where I step in

Claude flattens nuance. You get clean, safe themes. “Users want more transparency.” That is not an insight, it is the shape of one.

One rule fixes most of it:

Every theme must quote a real line from a real transcript.

Ask for that and the generic themes fall apart, because nothing supports them. The sharp ones survive, because someone actually said them.

Same rule for competitor work. If it makes a claim, I want the screen.

Define

Affinity mapping, HMWs, problem statement.

I step in most here. Everything after this inherits the problem statement. Get it wrong and you build a great solution nobody needed.

Where I step in

• First pass HMWs are usually the brief in different words. Push it to one specific tension at a time.
• Watch for invented needs. It fills gaps because that is what it does. If something surprises you, ask which participant said it. Vague answer, delete it.
• I write the problem statement myself. Claude drafts, I rewrite.

Diamond Two

Develop

Two jobs here: exploration, and design system upkeep. Design system work is where it helps most and fails most. It will audit tokens, find drifted components, flag inconsistent spacing, and write docs for components that never had any.

Then it drifts anyway.

Where I step in

This is my biggest problem, so here it is in detail.

Claude gets spacing, margins, padding and alignment wrong. Often. It will use 14px when your scale only has 12 and 16. It will centre something that should sit left, because centred looks fine on its own.

What helps:

1. Give exact values, never categories. Not “use our type scale”. Give the font, weight, size, line height.
2. Put the full token list in CLAUDE.md.
3. Ban invention. “If a value is not in the system, stop and ask me.”
4. Check spacing by hand anyway. Every time. I have never had a clean run.
5. Give real references. Vague inspiration in, vague design out.

It feels excessive until you catch a full screen built on a spacing scale it made up.

Deliver

• Prototypes. Clickable, in browser, built in hours.
• Testing. Test Tuesday, fix Wednesday, test again Thursday. This is the real win.
• Figma handoff over MCP. Designs land with proper auto layout and components tied to the system. Nobody rebuilds anything.

Where I step in

Prototypes are where it adds things nobody asked for. A filter bar for six items. A settings panel. Three states for something with one. It builds what a screen like this usually has, not what this screen needs.

My rule: make it list every element and the reason for it, before it builds. Cut the list first. Arguing with a list is cheap. Stripping a build is not.

Check the auto layout too. MCP gets it right most of the time. Most is not all.

The rules I work by

1. Read every answer properly. It sounds just as confident when it is wrong.
2. Be exact. Exact fonts, exact tokens, exact values.
3. Question every reason. Thin reasoning means the output is wrong, even if it looks right.
4. Ask for proof. Insights cite transcripts. Values cite the design system.
5. Assume drift. Check spacing, margins, padding, alignment by hand.
6. Cut the plan, not the build.
7. Bring better inputs. Specific references, clearly described.
8. Own the calls. Problem statement, direction, final judgement. Yours.

What it does not replace

It does not replace sitting with a user and noticing what they did not say. It does not replace taste. It does not replace knowing which of five good directions is the right one, which is most of the senior job.

What it removes is the distance between having an idea and seeing it built.

But you still have to decide. It is fast enough to build the wrong thing beautifully, and it will, unless someone is watching.

That someone is you.

Would definitely suggest you to watch these two videos to understand how I use Claude

📌 Stay Connected!

📍 Follow me on LinkedIn for more design insights: LinkedIn
🎙️ Book a FREE 1:1 call on Topmate: Topmate
📹 Subscribe to my Youtube Channel: Youtube

Claude Code Is a Brilliant Junior Designer. That’s Exactly the Problem. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.