From Client Conversation to Brief

The brief starts before Claude does. Your raw material is whatever you can honestly capture from the discovery conversation, and the richer and more faithful that capture, the better everything downstream works. In practice that means one of three things: typed or handwritten meeting notes; a recording you transcribe (many phones and meeting tools now produce a rough transcript automatically); or, at minimum, a brain-dump you dictate into your phone in the car afterwards while the conversation is fresh. None of these needs to be tidy. Claude does not care about order, grammar or repetition - in fact, the more complete and unfiltered the dump, the less you accidentally throw away a throwaway line that turns out to matter.

A crucial discipline here is separating what was said from what you concluded. When you dictate your car notes, mark your own inferences as inferences: "she said she cooks daily and hates being cut off from guests - I think that means an open or semi-open kitchen, confirm." That habit protects you later, because Claude will happily blend fact and inference into smooth prose that reads as if the client asked for an open kitchen when in truth you deduced it. Keeping the two visibly separate lets you and the client see which parts of the brief are their words and which are your professional reading.

Only once you have the raw capture do you bring in Claude - and the first move is not "write me a brief" but "help me structure what I have". Paste the notes or transcript in and ask Claude to organise them under headings, without adding anything. A prompt as plain as this works:

Below are my raw notes from a first meeting with a residential
client. Organise everything they contain under these headings:
Client & context, Goals, Users & lifestyle, Spaces wanted,
Budget, Site, Style & references, Timeline, Anything unclear.
Do NOT invent or assume anything - if something is not in my
notes, write "not discussed". Keep their own wording where you can.

[paste raw notes]

The instruction "do not invent" and "write not discussed" is doing real work. Left to itself, an LLM abhors a blank - it will fill an empty "Budget" heading with a plausible-sounding range because plausible continuation is what it does. Telling it explicitly to leave gaps visible turns that weakness into a feature: the empty headings become your to-do list for the next conversation.

A good brief captures not only what the client said but what they meant and what they never thought to mention. This is where an experienced designer earns their fee - and where Claude, used as a foil rather than an oracle, genuinely sharpens your thinking. Once your structured draft exists, run a second pass that asks Claude to interrogate it:

Here is my structured brief so far. Acting as an experienced
residential architect, tell me: (1) what important questions a
brief like this usually answers but this one does not yet;
(2) where the client's stated wishes may quietly conflict;
(3) assumptions I seem to be making that I should confirm.
Give me a short list of questions to take back to the client.

What comes back is not truth - it is a set of prompts for your own judgement. Claude might point out that "open plan" and "quiet home office" sit awkwardly together, that no one mentioned storage, that a growing family and a two-bedroom programme may not agree, or that "low maintenance" and "natural stone everywhere" pull in opposite directions. Some of these will be obvious to you and some will be off the mark - Claude does not know that the office is for occasional use, or that the client already owns the stone. But even the wrong suggestions are useful, because they make you articulate why they are wrong, which is itself a clarification of the brief.

The unspoken also lives in what clients avoid. Money, family tensions, resale anxiety, a spouse who is not in the room - these shape a project profoundly and rarely appear in a first conversation. Claude can help you prepare for them by generating the sensitive questions you might otherwise forget to ask: "What is the one thing that would make this project a failure for you?" or "Who else needs to be happy with this decision?" You decide which to ask and how; Claude just makes sure you walk into the second meeting with them ready.

Treat every one of Claude's observations as a hypothesis to test with the client, never as a finding to write down. The moment you let it assert - "the client needs a double-height living room" - rather than ask - "does the client want the living room to feel grand?" - you have let a plausibility engine put words in your client's mouth. The unspoken is drawn out by asking better questions, and Claude's real gift here is helping you ask them.

The fastest way to make this repeatable is to stop re-inventing the brief every time and instead keep a single template that reflects how your practice thinks. A brief is not a neutral form; the headings you choose reveal what you believe matters, and a good template quietly enforces your standards on every project. Build one once, keep it in a Claude Project (Module 1.2) as project knowledge, and every future brief starts from your structure instead of a blank page or Claude's generic guess.

A robust residential template has around ten sections: client and context; goals and success criteria; users and how they live; spaces and activities; budget and priorities; site and constraints; style, mood and references; programme and phasing; the unspoken and non-negotiable; and open questions to resolve. The exact list matters less than the fact that it is yours and it is consistent - the figure opposite shows a version you can adapt. The last two sections are the ones juniors and generic templates leave out, and they are the ones that save projects: an explicit place for what was implied but never stated, and a living list of what still needs confirming.

With the template loaded, your prompt becomes tighter and the output far more useful:

Using my practice brief template (in project knowledge), turn my
structured notes into a first-draft brief. Fill every section
from the notes only. Where the notes are silent, write the
heading and then "TO CONFIRM" with the specific question I need
to ask. Keep it factual and concise - no marketing language.

Two cautions keep this honest. First, the draft that comes back is a draft, and its confident tone is the trap: read every line as the client, not as the author, and strike anything you cannot source to something they actually said or you legitimately inferred. Second, a brief is a live document, not a monument. As the project moves, decisions change the brief, and the discipline of updating it - again, fast, with Claude - is what keeps it a true north rather than a fossil. The template makes the first draft quick; your judgement makes it right; and keeping it current makes it worth having at all.

There is a moment when the brief stops being a working draft and becomes the agreed foundation of the project - usually when you send it to the client and they confirm it. Everything about how you use Claude should be organised around making that moment trustworthy. The brief you send out carries your name and your professional judgement; if it contains a room the client never asked for, a budget figure Claude rounded into existence, or a "requirement" that was really your assumption dressed as fact, that is on you, not on the tool.

So build a simple final gate into your workflow. Before a brief leaves your desk, read it once in full against your raw notes - not the structured version, the original mess - and satisfy yourself that every claim traces back to something real. Pay special attention to numbers (areas, budgets, room counts, timelines): these are exactly where a language model's fluency is most dangerous, because a wrong number reads no differently from a right one. Anything Claude supplied that you cannot verify gets marked "to confirm" and goes to the client as a question, not a statement.

It helps to make the brief itself honest about its own status. A short line at the top - "This brief records our understanding from the meeting of [date]; items marked TO CONFIRM are not yet agreed" - protects everyone and sets the expectation that the brief is a shared, evolving agreement. Clients respect this; it signals rigour, not uncertainty. And when the client corrects something, you have both learned something real about the project, which is the entire point of writing a brief in the first place.

Used this way, Claude turns the worst part of the front end - the slow, error-prone transcription of a messy conversation into a usable document - into an hour's confident work, and it does so without ever taking the pen out of your hand. You heard the client. Claude organised the hearing. You decide what it means and you sign it off. That is the pattern for the rest of this module, and for the space program, adjacencies and stress-testing that follow.