Design Brief
The problem, the constraints and the success measures, agreed before design starts.
Definition
A design brief records what is being solved and for whom, what is fixed, and how the outcome will be judged. It should be written before solutions are proposed.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this plate
Fill it in
Loading your draft…
Saved in this browser only. Nothing is sent anywhere.
Problem
Who has the problem, in what circumstance, and what it costs them. No solution words.
What you know and how you know it. Separate findings from assumptions.
The primary audience, and explicitly who it is not for.
Constraints
Technical, legal, commercial, brand and timeline limits that cannot be negotiated.
Naming these opens design space that would otherwise stay closed.
Success
Measures with a current baseline and a target, or a defined qualitative signal.
Scope boundaries recorded up front prevent expansion later.
Who signs off, who advises, and when they are involved.
Questions the brief has to answer
If a question here has no answer, that is the first thing to resolve, not something to discover halfway through the work.
- What problem is being solved, described as a situation rather than as a feature request.
- Whose problem it is, and what evidence says so.
- What is genuinely fixed: platform, deadline, regulation, existing commitments, the parts of the system nobody will change.
- What is explicitly out of scope, which is what prevents the brief expanding quietly.
- How the outcome will be judged, as a measure that could come out badly.
- Who decides, and who has to be consulted before that decision.
- What happens if nothing is done, which is the honest test of whether this is worth doing at all.
Agreeing it
Do
- Write it before a solution is on the table, while the problem is still the subject.
- State the constraints you were given and the ones you chose, separately.
- Get it agreed by whoever will approve the work, in writing.
- Revisit it when something changes, and record what changed rather than quietly rewriting it.
Do not
- Do not accept a brief that names the solution. Ask what problem it solves and start there.
- Do not set a success measure that cannot fail.
- Do not leave the deadline out because it is uncomfortable. An unstated deadline still governs the work.
- Do not write a brief so long nobody reads it. One page that is agreed beats five that are filed.
Local chart
TPL·010 · Region VIII · Grid G4
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Often used with
These usually appear in the same screen or the same decision.
- Design Brief to Wireframe DirectionAI·008 · AI workflow
- Jobs to Be DoneRES·018 · Research method
- Product SpecificationTPL·011 · Template
- Design CritiqueFLOW·001 · Workflow
- DiscoveryFLOW·004 · Workflow
- Problem FramingFLOW·007 · Workflow
Short definition
The one-paragraph version, for when that is all you need.
- Double DiamondTERM·110 · Term