A website brief is not a shopping list of pages or visual preferences. It is a decision document. The strongest briefs give a team enough context to make good choices and enough constraints to know when the work is ready.
1. Start with the business change
Describe what should become meaningfully different: better-qualified enquiries, shorter sales explanations, easier publishing, stronger recruitment or lower operational risk. Name a baseline when one exists.
2. Define priority audiences and situations
“Everyone” is not an audience. Identify who has the highest-value problem, what prompts them to look, what they already know and what could prevent trust.
3. Inventory evidence and content ownership
List the proof you can substantiate, the content that exists, what must be created and who can approve it. Unowned content is one of the most common schedule risks.
4. Make functional behavior explicit
Document forms, integrations, permissions, error states, retention rules, consent, notifications and expected fallback behavior. A feature is incomplete until failure has a safe outcome.
5. State the non-negotiable quality gates
Include browser support, accessibility target, performance budgets, privacy obligations, search requirements, security controls and the exact acceptance process.
6. Clarify operations after launch
Name who owns hosting, domains, content, monitoring, updates, incident response and improvement. Launch is a transition of responsibility, not the end of it.