Most website projects that drift do so for the same reason: the person commissioning the work and the person doing it hold different pictures in their heads. A brief puts one picture on paper. Length is not the point. One page that both sides have read and agreed to will prevent more arguments than a forty-page document nobody opens.
What follows is a suggested structure, drawn from ordinary project-planning practice rather than a formal standard. The New South Wales government's project-planning guidance makes a similar point at larger scale: define the problem or opportunity using evidence before choosing a solution, and be clear about the outcomes you need. A small business can do the same in a few lines.
1. The goal, in one sentence
Say what the site is for in terms of the business, not the design. "Get more people to book a first visit" is a goal. "Look modern" is not. If you can, say how you will know it worked, using something you can count: enquiries received, bookings made, calls from the page.

2. The audience
Name one or two kinds of visitor and what each one needs to decide. A fictional example: "A homeowner in the east end who has never used us and wants to know what we cost and whether we are free next month." Avoid "everyone." A page written for everyone usually fits no one.
3. The main action
Choose the one thing you want most visitors to do: call, book, request a quote, buy. Everything else on the page supports it or stays out of its way. If you have two main actions, rank them.

4. The pages
List the pages and give each a one-line job. A small site often needs only a home page, a services page, an About page, a contact page and a privacy page. Include anything that must exist for legal or practical reasons, and any page the new site replaces. If old addresses will change, say so, so the builder can plan redirects.
5. Content: who owns what, and by when
This section saves the most time. For every page, write who supplies the text, who supplies the photos, who approves them, and a date. Do not leave "client to provide content" as a single line. Late content can stall a project, and it is the one part the builder cannot do for you. Say what you already have, such as a logo, photos, a price list, and what must be created.
If you want the builder to write copy, say so and say who checks it for accuracy. Facts such as prices, licences and opening hours should always be checked by someone in your business.
6. Requirements you can test
Keep these few and checkable:
- Devices. Works on a phone and a desktop browser.
- Accessibility. State a target. WCAG 2.2, from the W3C, is the usual reference, and you can name a level, such as AA, in one line. The UK government's service manual notes that problems usually cost less to fix if you find them early, which is the reason to put the target in the brief.
- Forms and email. Enquiries must reach a named inbox, and you will test that before launch.
- Accounts. The domain, hosting and any other accounts are registered in your business's name, and you hold the logins.
7. People, deadlines and decisions
Name one person who makes final decisions. Several approvers per page tend to produce conflicting changes. Set a launch date, the dates content is due, and how many rounds of changes are included. Also record a budget range if you have one, since it shapes what is realistic.
8. What is out of scope
Write down what this project does not include. Typical items: writing every page from scratch, a shop with payments, booking software, translation into another language, ongoing updates after launch, search-engine work, photography. Out of scope does not mean never. It means not in this price or this schedule, and a change needs a conversation.
9. After launch
Say who looks after the site once it is live, who updates content, and who holds the backups and the renewals. A short handover note, listing accounts, renewal dates and where the files are, belongs in the deliverables.
Template to copy
Fill this in and send it before asking for a quote.
``` WEBSITE BRIEF - [business name] - [date]
- Goal (one sentence): How we will know it worked:
- Audience (1-2 groups) and what each needs to decide:
- Main action (and second action, if any):
- Pages and the job of each: Pages being replaced / addresses that will change:
- Content Page | Text from | Photos from | Approved by | Due Already have: Needs creating:
- Requirements Devices: Accessibility target: Form goes to: Accounts and logins held by:
- Decision-maker: Launch date: Change rounds included: Budget range:
- Out of scope:
- After launch: who updates / who renews / who holds backups: Handover note delivered by:
```
Before you send it
Read the brief as if you were the builder with no other information. Could you price it? Could you start? If a section makes you guess, rewrite it. A good brief is short enough to read in five minutes and specific enough that two people would describe the finished site in the same way.
Sources
Prepared with AI assistance. Examples are fictional unless stated.
