Reports & Presentation Decks

A report exists to move a reader from where they are to a decision or an understanding you need from them. Most weak reports fail because they are organised around how the work was done rather than what the reader needs - chronology instead of priority. The single most useful thing Claude does for a report is help you fix the structure before you write a word of it.

Start by asking it to propose an outline for your reader and purpose, then argue with it. A good stage report, shown in the figure, leads with an executive summary that states the decisions you need up front - not on page nine - then covers where the project stands, the design development and its reasoning, the status of cost, programme and risk, and finally the specific asks and next steps. That order is deliberate: a busy client reads the summary and the asks, and dips into the middle only where they care. Claude knows these conventions well and will produce a sound skeleton in seconds; your job is to bend it to this project - to decide what leads, what is cut, and what the reader must not miss.

Only once the structure is right do you let Claude draft the prose, section by section, from your bullets. Feed it your substance - the moves you made, the reasons, the status - and it returns clean, consistent paragraphs in your register. Work in pieces rather than asking for the whole report at once: a section at a time is easier to direct, easier to check, and less likely to drift into generic filler. Artifacts help here - a report drafted as an Artifact sits beside the chat where you can edit it in place across many passes, rather than scrolling through chat to find the latest version.

A report carries more hard fact than an email, and the same iron rule applies: Claude drafts the words; you supply and verify every number, and you make every judgement. In a stage report the danger points are specific and worth naming.

The cost and programme status is the sharpest. If you give Claude your figures, it will present them cleanly; if you are vague, it will produce confident numbers, percentages complete and dates that read as authoritative and are pure invention. Never let a cost or a completion date reach a client because it sounded right in a draft - every figure comes from your own source and is checked against it. The same holds for anything quantitative: areas, quantities, savings, performance claims.

Risk is the second. A good report tells the client honestly what could go wrong and what you are doing about it - and that assessment is a professional judgement Claude cannot make. It does not know which supplier is shaky, which approval is genuinely at risk, or which client decision is the real bottleneck. Ask it to help you articulate risks you name, never to decide what the risks are; a report that reassures where it should warn is worse than no report.

The third is the reasoning behind the design. Claude can turn your rationale into fluent prose, but if you have not supplied the actual why, it will supply a plausible, generic why - the empty "architalk" that experienced reviewers see straight through. The judgement, the trade-offs you weighed, the reasons this scheme and not another: those are the substance a report exists to convey, and they must be yours. Use Claude to make your thinking clear and readable, never to manufacture thinking you have not done.

A practical tell separates the two uses. When you feed Claude real substance - your figures, your reasons, your named risks - and it returns clear prose, that is the tool working as intended. When you find yourself impressed by a paragraph you could not have written because you did not actually know that fact, stop: that is the model inventing, and it is exactly what a sceptical reviewer will probe first. If you cannot stand behind a sentence from your own knowledge, it does not belong in a report with your name on it.

A presentation is not a report on slides - it is a different medium with a different job: to carry a room through your thinking to a decision, out loud, in a fixed time. The commonest failure is treating slides as a document to be read, cramming each with text until the audience is reading instead of listening. Claude, used well, helps you avoid this by working on the deck as a narrative before it is a set of slides.

Start with the arc, not the slides. Ask Claude to help you structure the talk as a story: the brief, the site and its constraints, the one central idea, how the scheme delivers it, and the ask - the shape shown in the figure. Give it your material and your time limit and have it propose a slide sequence with one idea per slide and a suggested headline for each. Then bend it to your project: which single move is the heart of this scheme, and does every slide earn its place in getting there? A deck is won by ruthless subtraction, and Claude is a useful foil for deciding what to cut because it will lay out the full set and let you strike.

Then the speaker notes - an underused Claude strength. For each slide, ask it to draft the spoken line: the sentence you actually say when that slide is up, not the text on the slide. This separates showing from saying, which is the core discipline of presenting well. But treat the notes as a starting script, not a teleprompter: rehearse each line in your own words until it sounds spoken, not written, because an audience can hear a read-aloud sentence and it flattens your conviction. The design is yours, the room is yours to win; Claude just gets the scaffolding up fast so you can spend your time rehearsing.

The pay-off of this workflow is not just speed; it is that structuring with Claude lets you spend your scarce hours on the parts that actually decide the outcome. But two disciplines keep it from going wrong.

First, the voice and originality check that runs through this whole module. A report or deck drafted by Claude and sent unedited reads as generic - the same balanced-sounding paragraphs, the same tidy transitions, the tell-tale flourishes - and generic is fatal in work whose whole purpose is to convey a specific, considered point of view. Feed it your past reports so it matches your register, then read the draft as a sceptical client or a hard juror would, and cut anything that could have been written about any project. The parts that make a report or a talk land - the sharp observation, the honest risk, the reason this and not that - are the parts only you can put in.

Second, a final verification pass appropriate to the stakes. Reports and decks are often the highest-visibility documents a practice produces; a wrong cost in front of a board, or a fabricated precedent in a design report, is a serious credibility hit. Before it goes out: every figure checked against its source, every claim you can stand behind, every risk honestly stated, and the ask unmistakable. Do that and Claude turns the report-and-deck grind - historically an evening-and-weekend job - into a focused afternoon, with more of your energy left for the thinking and the delivery that win the decision. That is the trade the whole module is built on: hand over the drudgery, keep the judgement, and check before it ships. A report or a deck is, in the end, an argument you are making to people whose decision you need - and an argument is only as strong as the person who stands behind it, which will always be you and never the tool.