01
Begin with outcomes, audiences and evidence
Describe what needs to change for the business and customer. Replace “we need a modern website” with observable needs such as clearer service enquiries, accessible booking information or reduced confusion about coverage.
List primary audiences, their questions and the evidence already available. Note where research or stakeholder approval is still required rather than inventing certainty.
- Current problem and desired outcome
- Priority audiences and tasks
- Existing website, data and evidence
02
Example: turn a feature request into a requirement
Instead of writing “add a portal,” explain that approved customers need to sign in, view project milestones, download selected documents and submit support requests, while staff need role-based control and an audit trail.
That detail allows a supplier to identify privacy, security, integration and support questions. It may also reveal that a smaller first release can meet the immediate need.
- User and task
- Information and permission
- Success and failure behaviour
- Owner after launch
03
Complete the actionable brief sections
Cover content, pages, features, integrations, brand assets, accessibility, security, privacy, search, analytics, hosting, migration, timeline and budget. Mark essential, useful and future requirements separately.
Name decision-makers and content owners, record procurement or technical constraints and explain how proposals will be assessed. Leave space for supplier questions and alternative recommendations.
- Prioritise requirements by business need
- Identify dependencies and third-party providers
- Set realistic approval and content dates
- Define acceptance and handover expectations
04
Common website brief mistakes
An overly prescriptive brief can lock the project into an unsuitable technology before discovery. A one-line brief at the other extreme makes quotations depend on conflicting assumptions.
Avoid copying another organisation’s requirements or using a wish list without ownership. Every feature adds design, content, testing, security and support consequences.
- Do not confuse visual references with requirements
- Do not hide budget or fixed deadlines that affect scope
- Do not make every idea essential
Practical next steps
Checklist
- 01State the business problem and desired outcomes
- 02Describe priority audiences and journeys
- 03Inventory content, evidence and brand assets
- 04Prioritise features and integrations
- 05Record budget, timing, risks and constraints
- 06Name approvers, owners and acceptance criteria
Common questions
Questions and answers
How long should a website brief be?
Long enough to explain important decisions and constraints clearly. A concise structured brief is better than an unprioritised document.
Should the brief choose the technology?
Only where a genuine constraint requires it. Otherwise describe the need and invite reasoned technical recommendations.
Do I need a final sitemap in the brief?
No. Share known content and journeys, while leaving room for discovery and information-architecture work.
Should I include the budget?
A realistic range helps suppliers recommend proportionate scope and avoid proposals that cannot be delivered within constraints.
Need a considered recommendation?
Discuss the website, not just the symptom.
AHANIX reviews each requirement manually. Technical recommendations may depend on access to the website, hosting or DNS configuration.
Continue learning