How to Use Claude as a UX Thinking Partner, Not a UI Generator

Most designers' first move with Claude looks the same: open a chat, type "design me a clean dashboard," and see what comes back.

It usually looks fine. That's also the problem. A screen can look fine and still have no real thinking behind it — no defined user, no stated problem, no reasoning for why anything is arranged the way it is. UI/UX consultant Khairul Islam Ontor ran into exactly this, and the fix he landed on wasn't a better prompt. It was a different job for the tool entirely: stop asking Claude to generate interfaces, and start using it to think through the UX decisions that should happen before an interface exists.

Here's what that shift looks like in practice, prompt by prompt.

The problem with prompting for screens

Asking an AI model for a finished UI skips the part that actually makes a design good. There's no user behind the request, no problem it's solving, no constraint shaping the layout — just a request for output. What comes back can look polished and still be empty: no clarity about who it's for, no real UX decisions, nothing you couldn't have gotten from a template.

AI doesn't make weak design thinking stronger. It just renders whatever thinking you gave it, clearly enough that the gap becomes obvious.

Turn messy notes into a real product direction — before any screen exists

Instead of asking for a screen, start by handing Claude the unstructured version of your thinking: rough notes, business context, half-formed ideas about who this is for and why. Ask it to organize that into four things — a clear product goal, a target user defined by behavior rather than demographics, a core problem statement, and the outcome you want the user to walk away with.

A working version of that prompt:

I'm working on a product idea. Here are my raw thoughts:

[Paste messy notes]

Help me structure this into:
- Clear product goal
- Target users (with behaviors, not demographics)
- Core problem statement
- Expected outcome for users

Keep it simple and practical. Avoid generic startup language.

This is the step most people skip on the way to Figma. It's also the step that determines whether anything downstream is worth designing.

Define UX before you touch UI

Once the product direction is clear, the next question isn't "what should this screen look like" — it's what the user is actually trying to do, what the simplest path to that outcome is, and where they're likely to get stuck along the way.

Answering those three questions with Claude before opening a design tool turns UX from something you retrofit onto a finished screen into something that actually shapes it.

Design one screen at a time, with reasoning attached

A single prompt asking for a full UI tends to produce a full UI you didn't actually decide on — Claude fills in gaps with plausible defaults, and those defaults become your design by default. Working screen by screen, with an explicit instruction not to generate visuals yet, keeps the decisions in your hands instead of the model's.

We are designing this screen:

[Describe one screen + its goal]

Help me:
- Define what must be on this screen (priority elements)
- What can be removed or secondary
- UX rationale for each section

Do NOT generate UI.
Focus only on structure and decision-making.

The UI comes after this, once the structure and the reasoning behind it are already settled — which makes the actual visual design faster, not slower.

Use Claude to critique your work, not just produce it

This is arguably the most underused move: pasting in a screenshot or describing an existing layout and asking Claude to critique it like a senior product designer would, rather than asking it to redesign anything.

[Paste screenshot / describe layout]

Act as a senior product designer and critique this.

Focus on:
- Clarity
- Hierarchy
- User flow
- Cognitive load

Be direct. Point out weak decisions.
Suggest improvements with reasoning.

A blunt critique of an existing decision is often more useful than a fresh generation, because it forces you to defend or abandon choices you've already made instead of starting over every time.

Build reusable workflows instead of re-typing prompts

Once a few of these prompt patterns are working, the next step is turning them into something reusable — a UX audit checklist, an onboarding flow breakdown, a feature prioritization framework — so the process doesn't get rebuilt from scratch on every project. That's the difference between prompting an AI tool and actually building a design system for how you use it.

The real shift: Claude is an amplifier, not a substitute

Same model, same designer, different results — because what changed wasn't the tool, it was the thinking fed into it. More intentional input produces more intentional output. Vague input produces something that looks acceptable and says nothing.

That's the part worth sitting with: AI doesn't fix unclear thinking, it exposes it. Designers who get real value out of tools like Claude aren't the ones with better prompts. They're the ones who've done the work of getting clear on the problem, the user, and the outcome before they ask for anything at all.

Quick reference: prompts to use before you open a design tool

1. Structure the idea — turn raw notes into a product goal, target user, problem statement, and expected outcome.
2. Define UX before UI — what's the user trying to do, what's the simplest path, where will they get stuck.
3. Design one screen at a time — priority elements, what's secondary, UX rationale, no visuals yet.
4. Critique, don't just generate — clarity, hierarchy, user flow, cognitive load, direct feedback.
5. Save it as a reusable workflow — so the process holds up across projects instead of being reinvented each time.