Why the Same Model Designs Better in One App Than Another

Ask Claude for a screen inside Claude Design and you get something you’d happily show a client. Ask for the same screen in Claude Code and you get something that works, passes the linter, and looks like a form. Same company, same underlying model, very different results.

That gap confused me for a while, because the obvious explanation is wrong. Nobody has given Claude Design the smarter model. It’s working under a different set of conditions, and most of them you can copy.

It can see what it made

Claude Design draws your screen on a canvas and then looks at it. If the heading crowds the image, it can tell, because it’s looking at the heading crowding the image.

Claude Code can’t do that. It writes code into files and never sees the screen. Imagine describing a room to someone over the phone and asking them to hang the pictures. They can follow every instruction perfectly and the wall still looks wrong, because they’re hanging pictures they’ve never seen.

Almost everything else here is downstream of that one difference.

Small corrections beat long explanations

In Claude Design you point at the thing. Click the button, say “too heavy,” drag a slider for spacing. The feedback is attached to the element you’re talking about, so there’s no guessing involved.

In a chat window or a terminal you type “the spacing feels off at the top,” and the model has to work out which spacing, which top, and how much. Half the round trip goes on locating the problem rather than fixing it. Three precise nudges beat one paragraph of description nearly every time.

The medium it knows best

Claude Design builds web mockups, which means HTML and CSS. Models have read an enormous amount of good-looking web pages, so that material is deep in there. Ask for the same screen in a mobile framework, or a chart library, or your company’s in-house component kit, and the model is working from far less. It’s the difference between cooking in a cuisine you’ve made a thousand times and one you’ve only read about.

Where the attention goes

Attention is a budget, and everything in the context window competes for it.

In a real codebase, before the model can touch a screen, it loads the coding rules, the naming conventions, the accessibility requirements, the right-to-left language handling, the checks that run before a commit. All of that is necessary, and none of it is about whether the screen looks good. By the time the model reaches “so, how should this look,” most of its attention is spent.

Claude Design reads your design system once, boils it down to colours, type and spacing, and then spends the rest on the screen. Same budget, different allocation.

What it’s aiming at

A Claude Design mockup is meant to be looked at, reacted to, and thrown away. Nothing breaks if it’s wrong.

Code is meant to ship. It has to pass checks, survive translation, work at every screen size, and not wake anyone up at 2am. Aim at “must not break” and you get safe choices; aim at “must look right” and you get bolder ones. Neither aim is wrong, and if you ask for shippable code you shouldn’t be surprised to get careful design.

What to do about it

Explore in one place, build in another. Try layouts where the model can see them, then hand the chosen one to the coding tool to build properly. Anthropic supports this directly, with a design system sync between Claude Design and Claude Code.

Give the coding tool eyes. Screenshot the running screen and paste it back in. It’s unglamorous and it recovers most of the gap. You become the model’s vision for one round trip.

Separate the two jobs. A pass for how it looks, then a pass for the rules. Do both in one prompt and the rules win, because the rules are specific and “looks good” is not.

Point instead of describing. Screenshot with an arrow on it. A crop of the bad bit. Anything that removes the step where the model has to guess which part you mean.

Summary