“We need a new website” is a request, not yet a brief. So is a brochure, campaign, identity or CRM. Each names a possible output without explaining the change it is supposed to create.
1. What are we trying to make happen?
Describe the difference the work should make in plain language. A visitor should find the right service more easily. A sales team should spend less time retyping enquiries. A membership organisation should help more students reach the guidance they need.
A useful answer gives the project a decision-making tool. When an idea or requested feature appears, the team can ask whether it contributes to that change.
2. For whom, and in what situation?
“Everyone” hides the choices a project needs to make. Identify the people whose response matters most, what they are trying to do and what they already know, believe or find difficult.
Context matters as much as demographics. A confident repeat customer and an anxious first-time visitor can need very different things even when they look identical in a spreadsheet.
3. Why is change needed now?
Name the evidence behind the request. It might be customer feedback, an operational bottleneck, a change in strategy, poor performance or an opportunity the organisation cannot currently serve.
This separates a real requirement from accumulated preference and reveals what intelligence is still missing.
Brief the change, not merely the thing.
4. What is fixed, and what is assumed?
Budgets, deadlines, regulation and technology can create genuine constraints. Other boundaries are habits wearing the clothes of requirements. Label both honestly.
A good brief gives creative work enough structure to be relevant and enough freedom to find a better answer than the one first imagined.
5. What will tell us it worked?
Agree evidence before seeing the work. Measures might include task completion, quality of enquiries, staff time saved, response from a priority audience or qualitative feedback from the people affected.
Not everything valuable fits neatly into a dashboard, but every project should have an observable reason to exist.
The deliverables still matter. They simply arrive later in the conversation, after purpose, audience, context, constraints and evidence have created a reason for choosing them. That is when a request becomes a brief and making can begin with clarity.
Bring us the problem