A website brief should explain who the website serves, what those people need to do and what must work at launch. A request for a modern design, good visibility and a contact form leaves too much open: suppliers can quote entirely different projects under the same description.
You do not need a finished sitemap or technical specification. You need enough clarity for a supplier to propose the smallest complete solution and explain its boundaries.
Start with a business problem and a visitor task
“We need a new website” describes a purchase. “A visitor needs to understand whether our service fits and send a relevant enquiry” describes a useful outcome.
For each important visitor group, record its question, the information needed to decide, the intended next action and the doubt that could prevent that action. Include existing customers, applicants or partners where they genuinely have a different task. Every group does not automatically need its own page.
Identify useful pages and content
For each proposed page, ask whether it answers a separate question, contains enough original information and has a relevant next step. Include button labels, form instructions, confirmations and errors in the content scope. They affect whether the visitor can finish the task.
Separate launch requirements from ideas
Put each feature in one of three groups: required at launch, useful later, or still to investigate. A dashboard or AI feature needs a reason: what task becomes easier, faster or more reliable?
For an integration, describe which records move between which systems, the trigger, the owner and the response to failure. Naming two software packages is not an integration specification. A manual step or prototype can test an uncertain requirement before a full feature is commissioned.
Copy and complete this website brief
| Field | What to write |
|---|---|
| Business and offer | What you provide, to whom and in which market |
| Reason for the project | What is currently unclear, unreliable or difficult |
| Desired outcome | What a visitor or staff member should be able to do after launch |
| Main visitors | Their situations, questions and decisions |
| Main actions | Enquiry, booking, purchase or another task, ranked by importance |
| Pages | The question each proposed page owns |
| Available content | Existing text, images, project evidence and business details |
| Missing content | What needs writing, photography, design or approval, and by whom |
| Functions and integrations | Launch essentials, later work and assumptions to investigate |
| Constraints | Existing systems, languages, devices, security and access requirements |
| Ownership | Domain, hosting, code, content, accounts and transferable rights |
| Budget | A realistic range and the work that must fit within it |
| Planning | Hard dates, decisions, content delivery and feasible feedback rounds |
| Acceptance | How the important visitor tasks will be demonstrated and checked |
| Supplier selection | The criteria you will compare alongside price |
Make ownership and continuing costs explicit
Ask who controls the domain, DNS, hosting, source code, CMS, analytics, incoming enquiries, licences and backups. Access to an editing screen is not necessarily control of the whole website. Record what can be exported or transferred if the relationship ends and what depends on an ongoing supplier subscription.
Maintenance includes changing prices and service information as well as software updates. Name an owner for each responsibility. A technically functioning website can still misrepresent the business because nobody reviews its content.
Record budget and planning dependencies
Budget for the agreed work: strategy, design, development, copy, imagery, integrations, hosting, maintenance and support where relevant. A range is useful; false precision is not. For timing, identify dependencies rather than giving only a launch date.
Compare quotes against the same brief
Ask every supplier to identify deliverables, exclusions, recurring costs, content responsibilities and acceptance checks against this document. Differences then become visible before you sign.
The brief leaves room for a supplier to recommend a solution. It is not an instruction to build every idea. See how we approach projects, the website development service and our work. Use the website cost guide to separate cost categories, then assign continuing checks using the website maintenance checklist.