Begin with the business situation.
Explain why the project is happening now. Perhaps the offer has changed, the current site is difficult to update or enquiries arrive without enough context. Describe the problem in observable terms rather than starting with a preferred visual effect or a list of features.
Name the main audience and the action you want them to take. If there are several audiences, prioritise them and explain where their needs differ. A project becomes easier to scope when the team understands which customer journey must work especially well at launch.
Describe the offer and the information it requires.
List the priority services or products, the situations they suit and the questions people ask before buying. Include important limitations: coverage, eligibility, language, delivery or any required assessment. These details help the team plan content that attracts an appropriate enquiry.
Collect the evidence you can actually publish: approved project examples, photographs, credentials and testimonials. Note who owns the material and who must approve its use. Mark missing content honestly so the proposal can include creation or sourcing rather than assuming it already exists.
Follow the customer action all the way through.
Describe what should happen after a form, chat, booking or purchase action. Where does the information go, who reviews it and what does the customer receive? Include the systems already in use and any restrictions on how accounts or data may be handled.
For a lead website, decide which details help the team take the next step. A short initial brief might collect the service, intended outcome, location where relevant and contact details. More complex information can follow through an appropriate process once the request has been assessed.
State constraints and decision responsibilities.
Share the target timing, available budget range if known and any fixed launch dependencies. Identify the person who can approve scope and the reviewers responsible for content, brand or specialist requirements. If a deadline depends on material still being created, make that dependency visible.
Provide a few references with a reason for each. Explain whether you like the clarity, typography, navigation or tone rather than asking the team to reproduce another site. Also identify existing brand assets and the parts of the identity that are open to change.
Define what a complete launch means.
Agree the initial pages, content ownership, lead journey and essential integrations. Include search access, analytics, testing and handover where they belong in the scope. A shared definition of completion prevents a visually finished site from hiding unfinished operational work.
For a first conversation with Surf, send the current URL if available, a description of the business, the priority services and the main customer action. Add the desired timing and known dependencies. We can use that starting point to identify the decisions needed for a concrete project scope.
Your planning checklist
- Describe the business problem and priority audience.
- List services, buying questions and approved evidence.
- Explain the complete enquiry or purchase workflow.
- Name the approver and distinguish fixed requirements from ideas.
Common questions
How long should a website brief be?
It should be long enough to explain the business, audience, intended action and known constraints. A clear page or two can be a useful starting point; detailed functionality can be developed during planning rather than guessed in advance.
What if we do not have copy or a finished brand yet?
Say so in the brief. Writing, image sourcing and brand development can be scoped explicitly, with review responsibilities and dependencies. The project is easier to plan when missing inputs are visible from the beginning.
