An invented but familiar scenario. The client said "something warm but modern, not too busy" and "we're flexible on budget." Six weeks and two redesigns later, it turns out warm meant timber everywhere, modern meant no ornament at all, and flexible meant 10 percent. Nobody lied. The brief was never written down in words that could be disagreed with.
That's the job AI can do well in a design practice: take loose conversation and force it into a structured document the client can confirm or correct. It can't design the building or know your client. It can make vagueness visible early, when fixing it costs a meeting rather than a rework.
This post covers three documents: the client brief, the scope of work with exclusions, and the change request. All prompts are untested templates, and the worked example is invented and labelled. Nothing here is legal or professional advice; contract wording and fee terms should come from your own agreement, your professional body's standard form or a lawyer.
What goes into a client brief that actually helps?
A brief that helps you design has seven parts. In my experience of reading templates like this, the third, fifth and seventh are the ones people skip (a view, not measured).
- Project facts: site, size, type, who decides.
- Goals: what the space must do, for whom.
- Constraints: budget range, deadline, regulations you already know, existing conditions.
- Preferences: styles, materials, references, dislikes.
- Priorities: what wins when two goals conflict.
- Stakeholders: who must approve what.
- Unknowns: questions still open.
The prompts below are built around making the model give you all seven and mark where the information is thin.
Prompt 1: meeting notes to a brief
You are helping an architect/interior designer write a client brief from
meeting notes. Output a brief in this structure:
1. Project facts 2. Goals 3. Constraints 4. Preferences (likes and
dislikes separately) 5. Priorities 6. Decision makers 7. Open questions
Rules:
- Use only what is in the notes. Label each item [STATED] or [INFERRED].
Prefer fewer inferences.
- Where the client used a vague word (modern, warm, flexible, minimal,
budget-friendly), list it under VAGUE TERMS with two or three concrete
readings I could ask the client to choose between.
- Write numbers exactly as given. If the budget is unclear, write
[BUDGET UNCLEAR] rather than a range.
- End with the ten most important questions I still need answered, ordered
by how much each could change the design.
NOTES (client names removed):
[PASTE NOTES]
The VAGUE TERMS section is where most of the value sits. "Warm" becomes "timber and brass accents, or warm white walls and soft lighting, or earthy terracotta and clay tones?" The client points at one, and a misreading is caught before anything is drawn.
Prompt 2: a client question list before the first meeting
I am meeting a client about [PROJECT TYPE: e.g. a 2-bedroom flat renovation,
a small clinic fit-out, a house extension] in [CITY/REGION].
Write a question list for the first meeting, grouped as:
- How they live or operate day to day
- What currently doesn't work
- Budget, timing and who approves
- Taste: show-me questions I can ask using reference images
- Constraints: building rules, society/landlord approvals, existing services
- Things they might not have thought of
Mark the questions most likely to change the scope. Keep it to 30 questions.
Do not state any regulation or code requirement as fact; if a question
involves regulations, phrase it as "Has anyone checked ... with [authority]?"
The last instruction is deliberate. Planning rules, building codes and approvals vary by place and change over time, and a chatbot's recollection of them is not a source. Ask the question, then check with the relevant authority or your local professional.
Prompt 3: scope of work, with exclusions
A scope isn't complete until it says what's not included. Write both halves.
Draft a plain-language scope of work for [SERVICE: concept design / full
interior design / architectural design through to tender / site visits only].
INCLUDED STAGES AND DELIVERABLES (from my fee proposal, use my wording):
[PASTE STAGES, DELIVERABLES, NUMBER OF REVISION ROUNDS, MEETINGS]
Produce:
A. What you get (stage by stage, deliverable by deliverable)
B. What is NOT included (list at least 10 items typical for this kind of
service that a client might wrongly assume are included; mark each
[CONFIRM FITS MY PRACTICE])
C. Assumptions this fee depends on (client decision times, access to the site,
accuracy of client-supplied drawings, etc.)
D. What I need from the client, and by when ([DATES])
E. How changes are handled: refer to the change request process.
Do not state prices, legal terms, liability limits or regulatory
responsibilities. Mark any place where those would normally be mentioned as
[LEGAL/CONTRACT WORDING: take from my agreement].
Read section B carefully. A model will often list things you do include, or miss one that has burned you before. Edit it against your own history. Your last three disputed projects are better input than any generic list.
Prompt 4: change requests that get answered
Scope creep rarely arrives as a big demand. It arrives as "could we just..." in a WhatsApp message. The antidote is a standard form you send every time.
Turn this client message into a change request note.
Client message (verbatim): [PASTE]
Current agreed scope for the relevant stage: [PASTE]
Output:
1. What the client is asking for, in one sentence.
2. Is it inside the current scope? Answer INSIDE, OUTSIDE or UNCLEAR, and
quote the scope line that decides it.
3. If OUTSIDE or UNCLEAR: what additional work it involves, listed as tasks.
4. Questions I need to answer to estimate cost and time:
[list; do NOT estimate numbers yourself]
5. A short, friendly note to the client (under 120 words) that confirms
what they asked, says it is outside/under review, and asks them to
approve a quote before work begins.
Do not blame the client or imply they should have known.
The model is told not to estimate hours or fees. You know your rates and how long the thing takes. A made-up number in a client message is worse than none.
Prompt 5: turning options into a decision
Clients freeze when given ten finishes. Use AI to make a short comparison, then you recommend.
Here are three options for [ELEMENT: flooring in the living area / facade
treatment / kitchen layout]:
[OPTION A: description, supplier quote, lead time]
[OPTION B: ...]
[OPTION C: ...]
Make a comparison table: cost (use only my numbers), lead time, maintenance,
fit with the brief's priorities: [PASTE PRIORITIES], and the main risk of
each. Then write a 3-sentence note to the client that states which option
best fits their stated priorities and why. Flag any claim about durability,
fire rating, or performance as [VERIFY WITH SUPPLIER DATA SHEET].
Product performance, fire and structural claims must come from data sheets and the engineers, not from a model's summary.
A worked example (illustrative)
An invented scenario, not a real client. A family says: "We want an open, airy kitchen, nothing too fancy, and we'd like to finish before the festival season."
Running Prompt 1 on a page of notes like that should surface, in the VAGUE TERMS section, something like:
- Open: remove the wall to the living room, or keep it with a wide opening?
- Airy: more daylight, lighter finishes, or higher ceilings?
- Not too fancy: standard laminate cabinets, or something mid-range like painted wood?
- Before the festival season: which date, and is it a hard deadline or a hope?
The date question changes the scope more than any design choice. If it's a hard deadline, material lead times and contractor availability drive the plan, and you would want that written into the assumptions section of the scope. This is the sort of thing a good question list brings out before anyone is angry.
Failure modes to check for
| What goes wrong | Why | What to do |
|---|---|---|
| Brief reads confidently but invents preferences | Models fill gaps with typical taste | [STATED] / [INFERRED] labels; client confirms |
| Scope exclusions are generic | The model doesn't know your practice | Edit against your past disputes |
| Code or planning rules stated as fact | Recollection, not a source | Phrase as a question; check with the authority |
| Invented costs or timelines | Plausible numbers | Forbid estimates; use your own |
| Performance claims about materials | Marketing-style summaries | Data sheets and engineers only |
| Client details in the prompt | Convenience | Placeholders; approved tools only |
What not to automate
- Design judgement and the actual design. The brief is the input to your thinking, not a substitute for it.
- Fees, liability and contract terms. Use your agreement or a standard form, reviewed by someone qualified.
- Structural, fire, services and code compliance. These belong to the relevant engineers and authorities.
- Sending a brief or scope the client hasn't had a chance to correct. The point is agreement.
- Anything with identifiable client data in an unapproved tool. Placeholders first; see the AI use policy template and what to tell clients about AI use if clients ask how you work.
For the general habit of giving a model enough context to produce something usable, giving context explains the pattern, and AI prompts for consultants and freelancers covers proposal writing in more depth. If you also write listings or marketing for finished projects, the prompt library has templates to adapt.
