How to prompt Claude: a guide for designers

Of two designers using the same tool, one says “brilliant, done in an hour” and the other says “it is useless, I would have been faster by hand”. Same model. The difference is in how they described what they wanted. Prompting is not a mysterious skill — it is writing a good brief, in digital form. Something you already know how to do.

What a bad prompt looks like

“Make the site nicer.” There is no information in that sentence for the model. Nicer to whom? Which part? Why is it not nice now? The model will do something — but it matching what was in your head is down to luck. Then you say “it does not understand”, when you expected it to understand something you never said.

The working version of the same request: “The hero feels crowded. Increase the space between the headline and the subtext, get the subtext down to one line, and left-align the buttons.” Same intent, now actionable.

1. Give context

The model can see your code but not your business. Say who it is for in one sentence: “This site is for a 24-hour towing company; most visitors arrive in a panic, on a phone.” That single sentence changes the quality of the next ten decisions — because now it can work out for itself that the call button belongs at the top and needs to be large.

2. Ask for one thing at a time

The most common mistake: eight changes in one message. “Change the colours, add contact to the menu, simplify the form, redo the footer…” The result is usually half done with one part misunderstood, and untangling what broke takes longer than doing it by hand.

Ask small and in sequence. You see the result at every step and you can undo a single step when you do not like it. That is not slower — it is faster, because it removes the time spent on repair.

3. Describe the outcome, not the method

Instead of “use flexbox with a 24px gap”, say “the spacing between the cards is too tight, let them breathe”. The first drags it down to your level; the second lets it use what it knows. Technical language has its place — but say what you want first, and specify how only when you genuinely care.

4. Show an example

When something is hard to describe, give a reference: “make the pricing table foreground the middle plan, like the pricing page on a well-known SaaS site”. One reference does what three paragraphs of description cannot. The same works for tone: “write the about section in the voice of this paragraph”, and paste a piece of writing you like.

5. State the acceptance criterion

The hidden weapon of professional briefs: writing down what counts as done. “Simplify the menu” is vague; “no more than five links in the menu, move the rest into a submenu” is measurable. With the second, the model knows when to stop.

The habit also disciplines you: if you cannot write the acceptance criterion, you probably do not yet know what you want. In that case think first and write second — do not try to make the model do the thinking.

6. Describe your corrections too

When you do not like the output, “no, try again” is the least productive response — you are rolling the same dice from the same place. Say what was wrong: “too formal, make it warmer” or “the headline is long, keep it under six words”. The model’s second attempt is only as good as your critique of the first.

Prompting is not a new skill. A designer who writes a good brief writes a good prompt — because both want the same thing: a clear request.

7. Say what you do not want

The least known and most useful technique. A model tends to fill any gap it sees — if you do not say what you do not want, it will helpfully add it. “Add a testimonials section but no star ratings”, “rewrite the copy but no emoji”, “simplify the form, do not add fields”. Those negative boundaries prevent work you would otherwise have to delete.

Accumulating context: the advantage of a long conversation

What beginners most often miss: as the conversation progresses, the model knows your project better. Your tenth instruction can be shorter than your first — because it now knows what you mean by “the hero”.

So opening a new conversation for every request is wasteful. Stay in the same conversation for the same project; accumulated context works in your favour. Only start clean when the subject changes completely — when you move to a different client.

The reverse is also true: if the conversation gets very long, the model starts forgetting the beginning. The moment you find yourself saying “wasn’t the button supposed to be orange?”, it is time to split. Summarise the important decisions in one message and carry them into a fresh conversation.

A prompt is a brief, not an order

Designers have an advantage here and most do not notice it. For years you have been trying to extract briefs from clients; trying to turn “make it cooler” into something you can act on. Prompting is the same job in reverse: this time you are the one giving the brief.

Which means that when you write a bad prompt, you are behaving like a bad client. Complaining about the client who says “make it nice” and then typing that same sentence to a model — there is an irony there, and noticing it is itself a correction.

Three common mistakes

• Politeness padding: “Hello, would it be possible for you to…” — the model is not moved by courtesy, it just has more trouble locating the request. Write directly.
• Starting over when you dislike the result: correcting inside the same conversation is almost always better than opening a new one, because the context is there.
• Stacking requests without looking: check the preview at every step; if you do not, working out which step broke what takes far longer.

Build your own pattern library

The habit that saves the most time and is practised the least: keeping the prompts that worked. Every designer’s work resembles itself — you work with the same kind of client, you build the same sections. So eighty per cent of your prompts repeat.

Open a notes file and paste in any request that produced a very good result, exactly as written. Six months later you have your own brief library — and that library is worth more than anything a tool gives you, because it knows your work. Even if the tool changes, the library stays.

Ready-made patterns for designers

Patterns that work for the requests that recur in daily work:

• Adding a section: “Under the services section, add a three-column testimonials block. Each card has a logo, a one-sentence quote and the company name. Drop to one column on mobile.”
• Changing tone: “Make all the site copy shorter and less formal. Remove sentences that make promises.”
• Layout adjustment: “Reduce the height of the hero so the services start to appear on the first screen.”
• Mobile fix: “On phones the menu button sits too close to the content, increase the top spacing.”
• Conversion: “Add a sticky contact button on every page; bottom right on mobile, smaller on desktop.”

Notice what those have in common: all of them answer where, what, and on which device. The formula really is that simple.

What to do when you cannot write the prompt

Sometimes you cannot describe what you want — you feel something is wrong but cannot name it. That is the hard moment of design, not of prompting; do not blame the model.

The trick that works: instead of describing, ask. “This section feels crowded to me but I cannot work out why — give me three possibilities.” The options that come back usually clarify your own thinking, and then you can write the right request. Here the model is a conversation partner rather than an implementer.

In short: give context, ask for one thing, describe the outcome, show an example, state the acceptance criterion, and talk while correcting. Those habits are the entire difference between the person saying “it is useless” and the person saying “done in an hour”.