How detailed should a brief be?

Detailed on constraints and outcomes, deliberately loose on execution. Naming the exact typeface and layout removes the judgement you are hiring; leaving out the accessibility requirement or the fact that it must survive being faxed guarantees rework. Constrain the box tightly, then leave what happens inside it open.

What if I do not know what I want yet?

Then the first engagement is not the work — it is a paid discovery step that produces the brief. Trying to buy a finished artefact while the problem is still undefined is how scope creep starts, because the target moves as understanding improves. Separating the two is cheaper than discovering it mid-project.

Writing a client brief — outcome before artefact

Client Brief

Also: creative brief, project brief, design brief

A client brief is the document that states what a piece of work must achieve and for whom, before anyone decides what it will look like — describing the problem and the constraints rather than prescribing the solution.

Outcome first, artefact second

"We need a logo" is a request. "We need an identity that stays legible at sixteen pixels in a browser tab, works in a single colour on invoices, and does not read as a law firm" is a brief. The first invites a guess; the second can be satisfied or missed, and both parties can tell which happened.

This matters most on fixed-price work, where a supplier resolves ambiguity in whichever direction costs them least — not from bad faith, but because that is what fixed scope rewards. Every decision the brief leaves open is a decision someone else will make on your behalf, optimising for their constraints rather than yours.

The outcome, in a sentence someone could later check against the result.
Who it is for, and what they should be able to do or feel.
Hard constraints: formats, dimensions, brand rules, accessibility requirements, technical limits.
What already exists and must be worked with rather than replaced.
What success looks like — and, just as usefully, what would count as getting it wrong.

Key takeaways

→Describe the outcome and the constraints; prescribing the solution wastes the expertise you are paying for.
→Withholding context guarantees you get exactly what you asked for — which is rarely the same as what you needed.

FAQ

How detailed should a brief be?: Detailed on constraints and outcomes, deliberately loose on execution. Naming the exact typeface and layout removes the judgement you are hiring; leaving out the accessibility requirement or the fact that it must survive being faxed guarantees rework. Constrain the box tightly, then leave what happens inside it open.
What if I do not know what I want yet?: Then the first engagement is not the work — it is a paid discovery step that produces the brief. Trying to buy a finished artefact while the problem is still undefined is how scope creep starts, because the target moves as understanding improves. Separating the two is cheaper than discovering it mid-project.