The Design Rationale & Story

Before touching Claude, be clear about what a rationale is and who reads it. A design rationale is the honest account of why the design is the way it is - the thread from the brief and site, through your concept, to the decisions a viewer can see in the drawings. It exists to do a job for a reader: to help a client feel confident they are getting what they asked for, to help a planning officer see that you have addressed context, to help a juror grasp the idea in ninety seconds, to help your future self remember what you were thinking. A good rationale makes the design legible. A bad one makes it suspicious - because a reader who senses that the words are decoration stops trusting the drawings too.

That framing matters because it tells you what the rationale must contain: real reasons, tied to real decisions, pitched at a real reader. "A dialogue between old and new" is not a reason - it is a mood. "We kept the old brick spine and set the new work back from it in board-marked concrete, so the two eras read as distinct layers rather than a pastiche" is a reason, because it points at something built and says why. The difference is the whole game, and it is exactly the difference Claude will smooth away if you let it write unsupervised.

So the workflow in this lesson is not "ask Claude for a rationale". It is: you supply the decisions and the reasons - even as rough bullets - and Claude helps you turn them into prose that is coherent, well-structured and readable, in your voice, with nothing added that you did not actually do. The rest of this lesson is how to run that reliably, and how to catch it when Claude quietly tries to make your building sound like every other building.

The single most useful rationale workflow is the bullets-to-prose pipeline in the figure, and it works because it puts the truth in before the fluency. You start by dumping your real decisions as rough bullets - ugly, honest, in any order:

Help me turn these decisions into a 180-word design rationale for a
client report. Keep my reasons exactly - do NOT add new ones. Plain,
warm, first person plural. Here are the bullets:
- long thin north-south plot, so living spaces along the east edge for
  morning light, service band on the hot west
- kept the existing tamarind; the plan bends around it, it shades the
  courtyard
- client hates AC; deep verandah + cross-vent instead
- budget tight, so one material palette: local laterite + oxide floors
- flood line at back, so plinth raised 900mm, garden steps down to it

What comes back is your argument, made continuous - transitions supplied, order tidied, repetition removed. Because you gave it the reasons, it is not inventing; it is arranging. Then comes the step that keeps the writing yours: you edit. You cut the word that sounds like a brochure, restore the phrase only you would use, and shorten the sentence Claude made too grand. The figure marks two owned steps at the end for a reason - edit for voice, then verify every claim - and neither is optional.

Two instructions dramatically improve the draft. First, forbid additions explicitly - "do not add reasons I did not give you" - because a model asked to write a rationale will helpfully invent plausible extra justifications, and those are the ones that get you caught. Second, name the reader and the register - "for a planning officer, formal and specific" versus "for the client, warm and plain" - because the same decisions want very different prose for different eyes. Give it the truth, the reader and your voice, and Claude does the genuinely tedious part - making it flow - while the substance stays entirely yours.

Architalk is the house style of un-owned design writing: grand, abstract, agreeable, and empty. "The building engages in a dialogue with its context." "A journey of light and shadow unfolds." "The design celebrates the intersection of tradition and modernity." These phrases feel like writing but carry no information, and a large language model produces them by the yard, because they are the statistical centre of everything ever written about buildings. If you draft with Claude and do not actively push against this, architalk is the default you will drift toward.

The figure sets the two registers side by side. On the generic side, every line is true of almost any project and pinned to nothing. On the grounded side, every line points at a specific, checkable decision on this site: the plan bends to keep the tamarind; openings are sized to the river breeze, not the road; the brick is reused from the shed it replaces; the stair is the one cool room in May. The test is simple and worth applying to every sentence: could this line appear, unchanged, in the rationale for a completely different building? If yes, it is architalk, and it should be cut or grounded.

You can put Claude to work as the architalk detector, not just the generator. After a draft, prompt: "Go through this rationale and flag every sentence that could describe almost any building. For each, either tie it to a specific decision from my bullets or delete it." It is genuinely good at spotting its own vagueness when asked to. You can also brief it up front - "no abstract claims, no words like dialogue, journey, seamless, celebrate; every sentence must name a real decision." But do not trust the machine to police itself completely. The final read is yours, out loud if you can, hunting for the smooth sentence that says nothing. Your voice, and your specificity, are the things that make a rationale sound like a person who made choices rather than a template that was filled in.

A rationale is not just true sentences - it is an argument with a shape, and shape is another thing Claude helps with. Most strong rationales follow a simple arc: the situation (brief, site, client, the real problem), the idea (your concept, in a line), the moves (the specific decisions that deliver it), and the result (what the reader gets - the feeling, the performance, the value). You can hand Claude your material and ask it to propose that structure before it writes a word: "Here are my decisions. Suggest an order that builds an argument from problem to idea to moves to result - as a bullet outline first, no prose yet." Approving an outline before prose is written saves you from editing a beautiful paragraph that argues in the wrong order.

Match the length and register to where it lands. A client report wants warmth and plain words; a competition panel wants compression and punch; a planning statement wants sober specificity and the language of the policy it answers. The same set of decisions can become a 60-word caption, a 200-word statement, or an 800-word report section - and Claude is fast at all three from one source, which is a real gift when the same project has to be described five ways.

Then the non-negotiable: honesty. A rationale is a set of claims about what you did and why, and a submitted rationale is a professional document. Never let Claude add a reason you did not have, a performance figure you did not calculate, or a contextual reading you never made - and read the final draft specifically hunting for anything that sounds better than the truth. The seductive failure here is not clumsy writing; it is a beautifully written sentence claiming a virtue your design does not have. Claude will produce that sentence cheerfully and without warning, because it reads as plausible. Your job is to strike it, keep the story to what you actually did, and sign your name to something real. A rationale that is true and specific always beats one that is grand and hollow - and only you can tell the difference.