What should you put in a website brief?

Explain the job the website needs to do

A brief that says 'modern, professional and easy to use' leaves most of the important questions unanswered. Who is arriving? What do they need to understand? What should happen when they decide to contact you?

Start with the business and the customer. A fictional joinery company might want homeowners to understand its fitted-furniture work and send enough project detail for a useful first reply. That gives the design a direction. A request for a fashionable animation doesn’t explain the same need.

GOV.UK’s service-design guidance starts with understanding users and the problems they need to solve. We apply that principle to a business website brief: bring the questions customers actually ask, the misunderstandings you keep correcting and any evidence from the current site. You don’t need to turn them into a finished design specification yourself.

Source: GOV.UK Service Manual: learning about users and their needs

Show what content is available

Put the existing logo files, approved service information and usable photographs somewhere the project team can review. Explain what is current and what needs replacing. A folder full of different versions becomes much more useful when somebody identifies the right ones.

For each important service, think about what a prospective customer needs to see before enquiring. There may be relevant work examples, a description of the process or answers to recurring questions. Use genuine material that you have permission to publish. An unsupported claim or an invented testimonial creates a different problem for the project.

Content gaps belong in the brief too. If nobody has written the service descriptions or taken suitable photographs, say so. Agree who will provide the missing material, whether help is needed and when it can realistically be ready. Writing, image sourcing and moving old content should each have an agreed place in the scope.

Describe what a feature must actually do

'We need bookings' can mean a simple appointment request or a system that checks availability and confirms a reserved slot. Those lead to different work. Explain what the customer should be able to do and what your team needs to see afterwards.

For a quote calculator, describe the information it would need and what the result should mean. Is it a rough guide before a conversation, or an amount the business is prepared to honour? A customer portal needs equally clear decisions about who can see which projects and what an approval records.

Keep essential launch requirements separate from ideas for later. The designer can help turn the business rules into an appropriate interface, but the scope needs to distinguish a useful first release from every possibility somebody might eventually want.

Include accessibility in the early conversation

Tell the project team about any known barriers customers face and how people are likely to use the site. For example, a visitor may need to complete the enquiry using a keyboard, or read essential information without depending on a photograph of text.

W3C’s accessibility-planning guidance recommends clear objectives and responsibilities, with evaluation early and regularly through the work. Use the brief to agree how accessibility will be considered and checked, including any relevant documents or connected tools. A vague promise to make everything accessible at the end leaves too much unresolved.

Source: W3C WAI: planning and managing web accessibility

Flag what must survive a rebuild

Share the current website address and explain which services, pages or downloads people already rely on. If existing customers use a particular enquiry route or an external booking service, the team needs to know before replacing it.

Where a rebuild changes page addresses, ask for a plan covering the old URLs and their appropriate new destinations. Google Search Central’s site-move guidance includes preparing a URL mapping and planning redirects when URLs change. That work needs to be considered in the agreed scope; a new visual design alone doesn’t resolve it.

Explain who controls the domain, hosting and existing email, without putting passwords into the brief. Relevant analytics or search evidence can help establish what is already useful. Access should be arranged securely when it is needed.

Source: Google Search Central: site moves with URL changes

Read our domain ownership guide

Agree how decisions will be made

Name the person who can approve factual content and the person who makes the final design decision. If several colleagues need to contribute, agree how their comments will be brought together before a review round. Conflicting instructions are difficult to build against.

Explain any real deadline and what depends on it. A launch tied to an event needs a conversation about content readiness, review time and testing. Also explain who will look after the site after launch, so the choice between ongoing support and self-managed handover can be made with the right information. These responsibilities should be agreed alongside the build.

Bring the starting point to Pointed

We can work from your business details, existing material and the outcomes you need. You don’t need to arrive with a finished page layout. Our free homepage preview gives you a direction to consider before deciding whether to commission the paid website, with the included scope agreed before work starts.

Send your current site link if you have one, a short explanation of the business and the main improvement you want. Keep customer information and account credentials out of the initial message. We can establish what further material or access the agreed project needs.

Enquire by email, WhatsApp or our short enquiry form. We agree the scope and price with you before you pay by Stripe invoice.