How to write a website brief: eight points instead of forty pages

Why a brief, when the developer already understood

Everyone agrees verbally at the start of a project. The gap appears at handover, when it turns out that catalogue meant twenty product pages to one side and twenty with filters, comparison and stock export to the other.

A brief is not there to tie a developer's hands. It is there so both sides understand at the same time what is being built — and so that three months later there is something to check against besides memory.

A good brief is shorter than people expect. It runs to a few pages rather than forty, and consists almost entirely of decisions rather than descriptions.

Below is what goes in it, in what order, and the three places where schedules most often slip. Written from the client's side: this is a document you produce, not one that arrives for your signature.

What does not belong in a brief

Start with what usually fills half the document and earns nothing.

The choice of technology. If you are not a developer, demanding a particular framework narrows the field of suppliers without improving the result. One exception: you already have a team who will maintain it.

Describing design in words. Modern, stylish, eye-catching can neither be delivered nor checked. Instead give three or four links to sites you like and one line on what you like about each.

Recycled feature lists. Phrases like intuitive navigation and responsive design specify nothing: they are the baseline, not a requirement, and in a brief they only dilute what actually matters.

Anything you are not prepared to test at handover. A clause you cannot mark done or not done does not work in a brief.

Where it starts: the job, not the page list

The first page of a brief is not the site structure. It is the answer to what should change in the business after launch.

The wording has to be testable. Not raise awareness but take survey requests through the site, which currently only arrive by phone. Not get online but show the catalogue we currently email as a file.

Then who these people are. One or two types of visitor, and for each: what question they arrive with, what they should do, and what stops them doing it today.

This section takes half a page and determines everything else. A page list built without it always comes out either longer than needed or aimed at the wrong thing.

The test is simple: if the first page of the brief does not explain why each page listed later exists, go back to it.

The page list, and how to know it is complete

Now the structure. List the pages, one line each, with what each is for beside it.

Mark separately the pages that will exist in quantity with identical construction: product pages, services, articles. Describe one of them — the rest are built to that pattern, and it is noticeably cheaper than twenty individual designs.

Do not forget the utility pages: the error page, the form-sent confirmation, the data policy. These are almost always missed and then made in a hurry.

Completeness is checked backwards: walk the list of jobs from the first section and confirm each has a page where it gets done. And the reverse — that each page has a job.

If a page is attached to no job, either it should go, or you have found a job you forgot to write down.

Data: the most skipped section

This is where expectations and price diverge most often, because the section looks dull and gets written last.

Anything that exists in the plural on a site lives in a table: products, services, properties, staff, articles. Each such set needs three things.

How many there are now and how many in a year. The difference between a hundred and a thousand is a difference in approach, not in workload.

What fields each record has. Write them out by name: title, price, photographs, attributes, availability. That list determines the filters, the card layout and the complexity.

And where the data comes from: entered by hand, exported from an accounting system, delivered by a supplier as a file. An answer of by hand for a thousand items means an importer is needed, and it is better to learn that before rather than after.

Integrations: name them

A list of the outside systems the site must talk to. Not integrate with a CRM but the name of the CRM.

For each, what should happen and in which direction. The enquiry goes to the CRM. Stock arrives from the accounting system hourly. Payment clears through a specific bank. A notification lands in a messenger.

Mark separately what you already have access to and what has to be set up. Waiting for access is the most common cause of a stall mid-project, and it has nothing to do with the developer.

And one question worth asking early: what should happen when an outside system does not answer. An enquiry lost to somebody else's silent server looks exactly the same to a customer as an enquiry that was never sent.

What happens to the old site

This section is needed by everyone who already has a site, and almost everyone skips it.

Old addresses do not disappear with the old site. A search engine remembers them for years, other people's pages link to them, they sit in somebody's bookmarks. After the new site launches, each of those addresses either leads somewhere sensible or returns an error.

After our own move off a previous platform there were 673 such addresses. They had to be worked through one at a time, because the decision on each is editorial: is there a page on the new site that answers the same question?

So the brief needs a clause: export the old site's address list and draw the mapping before development starts. Take the list from two places — the old system and the search console — because they will not match.

It costs a few days of work and saves months of recovering positions.

Who provides what

A short table that prevents more argument than the rest of the document combined.

Text: written by the client, the developer, or a separate writer. If the client, name a date, because text almost always arrives last and holds up the launch.

Photography: existing images, a new shoot, or stock. Each option has its own cost and its own lead time.

Access: domain, hosting, mail, analytics, accounting system. Gather these early and confirm they work — the password to a domain registered seven years ago in a former employee's name takes a while to find.

Upkeep after launch: who adds products and writes news. A site nobody is assigned to maintain goes stale within a quarter regardless of how it was built.

How the work is accepted

The section written least often, and the one that determines how the project ends.

Acceptance criteria must be testable with both sides present. The site works correctly is not a criterion. An enquiry from the form arrives at the stated address and in the CRM within a minute is one.

Agree in advance what you test on. A list of devices and browsers, and two or three real tasks a visitor should complete end to end.

Separately: what counts as a defect and what counts as a change. A defect is fixed within the agreed work; a change is quoted separately. Without that line, every disagreement becomes a negotiation about money.

And name the period during which defects are fixed after launch. A month is reasonable; lifetime free support does not exist and is simply priced in.

Three places where schedules slip

In practice almost every delay happens somewhere other than expected.

Text. It gets written last and holds up everything. The fix is to write it alongside development and hand it over page by page rather than all at once.

Access. It takes longer to obtain than anyone expects, especially for banking and accounting systems. Start collecting on the day of signature.

Approval on the client's side. If three people decide and they meet fortnightly, every revision costs two weeks. Name one person whose word is final — the cheapest acceleration available.

A one-page template

If you would rather not write a document from scratch, here is the minimum that covers most of the risk.

The business job and one or two visitor types. The page list with the purpose of each. Data sets with their fields and volume. Outside systems by name, with the direction of exchange. The fate of the old addresses. Who provides what and by when. Acceptance criteria. The line between a defect and a change.

Eight points, three or four pages. Enough to get comparable proposals from different suppliers, and enough that three months later the conversation is about the work rather than about who meant what.

One last thing: a brief written by the client is almost always better than one supplied by the developer — not because the client knows more, but because only the client knows what it is all for.