I spent some time today exploring how to use Claude for design-related tasks. Not coding tasks, not refactors, not “build me a component”. Actual design work: thinking through layouts, exploring variants, iterating on visual structure.
These are my notes after a few hours of real use.
Table of contents
- Why I tried it
- The setup
- What works well
- Where it falls short
- A practical workflow
- Tradeoffs worth knowing
- Final thoughts
Why I tried it
Most AI design tools I’ve used feel like a wrapper over an image model. You write a prompt, get a screenshot, and you can’t really do anything with it.
Claude is different because it can actually produce structured output: HTML, JSX, Tailwind, SVG. That means the result is something you can inspect, modify and iterate on, instead of a flat image.
That alone changes the conversation.
The setup
Nothing fancy. I worked directly inside Claude with a few principles in mind:
- Describe the intent, not the visual.
- Anchor it to a real context (component, page, product).
- Iterate in small steps.
- Ask for variants, not perfection.
A typical opening prompt looked like this:
I'm designing a settings page for a developer tool.
Users mostly skim it. Density matters more than whitespace.
Give me 3 layout variants in Tailwind, no images, no icons.
Focus on hierarchy and scannability.
The key is constraining the output. Otherwise you get the same generic SaaS dashboard everyone has seen a hundred times.
What works well
A few things stood out quickly.
Exploring layout variants. Asking for 3–5 versions of the same screen is genuinely useful. Not because any of them is final, but because seeing options helps you understand what you actually want.
Component-level thinking. It’s good at proposing structure: where the primary action goes, how to group secondary info, when to collapse things.
Naming and hierarchy. It’s surprisingly decent at suggesting clearer labels, section titles and microcopy. Often better than my first instinct.
Translating rough ideas into markup. You describe a vague idea, and you get something concrete to react to. Reacting to something is much faster than designing from scratch.
Where it falls short
It’s not magic, and pretending otherwise wastes time.
- Visual taste is inconsistent. Sometimes it nails it. Sometimes it produces the most generic card grid imaginable.
- Spacing and rhythm need manual tuning. The output looks “almost right” but rarely feels balanced without adjustments.
- Accessibility isn’t automatic. It uses semantic tags more often than not, but contrast, focus states and keyboard flows still need a human pass.
- It drifts on long sessions. After many iterations, it starts forgetting earlier decisions. Short, focused threads work better.
The output is a starting point, not a deliverable. Treating it as a deliverable is where people get disappointed.
A practical workflow
This is what ended up working for me:
- Frame the problem in plain language. Who uses this, what do they need, what should be obvious.
- Ask for 2–3 structural variants. No styling yet. Just layout and hierarchy.
- Pick one. Discard the rest. Don’t try to merge them.
- Iterate on details. Spacing, typography scale, states.
- Move it into the real codebase. Adjust against your design system, not in isolation.
- Do an accessibility pass manually. Always.
Step 5 is the one most people skip. A component that looks good in a blank Tailwind page often looks wrong next to your existing components. That’s not Claude’s fault, it’s just the nature of design systems.
Tradeoffs worth knowing
| Aspect | Strength | Weakness |
|---|---|---|
| Speed of exploration | Very high | Quality varies |
| Structure and hierarchy | Solid | Visual polish is inconsistent |
| Code output | Usable as draft | Needs cleanup before merging |
| Accessibility | Decent defaults | No real validation |
| Long iterations | Good for short loops | Drifts in long sessions |
The real value isn’t replacing design work. It’s compressing the early exploration phase, which is usually the slowest and most frustrating part.
Final thoughts
Claude isn’t a designer. But used carefully, it’s a useful collaborator for the parts of design work that are mostly thinking out loud: structure, hierarchy, variants, microcopy.
The trap is expecting finished UI. The opportunity is using it to move faster through the messy early stage where most of us get stuck.
I’ll keep experimenting. There’s probably a tighter loop between Claude, a design system and a real codebase that I haven’t figured out yet.