How to write a useful website brief
Write your website brief around the work you want to win, the customers you need to help and what the site must do. Include relevant proof, existing systems, budget and timing. Separate firm requirements from preferences, and identify decisions you need the designer or developer to recommend.
Our website planning starts with the business, customer and intended result. The worked brief below shows how to turn those inputs into useful direction, with room for an expert recommendation.
What should a website brief actually settle?
A website brief explains why you are commissioning the site and what it needs to achieve. Your first version should give a provider enough business context to ask better questions and recommend the work.
For an established service company, “we need a better website” leaves a lot unanswered. Do you want more of your current work, larger contracts, a different customer group or fewer unsuitable enquiries? Those choices affect what the site should explain and prove.
Start there. You can bring rough notes, existing sales material and examples of questions customers ask. You do not need to turn yourself into a web designer before speaking to one.
Keep four kinds of information distinguishable:
- Facts: what the business does, who it serves and what currently happens.
- Constraints: something the project must accommodate, with a reason it is fixed.
- Preferences: a direction you like, which can be challenged if another approach works better.
- Open decisions: something you need advice on, with a person responsible for resolving it.
For example, “our team must update completed projects” is a requirement. “We must use the same platform as a competitor” needs a reason. An existing company-wide technology requirement is different from a platform someone happens to like.
If you do not know an answer, write down the question and who will help resolve it. Guessing makes the brief look finished while leaving the decision unfinished.
Describe the need before making a feature mandatory
Give the provider the reason behind a feature request so they can recommend how to meet it.
Suppose your initial request is “we need fifteen pages”. That does not explain what any of those pages will do. A more useful brief names the services, customer questions and project examples that need a home. The provider can then recommend a page plan and explain what deserves a separate page.
The same applies to “we need to edit everything”. List the changes your team will actually make, who makes them and how often. Adding a project is a different task from changing the site's layout. Ask the provider to demonstrate the agreed editing tasks before accepting the setup.
Where a requirement is genuinely fixed, say so. If a booking system must remain because the business depends on it, name the system and the customer task it handles. Ask the provider to check how the new site should connect to it. You should not have to commission a replacement merely because the website is changing.
Example Website Brief: A Commercial Maintenance Company
This fictional brief shows how an established company could put those decisions into writing.
Business and customers
We maintain commercial properties and want more planned maintenance work from property and facilities managers. The site needs to explain our capabilities and make it easy to discuss a maintenance arrangement. Existing customers still need a direct route to request help.
Current site and marketing
Our current site lists services but gives little detail about recurring work. We plan to run search marketing after the rebuild; the proposal should separate the website work from ongoing marketing. Our office manager will check current enquiry records before we agree what improvement to measure.
Content and design
We can supply service facts, project examples and photographs, subject to customer permission. We need copywriting included and want advice on missing visuals. We will share design references with notes, then ask the designer to recommend the visual direction.
Functions and existing systems
New prospects need to describe their properties and required work. Our team needs to add projects and update selected services. Please recommend how those edits should work.
Email must keep working. We will confirm who manages the domain, email and hosting, and share access securely outside this document. A portal has been suggested, but no customer task currently justifies it.
Budget, timing and approvals
The director will confirm the available investment before scope is agreed. We would like the site ready before our planned marketing launch, but that date is flexible. Our marketing lead combines feedback; our operations manager checks service facts.
Decisions still to resolve
| Open decision | Who needs to resolve it | Before which step? |
|---|---|---|
| Available budget | Director | Agreeing the build scope |
| Recommended pages and editing setup | Provider, with marketing lead | Agreeing the detailed website plan |
| Permission for project photos | Marketing lead, with relevant customers | Using those images |
| Enquiry routing and responsibility | Office manager, with provider | Approving the enquiry flow |
| Marketing launch and website timing | Marketing lead, with provider | Committing to the schedule |
Copy this website brief template
Copy these fields into a document or email and replace the brackets with your business information. Rough answers are fine. Name someone to help with anything unresolved.
- Business and priority work: We provide [services]. We want more [work/customer type]. We do not want to promote [work we are moving away from].
- Customers: Our priority visitor is [person making the buying decision]. They need to understand [key questions]. Existing customers still need [information or action].
- Reason for the project: We have observed [current problem or change in the business]. We still need to check [assumptions].
- Website's job: Visitors should be able to [understand, assess or do something specific]. The site will support [actual marketing activity or customer contact].
- Current site and systems: Keep [useful content, tools or services], because [reason]. Review [what is open to change]. [Person] manages the relevant accounts.
- Content and proof: We can supply [accurate information and genuine evidence]. We need help with [missing material]. [Person] checks facts and permissions.
- Functions and editing: Customers need to [task]. Our team needs to update [content] about [frequency]. [Request] is [required/preferred/recommendation needed], because [reason].
- Design direction: The site should communicate [relevant impression]. We like [reference] because [specific reason]. [Brand requirements] are fixed; [preferences] are open to advice.
- Budget and timing: Our available investment is [approved range/needs discussion]. Our preferred launch is [date or event]. It is [fixed/preferred] because [reason].
- People and open decisions: [Person] combines feedback; [person] approves expenditure and direction. Resolve [question] with [person/provider] before [affected decision].
Under any request, add one of these descriptions where useful: required, preferred, or recommendation needed. Explain the reason. Avoid marking everything required, or the distinction stops helping.
If you do not know what the work should cost yet, say that and ask for an initial indication. Keep an undecided budget visible rather than inventing a figure to complete the template.
For a fuller material list, use our website content preparation guide. You can identify what is available in the brief, then organise the actual collection as the project takes shape.
Who writes the brief, and what happens next?
Someone who understands the business should own the first version, usually the owner or marketing lead. Bring in the people who know how sales, service delivery and customer support actually work.
One person should combine that input. A designer needs to know which feedback is the company's decision, particularly when several people have different preferences.
The provider then investigates the open questions, tests feasibility and recommends the website plan. If the recommendation changes your initial request, ask them to explain why. Record what you accept, what remains unresolved and what the agreed project includes.
A brief starts that conversation; the accepted proposal or agreement confirms the scope. Asking for a function in your brief does not establish that it is included in a quote. Check the written inclusions, exclusions and responsibilities before approving the work.
Copy deserves an explicit answer too. With SOL, we write the agreed website pages from your business information, rough material and feedback. You remain responsible for factual accuracy. Confirm any specialist content or additional writing separately.
If you are still comparing providers, our questions to ask a web developer cover how to examine their recommendation and scope. For the wider planning sequence, see planning a website for an established service business.
Bring the business context. We can work through the build.
Our web development service brings research, copy, design and development together around the agreed website job. Send us what you know about the business and what needs to change. You can leave the unanswered technical questions in the brief.
SOL STUDIOS is Australia's leading design and digital systems studio for established businesses.
Contact Us
