How to Write a Website Brief: What to Include (With a Simple Template)

A website brief is a short document that tells a web developer what your business needs from a new or redesigned website: why you want it, who it is for, what it must do, what content you already have, and the budget and deadline you are working with. When a client sends me a clear brief, I can give an accurate quote within a day or two and the project runs smoothly. When there is no brief, we usually spend the first weeks discovering things that could have been written down in an hour.

In this guide I will walk you through exactly what to put in a website brief, share a simple template you can copy, and point out the mistakes I see most often. It works whether you are a business owner hiring a freelancer for the first time or an agency briefing a white-label partner.

Why a website brief matters more than you think

Most website problems I am asked to fix were not caused by bad code. They were caused by a gap between what the client pictured and what the developer understood. A good brief closes that gap before any money is spent.

• Comparable quotes: if you send the same brief to three developers, you can compare their proposals fairly instead of comparing three different guesses.
• Fewer surprises: features that were "obvious" to you, such as online booking or a members area, get priced and planned from day one.
• Faster decisions: when a question comes up mid-project, the brief is the reference both sides agreed on.
• A better website: writing the brief forces you to think about your customers and goals, which is the foundation of good design.

You do not need to be technical to write one. You only need to know your business. Leave the technical decisions to your developer, and focus on describing outcomes.

What to include in a website brief

Here are the sections I ask every client to cover. Short answers are fine; a few honest sentences beat pages of buzzwords.

1. About your business

Explain what you do, who you serve and what makes you different, in plain language. Include your business name, location (or the countries you sell to), and any brand assets you already have, such as a logo, colours, fonts or a style guide. If you are rebranding at the same time, say so, because that changes the scope.

2. The goal of the website

This is the most important section. What should the website achieve? Typical goals include:

• Getting enquiries or quote requests
• Selling products online
• Taking bookings or appointments
• Building trust so that people who hear about you can check you out
• Reducing phone calls by answering common questions

Pick one primary goal and, at most, two secondary ones. If you can, say how you will measure success, for example "more contact form enquiries from people outside my city".

3. Your target audience

Describe the people you want to visit the site. Are they homeowners, procurement managers, students, other businesses? What do they need to know before they contact you, and what device are they likely to use? A site for busy tradespeople browsing on their phones looks very different from one for corporate buyers comparing suppliers at a desk.

4. Pages and content

List the pages you think you need, even roughly: Home, About, Services (and how many individual services), Portfolio, Blog, Contact. Then be honest about content:

• Who will write the text: you, your team, or a copywriter?
• Do you have good photos of your work, team or premises, or will you need stock images or a photographer?
• Is there existing content on an old site that should move across?

Content is the number one cause of delayed launches I see. Planning for it in the brief saves weeks.

5. Features and functionality

Describe what the site needs to do, not how it should be built. For example:

• "Customers should be able to book a 30-minute consultation and pay a deposit."
• "I want to sell around 50 products and ship within my country."
• "Staff need to update prices themselves without calling a developer."
• "Enquiries should go into our CRM automatically."

Mention any systems the website must connect to, such as an accounting tool, CRM, email marketing platform or payment gateway. Integrations often take more time than the pages themselves, so they belong in the brief.

6. Websites you like and dislike

Share two or three websites you like and, just as useful, one or two you do not. Add a sentence about why: "I like how clean this layout is" or "this one feels cluttered and slow". These do not need to be in your industry. Your developer uses them to understand your taste, not to copy them.

7. Competitors

List a few competitors and what you think they do well or badly online. This helps your developer position you clearly and spot what customers in your market expect to see.

8. Technical details you already have

You do not need to understand these, just list what exists:

• Do you own a domain name, and who is it registered with?
• Do you have hosting, and who manages it?
• Is there a current website, and which platform is it on (for example WordPress, Shopify or Wix)?
• Do you have business email set up on your domain?

Make sure the domain and hosting accounts are in your business's name. If you are not sure who controls them, read my guide on what to do when your web developer disappears before you start a new project.

9. If you are redesigning an existing site

Tell your developer what works today and what does not. Which pages bring in traffic or enquiries? Are there pages ranking on Google that must keep their addresses? A redesign that ignores existing search rankings can wipe out traffic overnight, which is why I wrote a separate checklist on how to redesign a website without losing SEO.

10. Budget and timeline

Many clients hesitate to share a budget because they worry it will be used against them. In practice, a budget range is the single most useful thing you can give a developer. It tells us whether to propose a lean solution built on a proven platform or a custom build, and it stops both sides wasting time on proposals that will never fit.

For the timeline, give your ideal launch date and explain whether it is fixed (a product launch or event) or flexible. Also note any periods when you or your team will not be available to review work.

11. Ongoing support after launch

Decide early who will keep the site updated, backed up and secure after it goes live. If you want your developer to handle it, say so in the brief so it can be included in the proposal. Websites need regular care, and I explain why in why every business website needs ongoing support.

A simple website brief template you can copy

Copy the headings below into a document and answer each one in a few sentences. That is enough for most small and medium business websites.

1. Business overview: what we do, who we serve, where we operate, what makes us different.
2. Main goal: the one thing the website must achieve, plus up to two secondary goals.
3. Audience: who our ideal visitors are and what they need to know before contacting us.
4. Pages: the list of pages or sections we expect to need.
5. Content: who is writing text, what photos we have, and what can be reused.
6. Features: what visitors and staff need to be able to do on the site.
7. Integrations: other tools or systems the site must connect to.
8. Style: brand assets, plus websites we like and dislike and why.
9. Competitors: two or three competitors and our view of their websites.
10. Technical: domain, hosting, email and current platform details.
11. Budget range: what we are prepared to invest.
12. Timeline: target launch date and whether it is fixed.
13. After launch: who will maintain the site, and whether we want a support plan.
14. Decision maker: who approves designs and pays invoices.

Common website brief mistakes to avoid

Describing the solution instead of the problem

"We need a chatbot" is a solution. "Customers keep asking the same five questions by phone" is a problem, and there may be a simpler, cheaper fix. Describe the problem and let your developer suggest options.

Listing every possible feature

Long wish lists inflate quotes and delay launches. Mark each feature as "must have at launch" or "nice to have later". A focused first version that goes live is worth more than a perfect site that never launches.

Forgetting who signs off

If five people need to approve the design, say so. Unclear approval is one of the most common reasons projects stall halfway.

Leaving out accessibility and mobile

Your website should work for everyone, including people using screen readers or keyboard navigation, and on small phone screens. If you have legal or contractual accessibility requirements, mention them. The W3C accessibility guidelines are the standard most developers work to.

Writing it alone

Ask the people who talk to customers every day, such as sales or support staff, what questions come up most. Their answers often become the most useful pages on the site.

Website briefs for agencies working with a white-label developer

If you are an agency briefing a development partner, the same structure applies, with a few additions. Include the approved designs or design files, the client's hosting environment, your preferred platform and plugins, your coding or accessibility standards, how you want progress reported, and who the developer can contact with questions. Be clear about whether the developer will ever speak to your client directly. This is how I work with agencies on white-label web development, and a clear brief is what lets me deliver work you can put your name on.

What happens after you send the brief

When I receive a website brief, I read it, note anything unclear, and usually suggest a short call to go through my questions. From there I send a proposal covering scope, approach, timeline and cost, and point out anything in the brief that could be simplified or might cause trouble later. The brief then becomes the reference we both work from throughout the project.

If you already have a website and are not sure what to change, a free website audit is a good starting point for your brief. And if your brief is ready, send it over through my web design services page and I will tell you honestly how I would approach it.

Frequently asked questions

How long should a website brief be?

For most small and medium business websites, one to three pages is plenty. What matters is that it answers the key questions: goal, audience, pages, features, content, budget and timeline. A short, clear brief is far more useful than a long one full of vague statements.

Do I need to know which platform I want before writing a brief?

No. Describe what you need the site to do and who will update it, and your developer will recommend a platform such as WordPress, Shopify or a custom build. If you already have a strong preference or an existing platform, mention it.

Should I include my budget in a website brief?

Yes. A budget range helps the developer propose a solution that actually fits, instead of guessing. It does not have to be exact, but without it you may receive quotes for very different projects that are impossible to compare.

What is the difference between a website brief and a website specification?

A brief is written by the client and explains goals, audience and requirements in business terms. A specification is usually written by the developer afterwards and describes in technical detail how the site will be built. A good brief is the starting point for a good specification.

Can my developer help me write the brief?

Yes. Many developers, including me, are happy to run a short discovery call and turn your answers into a brief. It still helps to think through the questions in this guide beforehand so the call is focused.