What Does a Good Website Brief Look Like? A Guide for Business Owners

Most website projects that go wrong do not go wrong because of the design. They do not go wrong because of the development. They go wrong because of what happened, or rather what did not happen, before any design or development work began.

A weak brief results in a website that looks fine but does not meet the business’s actual needs. It leads to misaligned expectations, scope creep, rounds of expensive revisions, and a finished product that the business owner suspects is not quite right but cannot easily articulate why.

A good brief prevents all of that. It is neither a long nor a complicated document. It is a clear, honest account of what the website needs to achieve, who it is for, and what success looks like. This article explains exactly what to put in one.

Why Most Briefs Are Too Vague to Be Useful

The most common brief a designer or developer receives is some variation of: ” We need a new website, it should look modern and professional, here are a few sites we like the look of. That is not a brief. It is a starting point for a conversation, and a limited one at that.

The problem with vague briefs is not that they are unhelpful to the supplier, though they are. The deeper problem is that they reflect a lack of clarity about what the website is actually supposed to do. A business that cannot articulate the purpose of its website in specific terms has not yet done the thinking required before any creative work begins.

Suppliers working from a vague brief make assumptions. Some of those assumptions will be right. Many will not be. The gaps only become apparent later in the project, at a point where addressing them is far more disruptive and expensive than it would have been at the outset.

What a Good Brief Contains

A well-constructed website brief covers seven areas. None of them requires technical knowledge to complete. All of them require honest, specific thinking.

1. About your business

Start with a clear, plain-English description of what your business does, who it does it for, and what makes it different from competitors. This is not a marketing paragraph. It provides a factual foundation that allows the designer or developer to make decisions appropriate to your specific context.

• What does your business do, in one or two sentences?
• Who are your primary customers or clients?
• What is your main point of difference from competitors?
• What tone do you want the website to project? (Formal, approachable, technical, friendly?)

2. The purpose of the website

A website can serve many purposes: generating enquiries, selling products, providing information, building credibility, or some combination of these. Being specific about the primary purpose and the relative priority of secondary purposes allows every design and content decision to be made in service of something concrete.

• What is the single most important thing you want a visitor to do after arriving on your site?
• What secondary actions would also be valuable?
• How will you measure whether the website is working?

3. Your audience

The more specifically you can describe your audience, the more precisely the design and content can be calibrated to them. Vague audience descriptions (small businesses, professionals, people aged 25 to 55) are less useful than specific ones.

• Who is your typical visitor? What do they do, what do they care about, what are they looking for?
• How technically confident is your audience? Does the site need to be particularly straightforward to use?
• Are there multiple distinct audience types who need different things from the site?

4. Content and structure

Content is the part of a website brief that is most often underestimated. The assumption that content can be sorted out after the design is done is one of the most reliable causes of delayed launches and disappointing results.

• What pages does the site need? List them explicitly.
• Who is responsible for writing the content? Is this included in the project scope or handled separately?
• Do you have existing content that will be reused, updated or replaced?
• Are there content types that need specific functionality, such as a blog, a portfolio, a case study section or a product catalogue?

5. Technical requirements

Even if you are not technical yourself, there are practical requirements worth specifying at the brief stage. These affect both the project’s scope and the platform choices the supplier will make.

• Does the site need to integrate with any existing tools? (CRM, booking system, email marketing platform, payment gateway?)
• Who will be updating the site after launch, and how technical are they? (This affects the choice of content management system.)
• Are there specific performance requirements, such as fast loading on mobile or compatibility with particular browsers?
• Does the site need to meet specific accessibility standards?

6. Search and visibility requirements

As the earlier articles on this blog have covered in depth, the technical and structural decisions made during a website build directly affect how well the site performs in both traditional and AI-powered search. These requirements belong in the brief, not as an afterthought once the site is live.

• Does the site need to rank for specific search terms? If so, which ones?
• Is local search visibility important? If so, which locations?
• Should the build include schema markup? If so, which types?
• Are there specific Core Web Vitals performance targets to meet?
• Will the content be structured to support AI search visibility as well as traditional SEO?

7. Budget and timeline

Budget and timeline are two of the most consistently avoided topics in website briefs, usually because business owners feel uncertain about what is reasonable or worry about anchoring the conversation at the wrong level. In practice, being clear about both saves significant time for everyone.

• What is your budget range for the project? A range is more useful than a single figure.
• Is there a specific launch date requirement, and if so, what is driving it?
• Are there known constraints on your own availability to provide feedback, content or decisions during the project?

Questions to Ask Any Supplier You Are Considering

A brief is not only a document you hand to a supplier. It is also the basis for evaluating whether a supplier is the right fit for the project. Here are the questions worth asking before committing to anyone.

1. Can you show me examples of work you have done for businesses similar to mine in size or sector?
2. How do you handle search optimisation, including both traditional SEO and AI search visibility, as part of a build?
3. What is your approach to performance and Core Web Vitals?
4. Who will actually be doing the work? (On smaller projects, especially, it is worth knowing whether you are hiring the person you are speaking to or a subcontracted team.)
5. How do you handle revisions and scope changes during a project?
6. What does the handover process look like, and what support is available after launch?

Common Brief Mistakes to Avoid

Defining the solution instead of the problem

A brief that says we need a homepage, an about page, a services page, and a contact page defines a solution before the problem has been properly understood. Start with what you need the website to achieve, and let the structure follow from that.

Leaving content until after design

Design built around placeholder text almost always needs to be revisited once real content is introduced. Headline lengths differ. Page structures that worked for dummy content break with actual copy. Content and design need to develop together, not sequentially.

Treating mobile as an afterthought

A brief that describes the desktop experience in detail and adds, as a footnote, that it needs to work on mobile does not take mobile seriously. For most businesses, mobile visitors represent the majority of their traffic. Mobile experience deserves equal, or in many cases greater, attention in the brief.

Not specifying who has final sign-off

Projects stall when it is unclear who has the authority to approve work and make final decisions. This sounds like an obvious thing to establish, but it is frequently not documented in a brief, and the consequences of the ambiguity tend to surface at the most inconvenient moments.

A Brief Template Framework

Use this as a starting structure. The goal is not to produce a long document but an honest, specific one. Two to four pages that cover these areas well are far more useful than a ten-page document full of vague aspirations.

☐  Business overview: what you do, who you serve, what makes you different

☐  Primary purpose of the website and how success will be measured

☐  Audience description: who they are, what they need, how technically confident they are

☐  Site structure: a list of all required pages and content types

☐  Content plan: who is writing it, what exists already, what needs to be created

☐  Technical requirements: integrations, CMS preferences, accessibility needs

☐  Search and visibility requirements: SEO targets, schema, performance benchmarks

☐  Budget range and timeline, including any fixed deadlines and your own availability

☐  Examples of websites you admire and, just as usefully, ones you actively dislike

☐  Decision-making process: who has final sign-off and how feedback will be provided

Frequently Asked Questions

How long should a website brief be?

Long enough to cover the areas above with genuine specificity, and no longer. For most small to medium-sized website projects, two to four pages is sufficient. A brief that is longer than that often contains padding rather than additional useful information. If in doubt, prioritise clarity and honesty over completeness.

Should I write the brief before or after talking to suppliers?

Ideally, before, or at least in draft form before. A brief written after a series of supplier conversations tends to reflect those conversations rather than your own genuine requirements. Starting with your own thinking, however incomplete, gives you a firmer foundation for evaluating what different suppliers are telling you.

What if I do not know the answers to some of these questions?

That is useful information in itself. If you do not know what your primary audience looks like, or how you will measure whether the website is working, those are gaps worth addressing before the project begins rather than after. A good supplier will help you work through these questions, but the thinking ultimately needs to come from you.

Do I need to include a budget in the brief?

Yes, or at least a range. Suppliers working without a budget figure are guessing at what scope is appropriate, which means proposals are likely to come back either significantly over or under what you had in mind. A budget range, even a broad one, makes the conversation far more productive from the outset.

Can I use this brief process for both a website redesign and a new build?

Absolutely, and for a redesign, there are additional questions worth adding: what is not working about the current site, what data do you have about how visitors are currently using it, and what content from the existing site will be carried over. These answers significantly shape the scope of a redesign project.

Ready to Start a Project?

If you are planning a new website or a redesign and would like to talk through your requirements before committing to anything, get in touch for a straightforward conversation with no obligation and no sales pitch.