A website project brief should help your business and its website supplier make the same decisions for the same reasons. When the brief says only “we need a modern website”, every discussion depends on interpretation. One person expects a visual refresh, another expects more enquiries, and a third assumes the project includes replacing the booking system. Those differences usually emerge when work is already under way.
A useful brief makes the important assumptions visible before they become expensive changes. It explains the commercial problem, the people the website must serve, the journeys that matter, the content required and the conditions for accepting the finished work. You do not need to specify every technical detail yourself. You do need enough clarity for a supplier to recommend an appropriate approach and explain what their proposal covers.
Begin with the business problem and the visitor's task
Start by describing what is happening now. Perhaps prospective customers cannot distinguish between your services, quotation requests arrive without essential information, or your team cannot update important pages without outside help. Explain the effect on the business, rather than immediately prescribing a design solution.
“Our commercial customers cannot tell whether we handle planned maintenance or emergency repairs” is more useful than “add a large service menu”. The first statement leaves room to improve navigation, page structure, wording and enquiry routing together. The second commits everyone to a particular feature before the problem has been examined.
Next, identify the tasks visitors need to complete. A property manager comparing maintenance suppliers may need to check service coverage, understand response arrangements and send a specification. A homeowner may need to identify the right repair and request a callback. These journeys require different information, even if both ultimately reach an enquiry form.
The GOV.UK guidance on discovery research is a useful reference for understanding users and their existing experience. For a business website, interviews, sales questions and support records can help reveal where people currently struggle.
Set a small number of measurable outcomes
Choose outcomes that connect the website to the business problem. More traffic is not automatically a useful outcome if the additional visitors are unsuitable buyers. A clearer objective might be increasing qualified commercial enquiries, reducing incorrectly routed requests or making service information easier for customers to find.
For each outcome, record a starting point, a measurement method and who will review it. If you do not have dependable historic data, say so. Establishing a baseline can become an early project task rather than an invented number in a presentation.
- Qualified enquiries: define what makes an enquiry suitable and record that assessment in your CRM or enquiry register.
- Task completion: test whether representative visitors can find a service, understand its suitability and identify the next step.
- Operational efficiency: record how much information staff must request again after a form submission.
- Editing confidence: check whether the nominated content editor can complete common updates without damaging the layout.
Make a distinction between launch acceptance and later performance. A supplier can demonstrate that a form works and that tracking records successful submissions. They cannot responsibly guarantee a particular number of customers when your offer, competition, advertising and sales follow-up also influence the result.
Define the scope in terms of pages, journeys and responsibilities
A list of pages is a starting point, but it is not a complete scope. A service page may require original copy, photography, a testimonial, a downloadable specification and a tailored enquiry route. If the brief mentions only the page name, different suppliers may make different assumptions about those elements.
Create a page inventory with a purpose for each page. Record the intended audience, its main question, the action it should support and whether the content already exists. Include important supporting pages such as contact information, privacy information, resources and confirmation pages.
Then describe the journeys that cross those pages. For example, a visitor might arrive on a maintenance service page, check the area covered, download a checklist and submit a detailed enquiry. The scope should explain what happens after submission, including notifications and any transfer into another system.
Giraffe Digital's website design service plans structure, content and contact routes around these customer tasks. A brief organised in the same way makes it easier to discuss what the website needs to achieve.
Separate essential requirements from useful enhancements
Not every requested feature deserves equal priority. Give each requirement a reason, an owner and a launch priority. A feature is essential when the agreed visitor journey or an operational requirement cannot work without it. It is an enhancement when the website can meet its initial objectives through a simpler route.
Consider a business requesting an online quotation calculator. If every quotation depends on a site survey, a calculator might create misleading expectations. A structured enquiry form could be the more useful first release. The calculator may become appropriate later if the business develops sufficiently consistent pricing rules.
Record exclusions explicitly. If the website project does not include a CRM replacement, historic email migration or ongoing article writing, make that clear. An exclusion is not a refusal to discuss the work. It prevents an unpriced assumption becoming a surprise halfway through delivery.
Keep a separate list of future ideas. This lets people contribute improvements without expanding the launch scope whenever a new suggestion appears.
Document content ownership and approval
Website projects frequently stall because nobody has agreed who supplies the content or who can approve it. Your brief should distinguish between providing factual information, drafting copy, checking technical accuracy and giving final approval. Those jobs may belong to different people.
For each major content group, identify a named role and a deadline. Your operations team may confirm service coverage, a subject specialist may review technical descriptions, and a marketing lead may approve the tone and consistency. One accountable approver should resolve disagreements rather than returning every page to an open discussion.
Include practical content dependencies. Photography may require access to premises, permission from people appearing in images and coordination with a supplier. Case studies may need client approval. Product or service descriptions may depend on information that is not yet documented.
If existing pages attract useful search traffic, record the content and URLs that need reviewing before removal. A visual refresh should not casually discard explanations customers still use. Giraffe Digital's search engine optimisation service can connect those decisions with keyword intent, page structure and useful internal links.
Describe integrations and operational constraints honestly
List every system the website must exchange information with, including booking tools, CRM platforms, email services and payment providers where relevant. Record the current supplier, the business owner, the information involved and whether documentation or a test environment is available.
You do not need to promise that an integration is possible before it has been investigated. Mark uncertainties clearly. “We need successful enquiries added to our CRM; its integration options have not been checked” is a reasonable requirement. “Connect to the CRM in two days” is an unsupported assumption.
Also record constraints such as launch dates, trading peaks, domain ownership, hosting arrangements and staff availability. Explain why each constraint matters. A launch tied to an event has different planning implications from a preferred date chosen for convenience.
The GOV.UK explanation of discovery provides a useful reminder to understand problems and constraints before committing to a build. For a commercial website, that thinking helps separate decisions that need evidence from details that can be resolved during design.
Make quality requirements testable
Words such as fast, accessible and easy to use are important, but they need an agreed interpretation. Describe the tasks and conditions that will be tested. Identify representative devices, browsers, connection conditions and user needs, while allowing the supplier to recommend an appropriate test plan.
For an enquiry journey, acceptance criteria might include successful keyboard operation, meaningful form labels, understandable error messages, delivery of notifications and a clear confirmation. For content management, ask the supplier to demonstrate the editing tasks your team will actually perform.
Avoid demanding a perfect score in one automated tool as the sole definition of quality. Automated checks provide useful evidence, but they cannot fully establish whether a visitor understands a service or whether an enquiry reaches the correct team. Combine technical checks with task-based review.
Agree how findings will be recorded and resolved. A shared issue list should show the problem, its effect, the agreed priority and the evidence needed to close it.
Agree decisions, changes and handover before work starts
Your brief should explain who makes decisions and how quickly feedback is expected. A supplier cannot maintain a reliable delivery plan if every design approval depends on an unidentified group with different expectations.
Use one consolidated response for each review stage. Separate factual corrections from preferences and new requirements. “The emergency number is wrong” needs a correction. “We now want customers to upload videos” may change scope, hosting needs and testing.
Agree a change process that explains the effect on deliverables, timing and ongoing responsibilities before the change is accepted. This gives both sides a clear decision instead of leaving additional work hidden inside email discussions.
Specify the handover you need: editing guidance, access arrangements, ownership of approved assets, information about third-party dependencies, backup responsibilities and a support contact. Test the handover by asking your nominated editor to perform a real update.
Turn the brief into a working decision document
A good website brief is not a long document written once and forgotten. It is a concise record of the problem, the agreed scope and the decisions still needing evidence. Give it a version number, record important changes and use it when assessing proposals and approving work.
Before sharing it, check that a supplier can answer five questions: who is the website for, what must those visitors achieve, what work is included, what depends on your team, and how will the result be accepted? If an answer remains uncertain, label the uncertainty and plan how to resolve it.
For businesses coordinating website changes with content, analytics, hosting or customer follow-up, Giraffe Digital's digital strategy service can help establish priorities and dependencies. The immediate benefit of a stronger brief is simpler: fewer assumptions, more useful proposals and a website project that stays connected to the needs of your business and its customers.
