Prompting Claude for Design

A good design prompt usually carries six things, and you can remember them as a checklist: role, context, task, format, constraints, examples. You will not need all six every time - a quick question needs none of the ceremony - but when the output matters, the more of these you supply, the less generic the draft comes back.

Role gives Claude a vantage point to reason from. "Act as an experienced project architect reviewing a residential brief" pulls the response toward the register, priorities and vocabulary of that role, and away from a generic chatbot tone. Context is everything Claude cannot know unless you tell it: the project type, the site, the client, the stage you are at, the budget band, what has been decided already, what the constraints are. This is where designers under-invest most - Claude does not know your client, your city's byelaws or your last meeting unless you say so. Task is the single, plainly stated thing you want done: not "help me with the kitchen" but "propose three layouts for a galley kitchen in the plan below." One clear job beats a vague bundle.

Format tells Claude the shape of the answer - a table, five bullets, a 200-word paragraph, spec-clause style, a checklist. Ask for the shape you actually want to use and you save yourself a reformatting round. Constraints are the guardrails: the budget, the applicable code, the tone, the length, the materials to prefer or avoid, and crucially what to leave out. Examples are the most underused lever of all - paste one or two samples of the kind of output you want (a spec clause you like, a paragraph in your practice's voice) and Claude will match the pattern far more closely than any description could achieve. Giving examples is called few-shot prompting, and for anything you produce repeatedly it is transformative.

Specificity is the whole game. Every adjective you sharpen and every number you add narrows the space of plausible answers toward the one you want. Compare "suggest flooring for a living room" with "suggest three flooring options for a 320-square-foot living room in a humid coastal Goa villa, budget mid-range, low-maintenance, warm palette, suitable over an existing screed - give material, rough cost band, and one maintenance caveat each." The first prompt gets you a Wikipedia-flavoured list; the second gets you something close to a first-pass recommendation you can react to. You are not writing more words for their own sake - you are removing ambiguity, and each removed ambiguity is a decision you keep instead of surrender.

The most overlooked instruction is the negative one: telling Claude what not to do. Left to itself, Claude tends toward hedging, over-explaining, generic "design-speak," and long preambles. So say the opposite plainly: "Do not suggest anything over budget. Do not use marketing language. Skip the introduction and give me the options directly. Do not invent product names or prices - if you are unsure, say so." That last one matters most. Because Claude produces plausible text, it will happily fill a specification with a standard number or a product code that sounds right and is wrong. An explicit "if you don't know, say you don't know rather than guessing" measurably reduces confident fabrication - though it never eliminates it, which is why you still check.

Negative constraints also protect your voice and your scheme. "Keep it to plain, concrete language - no words like elevate, curate, bespoke, or journey" will strip out the architalk that makes AI writing recognisable. "Do not change the material palette I gave you; only reorganise the schedule" keeps Claude on task instead of helpfully redesigning things you had already settled. You are the one who knows where the lines are; drawing them explicitly is a large part of prompting well.

A related habit is to say which constraints are hard and which are soft, and to rank what matters when they collide. A real design task rarely optimises one thing; it balances budget against durability against look against lead time. If you simply list five wishes, Claude will guess at the priorities and usually guess the blandest compromise. Tell it instead: "budget is the hard limit; within that, prioritise low maintenance over appearance; warmth is nice-to-have." Now the trade-offs it proposes reflect your actual hierarchy, and when it has to give something up, it gives up the right thing. Making your priorities explicit is just good briefing - and it is exactly the kind of judgement a machine cannot supply for you.

The biggest shift for new users is realising that the first prompt is rarely the one that matters. Claude works in a conversation that remembers everything said so far in the same chat, so your real skill is steering - reading the first draft, seeing what is off, and correcting course in the next message. Expecting a perfect answer from a single prompt is like expecting a perfect drawing from a junior's first attempt before you have said a word about it. The loop from Lesson 0.1 applies exactly: you direct, Claude drafts, you judge, you refine - and the refine step is where quality actually appears.

Steering is concrete and specific, not "try again." If the options came back too expensive, say "these are all above budget - redo them under 8 lakh and tell me the trade-off for each." If the tone is wrong, "too salesy; rewrite it plainer, as if explaining to a busy client by email." If it missed something, "good, but you ignored the north light - factor that in." You can also ask Claude to improve its own work: "what are the three weakest points in this layout?" or "critique this spec as a strict site engineer would" often surfaces problems faster than starting over. Each turn is cheap, so iterate freely rather than agonising over the perfect opening prompt.

Two practical habits make iteration pay off. First, change one thing at a time when a draft is close - if you rewrite the whole prompt you lose the parts that were working. Second, start a fresh chat when you change direction - a long thread carries all its earlier assumptions, so if you have pivoted from a cafe to a co-working space, a clean chat with a clean brief beats fighting the old context. When you land on a prompt that works well, save it. A prompt that reliably produces a good FF&E schedule or a clean meeting-minutes draft is a small studio asset you will reuse for years - which is exactly what Modules 1.2 and 9.2 turn into a system.

One more iteration habit pays off constantly: ask Claude to show its options before it commits. "Give me three different directions for this, one line each, before you write the full version" lets you steer at the cheapest possible moment - a sentence in, not a page in. You pick the direction, then say "develop the second one." This keeps you in the driving seat of the idea while Claude does the legwork of expanding it, and it stops you from silently accepting the first plausible path just because it appeared first. Divergent then convergent, with you choosing the fork, is the shape of almost every good creative exchange with Claude.

Here is the difference in practice. A weak prompt for a common interiors task:

Help me write a spec for the bedroom flooring.

And a strong one for the same job, carrying role, context, task, format and constraints:

Act as an interior designer writing a material specification for a
contractor.

Context: master bedroom, 3BHK apartment in Pune, mid-to-high budget,
client wants warm, quiet, low-maintenance floors; existing sub-floor is
level cement screed; handover in 10 weeks.

Task: write a specification for engineered oak flooring for this room.

Format: numbered clauses covering (1) material and grade, (2) thickness
and wear layer, (3) substrate prep, (4) underlay/acoustic layer,
(5) installation method, (6) finish, (7) tolerances, (8) what the
contractor must confirm before ordering.

Constraints: plain contractor-facing language, metric units, no brand
names. Do NOT invent standard numbers or exact prices - if a standard
should be cited, write [VERIFY: standard ref] so I can fill it in.

The second prompt returns something you can edit in ten minutes instead of writing from scratch - and the [VERIFY] placeholders keep you honest about the one thing Claude must not fabricate. Notice you did not need clever wording; you needed to say what you actually wanted.

A final note on getting even more out of the harder tasks: for genuinely complex asks, tell Claude to think it through step by step before answering, or ask it to lay out its reasoning first and the recommendation last. On newer models this engages a more deliberate mode and tends to produce better-reasoned results on multi-part problems - a layout that has to satisfy several constraints at once, say. It is not magic, and it does not make the output true; it just makes the reasoning visible so you can check it. Keep a personal file of your best prompts, tuned to your practice, and your baseline quality rises every month without you learning a single new trick.