How to write a website brief (with a template)

The single biggest predictor of a smooth website project isn’t the budget or the developer. It’s the brief. A clear brief gets you quotes you can actually compare, a realistic timeline and a site that does what you need. A vague one gets you guesses.

You don’t need to be technical to write a good one. You need to answer the questions a developer will ask anyway, before they ask them.

What a brief is for

A brief does three jobs:

• It lets suppliers quote the same project. Without one, every quote is based on a different set of assumptions, which is why quotes vary so wildly.
• It forces the important decisions early. What the site is for, who it’s for and what success looks like are much cheaper to decide before design starts.
• It becomes the yardstick. When a question comes up mid-project, the brief is what everyone checks against.

The template

Copy these headings into a document and write a few sentences under each. One or two pages is plenty.

1. About the business

What you do, who your customers are and what makes you different. Link to your current site if you have one.

2. What the site needs to achieve

Be specific. “Look more professional” is a feeling. “Get 10 enquiries a month from facilities managers” is a goal. Pick one or two main goals and put them in order.

3. Who it’s for

Describe your main audiences and what each of them needs to find or do. A buyer, a job applicant and an existing customer want very different things from the same site.

4. What the site must do

List the functions, not the pages:

• Take enquiries or bookings
• Sell products online
• Let customers log in
• Publish news, case studies or a blog
• Connect to your CRM, payment provider or booking system

5. Content

Who is writing the words and supplying the photos? Is there existing content to move across? Content is the most common cause of delays, so be honest here.

6. Look and feel

Share three to five sites you like and say why, even if they’re in a different industry. Include your logo and any brand guidelines. Sites you dislike are just as useful.

7. Technical requirements

Anything that’s already decided: a platform you must use, integrations, hosting, accessibility standards, or who needs to be able to edit the site. If you don’t know, say so. That’s what your developer is for.

8. Budget and timeline

A budget range and any fixed dates, such as a launch event or the end of a contract with your current supplier.

Why you should share a budget

Most people leave the budget out because they worry a supplier will spend all of it. In practice it works the other way. With £8,000 in mind, a good developer will tell you what that realistically buys and where to spend it. Without a number, they have to guess between a £3,000 template and a £30,000 custom build, and so do you.

If you’re not sure what’s realistic, this guide to UK website costs gives typical ranges.

Mistakes that make projects overrun

• Listing pages instead of goals. A sitemap is a design decision. Let the goals drive it.
• Too many decision-makers. Name one person who signs things off.
• Forgetting about content. Waiting on copy and photos stalls more launches than any technical problem.
• Leaving out the boring integrations. “It also needs to send leads to our CRM” is a small sentence and sometimes a big job.
• No definition of done. Agree what launch looks like, and what happens after it.

What happens next

Send the same brief to two or three suppliers. Good ones will come back with questions, not just a price. Those questions are a preview of what working with them will be like.

If you’d like a second opinion on your brief, or a realistic quote for it, send it over. We read every one and reply within a working day.