A brief should frame a decision
A useful brief explains why the project exists and what needs to be different when it is complete. “A modern website” is a preference; “help procurement teams understand our offer and route qualified enquiries” is a business problem a team can investigate.
Describe priority audiences, their current journey, frequent objections and the action each should be able to take. Share existing analytics, sales insights, research and content rather than asking the web team to infer the market from competitors.
Include the inputs that shape scope
List required content types, languages, integrations, accessibility expectations, legal reviews, hosting constraints and internal owners. State what is fixed and what is open to recommendation so estimates do not depend on hidden assumptions.
Clarify governance: who gives input, who approves and who will maintain the result. A strong process can still stall when every stakeholder is invited late and no one owns a final decision.
- Business objective and priority user groups.
- Current evidence, pain points and working elements.
- Content, integration and compliance requirements.
- Decision process, timing and practical constraints.
Leave room for the team to solve
Define success using observable changes such as better-qualified enquiries, easier publishing, fewer support questions or improved completion of a key task. Include baseline data where available, while recognising that a website cannot control every commercial outcome.
Avoid prescribing every page and visual treatment unless they are genuine constraints. The brief should give the team enough context to challenge the proposed solution and explain trade-offs, not reduce discovery to order-taking.