I want to be careful here, because "using AI for design" is one of those phrases that gets thrown around in a way that makes it sound either magical or completely useless. In my experience, it's neither. Claude has become a genuine part of how I approach design problems — not because it replaces anything I already do well, but because it's oddly good at the parts of design work that are slow and frustrating: articulating tradeoffs, stress-testing copy logic, generating structured critique when I'm too close to a layout to see what's wrong.
This post is a practical walkthrough of how I actually use Claude as a design collaborator. Real prompts, real outputs, real moments where it failed and I had to course-correct. If you want a broader framework for deciding when to trust AI output at all, I wrote about that in 10 Patterns for Evaluating AI Outputs — but here I want to stay focused on the design-specific workflow.
The Problem With Most "AI for Design" Advice
Most articles on this topic tell you to ask Claude to "generate UI copy" or "suggest color palettes." That's fine, but it treats Claude like a vending machine — input a category, receive an output, move on. What I've found is that Claude works much better as a thinking partner than a generator. The difference is subtle but important.
A generator produces answers. A thinking partner helps you ask better questions, poke holes in your assumptions, and surface the thing you weren't quite able to articulate. That shift in how I frame the collaboration changed everything about the quality of what I got back.
Step 1: Describe Your Interface in Structured Terms
Claude can't see your Figma file. Even with Claude's vision capability in some contexts, I've found it more reliable to describe the interface in words — because it forces me to think clearly about what I'm actually building.
Here's the template I use when starting a design review session:
Screen: [name of the screen]
User goal: [what the user is trying to accomplish]
Current structure: [list the main elements in order — headline, subheadline, form fields, CTAs, etc.]
Current copy: [paste the actual copy, not a description of it]
My specific question: [one clear question — not "what do you think?"]Example — I was working on a subscription upgrade prompt that appeared mid-session in a project management tool I was building for a client. Here's what I sent:
Screen: Upgrade prompt modal (appears when free user tries to export a report)
User goal: Export their report. They didn't come here to upgrade — they were interrupted.
Current structure: Modal title, 2-sentence value prop, feature list (3 bullets), two buttons (Upgrade Now / Maybe Later)
Current copy:
Title: "Unlock Full Export"
Body: "Upgrade to Pro to export reports in PDF and Excel. Get access to advanced filters, custom branding, and priority support."
Bullets: PDF + Excel export / Custom branding / Priority support
Primary CTA: "Upgrade Now"
Secondary CTA: "Maybe Later"
My question: Does this copy address the right thing at the right moment, or is it trying to sell too much to someone who just wanted to export a file?What came back was genuinely useful. Claude pointed out that the body copy was doing two different jobs — justifying the export feature specifically, and then pivoting to list unrelated upsells like "priority support." For a user who was interrupted mid-task, that pivot creates friction. It also flagged that "Maybe Later" is a passive dismissal that doesn't acknowledge the user's actual intent (they still want to export — they just might not want to upgrade right now).
Those were observations I was circling around myself but hadn't quite landed on clearly. Having them stated plainly helped me move faster.
Step 2: Use Claude to Stress-Test Your Hierarchy Logic
One of my favourite uses is having Claude argue against my layout decisions. Not "improve this layout" — that's too open. I ask it to find the weakest part of the information hierarchy and explain why.
For a dashboard landing page I was designing, I gave Claude the screen description and said: "If a first-time user landed here with zero context, what's the first thing they'd get confused by, and what in the current hierarchy is causing that?"
The answer wasn't what I expected. I thought my empty state was the problem (it usually is — I've written about that pattern specifically in the context of empty state redesigns). But Claude pointed to the navigation — specifically that I had a "Reports" tab visible before the user had created any data, which signals a level of completeness the product hadn't earned yet. That was a real insight, and I acted on it.
Step 3: Generate Variations, Then Judge Them Yourself
I use Claude to generate multiple versions of things — headlines, CTA labels, error messages, onboarding step copy — but I've learned not to ask for "the best" version. That framing just gets me one answer that Claude has pre-decided is best, which removes my judgment from the loop.
Instead, I ask for variations with intentional differences in tone or emphasis:
Give me 5 versions of this CTA label. Each version should prioritise a different thing:
1. Speed / getting results quickly
2. Safety / low-risk commitment
3. Social proof / others are doing this
4. Curiosity / what will they discover
5. Direct / no framing at all, just the action
Context: This button appears on a free trial signup page for a B2B invoicing tool. Users are small business owners, slightly skeptical of SaaS tools, probably burned before.This gives me five coherent options I can actually evaluate, rather than one "optimised" label that might not fit the brand voice or the user's actual headspace. The judgment stays mine. Claude just saved me the twenty minutes of staring at a blank doc.
Step 4: Run a Structured Accessibility Logic Check
This one surprised me when I first tried it. I don't use Claude to replace an actual WCAG audit — that requires tooling and real browser testing. But I do use it to catch logical gaps in my accessibility reasoning before I get to that stage.
I describe a component — say, a custom dropdown with keyboard navigation — and ask Claude to list every accessibility consideration I should be accounting for: ARIA roles, keyboard interaction patterns, focus management, screen reader announcement order. Not to implement them, but to give me a checklist I can audit against.
On a recent project, this process caught something I'd genuinely missed: I had built a multi-select filter component where the selected state was communicated purely through background colour change. No aria-selected, no visible text change, no icon. Claude's checklist included "ensure selected state is communicated through means other than colour alone" — which is WCAG 1.4.1, and yes, I had violated it. It took me fifteen minutes to fix once I knew where to look.
Step 5: Use It for Design Rationale Documentation
This is probably the least glamorous use case, but it saves me real time on client projects. After making a design decision, I describe what I chose and why, and ask Claude to help me write it up as a clear design rationale — the kind that goes in a handoff doc or a client presentation slide.
Example input:
I moved the primary action button from the top-right of the card to the bottom of the card, below all the content. Reason: user testing showed people were clicking it before reading the card content, then being surprised by what happened next.
Help me write this as a one-paragraph design rationale for a client handoff doc. Audience: non-technical stakeholders.The output is usually 80% there on the first try. I edit tone, add specifics, and move on. What used to take me fifteen minutes of staring at a Google Doc now takes three.
Where Claude Earns Its Place — and Where It Doesn't
I want to be honest about the limits, because I've seen what happens when people trust this tool in the wrong contexts.
Claude does not know your users. It knows a reasonable approximation of "general users" based on its training data, which skews toward Western, English-speaking, tech-comfortable demographics. When I'm designing for small Indonesian SMB owners — which is most of my client base — I've learned to apply heavy skepticism to Claude's assumptions about user behavior. It'll suggest patterns that make sense in a Silicon Valley SaaS context and fall completely flat for someone running a warung who needs to invoice on a mobile browser on a slow connection.
Claude also doesn't know your technical constraints. It'll suggest things that are elegant in theory and impossible on shared cPanel hosting with no WebSocket support. That's fine — I just filter for it. But you have to know to filter, which means you have to bring your own context to the conversation, not expect Claude to infer it.
And occasionally Claude is just wrong. It'll state an accessibility rule with confidence that's slightly off, or recommend a copy pattern that violates what I know about the brand. This is why the output always goes through my judgment before it goes anywhere near a client. The evaluation layer is non-negotiable.
A Quick Reference: Prompt Patterns That Work
- Hierarchy critique: "If a first-time user landed here with zero context, what would confuse them first?"
- Copy variation: "Give me 5 versions of this label, each prioritising a different goal: [list goals]."
- Accessibility checklist: "List every accessibility consideration I should account for in this component: [describe component]."
- Rationale writing: "I made this design decision for this reason — write it as a one-paragraph rationale for non-technical stakeholders."
- Stress test: "Argue against this design decision. What's the strongest case for doing it differently?"
- Copy audit: "Is this copy doing one job or two? If two, which job should it prioritise at this moment in the user journey?"
The Mindset Shift That Made Everything Work Better
Honestly, the biggest change wasn't in how I prompt Claude — it was in what I expect from the collaboration. I stopped expecting it to give me answers and started expecting it to help me think faster. That's a different relationship with the tool, and it's a more honest one.
Claude is sharp at pattern recognition, articulation, and structured critique. It's weak at contextual judgment, cultural nuance, and knowing what you haven't told it. The moment you accept that split, you stop being frustrated when it misses something obvious (to you) and start using it for the specific tasks where it consistently adds value.
For UI/UX work specifically, that turns out to be a lot of tasks. Not all of them — but enough that I'd miss it if it were gone. That's probably the most honest endorsement I can give.
Frequently Asked Questions
Can Claude actually help with UI/UX design decisions, or is it only useful for writing and code?
Claude is genuinely useful for design reasoning tasks — critique, user story framing, copy hierarchy, and accessibility logic — even though it can't see your screens without a vision-capable model. The key is learning to describe your interface in structured, specific terms so Claude has enough context to reason about it properly.
What kinds of design prompts give the best results from Claude?
Prompts that include the user type, the goal of the screen, the current copy or structure, and a specific question you want answered. Vague prompts like "make this better" return vague answers. Specific prompts like "this modal has three actions — which one should be the primary CTA and why?" get you real reasoning.
Is Claude reliable enough to use in a client-facing design workflow?
As a thinking partner and first-pass critic, yes. As a final decision-maker, no. Claude's suggestions still need to be filtered through your knowledge of the actual users, technical constraints, and brand context — things it simply doesn't have access to unless you supply them.
