A useful website brief helps a team make decisions. It should explain who the website serves, what those people need to do, and what your business can realistically support after launch. A long list of pages is only one part of that conversation.
Write a first version before requesting proposals. Mark uncertain details as questions rather than filling the gaps with assumptions. Your development partner can then help turn those questions into a workable scope.
Start with the business outcome
Describe the problem in plain language. Perhaps enquiries arrive without enough information, customers cannot find your service area, or staff spend time explaining the same process. Choose a primary outcome and explain how you will recognise improvement.
For an enquiry website, useful measures might include relevant project requests and the proportion of requests your team can act on. Page visits alone do not explain whether the website is doing its job. Record your baseline if one exists; if it does not, plan how to collect it after launch.
Describe the people and their tasks
List the main visitor groups and the questions they bring. A purchasing manager may need capabilities and procurement information. A small business owner may need to understand the process and what to prepare. Give each group a clear next step.
- What must someone understand before contacting you?
- What information should they be able to find without asking?
- Which devices, languages or accessibility needs must the project consider?
- What happens after a visitor submits a form?
Include accessibility in the brief and acceptance criteria. W3C’s accessibility planning guidance recommends addressing it early and throughout the work. Treat keyboard use, readable content and form labels as planned requirements rather than a final visual check.
Inventory the content and responsibilities
List the essential pages, then assign an owner to each piece of content. Separate material already approved from material that needs writing, photography or legal review. Confirm permission to use every logo, image and testimonial.
| Item | Question to resolve |
|---|---|
| Service pages | Who writes and approves the scope and exclusions? |
| Project examples | Which details and images are approved for publication? |
| Contact form | Who receives enquiries and how are they followed up? |
Define functionality and constraints
Explain what each feature must do. “A contact form” is less useful than “an enquiry form that collects the service, company email and project summary, sends to the shared inbox, and clearly reports delivery failures.” Specify integrations, account access, hosting arrangements, migration needs and who controls the domain.
Share the available budget range and any deadline with a reason behind it. Identify fixed requirements and features that can wait. A launch date tied to an event may require a smaller first release rather than rushing every idea into production.
Agree on acceptance and ongoing ownership
Write down the checks required before launch: key visitor journeys, mobile layouts, form delivery, redirects, content approval and backups. Decide who can update the website, what training they need, and who handles maintenance.
A good brief makes the next decision easier. It does not need to predict every detail of the finished website.
Bring your draft, existing website and unanswered questions to an initial discussion. Our website development service can help turn that material into a scoped project. You can also discuss your requirements with IT Dev Hub.
Primary reference
W3C WAI: planning accessibility supports the accessibility planning advice above. The brief structure is our practical editorial guidance, not a prescribed standard.
