A useful website brief explains the business, the people the site needs to reach and what those people should be able to do. It also names the content, connections and constraints that will affect the work. A couple of thoughtful pages can be enough to start a useful conversation.
You don't need to arrive with a finished sitemap or a chosen platform. Those decisions can be part of the project. The brief gives your designer enough context to ask the right questions and explain what their quote includes.
Start with the reason you're doing the project
“We need a modern website” leaves a lot open. Describe what has changed in the business, or what the current website is getting in the way of.
Perhaps your services have expanded and the website still describes the old offer. Perhaps sales keep explaining the same thing because the site leaves people confused. Or your team has to call a developer every time a staff member changes. Each problem points to different work.
Write down what you want to be different after launch. Pick an outcome you can check, such as a visitor finding the right service, completing a booking, or a staff member publishing a case study without help. If enquiries matter, agree how a useful enquiry will be counted and where the existing numbers come from.
Describe the customers and the decision they face
A website for a considered business purchase needs different information from a shop selling a familiar product. Explain who is visiting, what they already know and what usually makes them hesitate.
Bring questions from sales calls and customer emails. They are useful raw material. A customer asking whether you cover their location, work with their type of business or handle an existing system has given you a specific question the site can answer.
Also name the action you want each main visitor to take. That might be an enquiry, a purchase, a booking or a request for a detailed proposal. Asking every page to achieve everything makes the brief harder to act on.
Make an honest content inventory
List the material you already have and who can approve it. Include the logo files, brand guidance, photography, service descriptions, project information and any customer feedback you're permitted to use.
A folder full of photos doesn't necessarily mean the photography is ready. Some images might be too small, out of date or unsuitable for the way the new site needs to use them. Ask for an assessment before treating them as finished content.
Name the gaps too. If someone needs to write the service pages or arrange new photography, put that into the brief and the quote. It affects the sequence of the work even when the website itself is straightforward.
Name the connections and editing tasks
“A contact form” can mean an email in an inbox, a record in a CRM or a request routed to different people. Describe where the information needs to go and what should happen next. The same applies to bookings, payments, product stock, recruitment and newsletters.
For editing, use tasks your team recognises. Say “add a project with six photos and a testimonial” or “change a service description and preview it before publishing”. This is more useful than simply asking for a CMS. Our CMS guide gives you a short way to test those tasks.
You can list the systems involved without sharing passwords in the brief. Access can be arranged through an appropriate invitation or secure setup when it is needed.
Give references a specific job
Choose a few references and explain what you like about each. It might be the clarity of a service page, the way a project is shown, the typography or how the mobile menu works. Screenshots with a short note are fine.
Include anything you want to avoid. A reference helps communicate a preference; it doesn't automatically provide the photography, copy or functionality needed to make the same idea work for your business.
A brief you can fill in
- Our business and the change that prompted this project.
- The customers the website needs to reach, and their main questions.
- The action each main visitor should be able to take.
- What works on the current site, and what gets in the way.
- The pages, content and assets we already have, with any known gaps.
- The systems the website needs to connect to.
- The tasks our team needs to edit and who approves changes.
- References with a sentence about what we like.
- The budget range, timing constraints and person making the final decision.
A rough budget range helps a designer propose a sensible scope. If you don't know the range yet, say so and ask for options with the differences explained. A launch date should include the reason behind it, particularly if it depends on a campaign or an event.
What to look for in the response
A useful proposal should turn your brief into a clear scope, with assumptions, exclusions and responsibilities you can understand. It should explain the content work, review points, editing setup, testing and what happens after launch.
When two quotes differ, compare those details before comparing the totals. A proposal that includes writing and migration is a different project from one that expects all the content to arrive finished.
You can start with the brief you have now. The first conversation can help fill the gaps.