Claude Design

Claude Design is Claude working in a visual project: a file system, a live preview, and a designer that builds everything as real, working web pages rather than pictures of pages.

That one architectural fact explains everything good about it. Because a "slide" is a real page, it can have working navigation, animation and interactivity. Because a "prototype" is a real page, buttons actually click and flows actually flow. And because everything is a file in a project, work persists, links between pages work, and a whole set of deliverables can live together and share a look.

If it's visual and shippable, it's in scope. The working list, roughly in order of how often people need them:

Design quality tracks brief quality even more tightly than writing does, because taste is harder to describe than facts. Three rules carry most of it.

• Never start from nothing. Attach something visual with the first message: your logo, an existing deck, a screenshot of a site whose vibe you want, brand colours, even a napkin sketch. A design started without context is a design you'll be correcting for an hour. If you have nothing, say what the design is for and let Claude ask its questions first.
• Show, don't describe (the same law as guide 02): "clean and modern" means nothing; a screenshot of a page you love means everything. Hate is data too: "not like this" with an example saves three rounds.
• Name the medium and the stakes. "A deck for a 10-minute pitch to investors" and "a leave-behind PDF they'll read alone" produce different right answers. Say which one you're in.

I need a 10-slide pitch deck for [company], presenting
live to [audience] for [duration]. Attached: our logo,
brand colours, and a deck whose style I like. Tone:
[confident/warm/technical]. The argument: [one
sentence]. Ask me anything unclear before you start,
and show me 2-3 visual directions for the title slide
before building the rest.

That last line is the art-director move: approve a direction on one piece before the whole thing gets built in the wrong one.

The single highest-leverage thing in Claude Design, and the least used. A design system is a project holding your colours, fonts, components and rules; bind it to any new project and everything made there comes out on-brand by default.

It's the same compounding law as the rest of this series (projects, skills): encode taste once, stop re-explaining it. Before the system, every deck starts with "our blue is #2C6EE6, our font is…". After it, "make the Q3 deck" is on-brand from the first slide.

1. Have Claude build the system itself. Feed it your logo, site and any brand documents: "turn this into a design system: palette, type, components, usage rules". Refine it like any design.
2. Bind it to new projects and name it in briefs: "using our design system". Consistency stops being a chore and becomes the default.
3. Grow it when you correct it. The second time you fix the same thing ("headings are always the dark blue, never black"), that rule belongs in the system, not the chat. Sound familiar? It's CLAUDE.md for visuals (guide 07, section 05).

Where Claude Design feels genuinely different from chat: you refine work the way you'd mark up a proof, not by writing paragraphs about it.

• Comment on the thing. Click any element in the preview and leave a note on it: "this heading", not "the third heading in the second section, no not that one". Claude reads the pin and knows exactly what you mean.
• Edit directly. Text, colours and simple styles can be changed by hand in the preview, like editing a document. Claude respects your manual edits in later revisions.
• Sketch what you can't say. Draw the layout you're imagining (boxes and arrows, quality irrelevant) and attach it. A ten-second napkin sketch outperforms a paragraph of spatial description every time.
• Screenshot the reference. "More like this" with a picture beats any adjective.
• Change one dimension at a time, and version big swings: "keep this, try a bolder v2" costs nothing and preserves your fallback.

Amateurs ask for the design; art directors ask for the spread. Claude Design is built for comparing directions, so use it that way.

• Ask for directions side by side. "Three visual directions for this landing page: one safe, one bold, one unexpected", laid out on one canvas you can pan around. You'll usually take one and steal a detail from another, which is exactly the point (the options-spread pattern from guide 02, in pictures).
• Ask for tweaks, not forks. For variations of a finished piece, have Claude build the options as toggles inside the design: a Tweaks panel where you flip between colourways, densities or copy versions live. One file, all the options, no "final_v7_THISONE" folder.
• Decide on structure before polish. Wireframe-level options first ("which of these three layouts?"), styling after. Reversing the order wastes the styling twice.

Because everything is a real page, a prototype isn't a picture sequence pretending to be an app; it's a small working app. That changes what you can learn from it.

• Real interactions: forms that validate, flows with real state, data that updates. Put it in front of a user and watch them actually use it.
• Real devices: phone-framed mock-ups that behave like the phone app would, shareable as a link to anyone.
• Even real intelligence: a prototype can call Claude from inside itself, so you can mock up AI-powered products (a support bot, a summariser, a writing tool) with the AI genuinely working in the demo.
• Brief behaviour precisely. Looks are Claude's job; the logic is yours (the same split as guide 05's tools): "when the user picks the annual plan, the price updates and the FAQ reorders".

A design that can't leave the tool is a screenshot. Everything here has a proper exit route; the skill is picking the right one before you build, because the destination shapes the design.

Where the tool ends, so you stop pushing on walls.

• It designs; it doesn't do photography. Real product shots, headshots and brand photography come from you. Claude places and treats them beautifully, but a design full of placeholder boxes needs your images before it's real.
• Editable exports are translations. PowerPoint's engine isn't a browser; complex layouts survive, exotic effects may simplify. For pixel-critical decks, use the screenshot export or present from the browser.
• It's not Figma. No multi-designer canvas, vector pen tool or component inspector for a human design team. It replaces the "I need a designer and don't have one" gap, not a design department's tooling.
• Taste still needs a client. Claude has range, not your opinions. The fastest projects are ones where you react decisively: "yes to A, kill B, push C further". Indecisive feedback produces indecisive design, same as with a human studio.

The studio rules, distilled.

1. Context in the first message: logo, reference, sketch, or an existing anything. Never from nothing.
2. Directions before details: approve a look on one piece before the set gets built.
3. Build the design system early; grow it with every correction you make twice.
4. Comment on elements, sketch layouts, screenshot references. Prose is your worst feedback tool.
5. One dimension per revision; version the big swings.
6. Options as tweaks in one file, not folders of forks.
7. Name the destination in the brief: PowerPoint, PDF, website, dev handoff. It changes the build.
8. React decisively. The tool moves at the speed of your yeses and nos.