Mind Mapping a Client Brief Before Your First Sketch

The most expensive mistake in design work happens in the first week, and it looks like productivity: the brief arrives, and someone starts sketching.

Here's the problem. The document the client sent is not the brief — it's the artifact of the brief. The actual brief is a tangle of stated wants, unstated assumptions, contradictions the client hasn't noticed, constraints they forgot to mention, and at least one requirement that means something different to them than it does to you. Sketch against the artifact and you'll produce a competent answer to the wrong question — discovered, expensively, at the first presentation.

The antidote is an unpacking session before any geometry: take the brief apart, lay every piece where the whole team (and the client) can see it, and find out what you actually know versus what you've assumed. A mind map is the right instrument for this — not because mind maps are magic, but because the brief's problems are relational (this requirement conflicts with that one; this assumption underlies those three decisions), and relational problems need a spatial medium, not a list. Here's the method, using AnchorMind — free, browser-based, and local-first, which matters when the brief you're dissecting is confidential.

Step 1: Dump the artifact — every claim becomes a node

Start with the project at the centre and go through the client's document line by line, turning every distinct claim into its own node. Discipline matters here:

One claim per node. "Modern 200-seat auditorium with excellent acoustics, also usable for exams" is four nodes — 200 seats, modern character, acoustic performance, exam mode — because each will be interrogated separately, and two of them may turn out to fight each other.

The client's words, preserved. Don't translate yet. Write "impressive lobby," not "double-height entry" — the translation is a design decision you haven't earned, and preserving the original phrasing keeps visible exactly where interpretation will later happen.

Nothing filtered. The throwaway line in the email ("parking is always a nightmare here") goes on the map with everything else. Throwaway lines are frequently load-bearing.

Cluster nodes into natural branches as you go — spaces, performance, character, budget, site, operations, politics. Twenty minutes with a typical brief yields forty to eighty nodes, and the first revelation is usually the map's shape: six branches about image and two about function, or a budget branch that's nearly empty. The brief's emphasis — and its silences — become visible before any analysis.

Now the real work. Walk every node and tag it as one of three kinds:

• FACT — verified, documented, true. (The lot's title area. The stated budget, if written.)
• ASSUMPTION — believed but unverified. (That "200 seats" was calculated rather than guessed. That the budget includes fit-out. That the stakeholder who wrote the brief speaks for the one who signs.)
• QUESTION — known unknowns. (What does "modern" mean to this client? Which requirement wins when acoustic performance meets exam-mode flexibility?)

Use colour or a prefix — the mechanism doesn't matter; the ruthlessness does. A well-run interrogation converts a shocking share of the map from FACT to ASSUMPTION, and that conversion is the value: every assumption you surface now is a redesign you don't do later. Then draw the cross-links — AnchorMind's dependency arrows — between nodes that constrain each other: the seat count drives the space, which fights the site branch's setback note, which connects to the parking lament. The map stops being a tidy radial diagram and starts being honest.

Pro tip: Hunt specifically for the brief's inherited numbers — figures the client states with confidence because a previous consultant, a committee, or a template put them there years ago. "200 seats," "3,000 m²," "40 parking slots." Ask where each number came from. In a distressing fraction of projects, a core sizing number traces back to nothing at all — and the earlier you catch it, the cheaper the correction. This is the single highest-yield question in brief interrogation.

Step 3: Convert — the map becomes three documents

The interrogated map exports directly into the three things the project needs next:

The question list for the client — every QUESTION node plus every high-stakes ASSUMPTION, organised by branch. Sending this before the first workshop transforms that meeting: instead of presenting sketches and hoping they surface the misunderstandings, you resolve the misunderstandings first, in writing, cheaply. Clients, almost universally, read a sharp question list as competence.

The requirements baseline — the FACT nodes and the assumptions the client confirms, restructured into your requirement register or, for spatial requirements, fed straight into a space program (the natural next tool is SpaceFlow, where nodes become spaces with areas and the cross-links become adjacency relationships — the map's tangle, made quantitative).

The risk memo — the assumptions the client couldn't confirm and the contradictions they declined to resolve. These don't disappear because a meeting ended; they go on record, dated, as the project's known fault lines.

Why before, not after

Everything above costs half a day. Its yield is a first sketch that answers the interrogated brief instead of the artifact — which typically means one fewer full redesign cycle per project, and a client relationship that starts from "they asked the questions no one else asked" rather than "the first scheme missed the point." The half-day also produces the map itself: a living document worth keeping open through the project, because briefs don't stop moving after kickoff — and a map with dated status tags is the cleanest record of when a requirement changed and what it dragged with it.

Take the brief currently sitting in your inbox and explode it this afternoon:

Open AnchorMind → — free, no account, and the brief stays on your device.