How to write a brief for a web project

A good brief does not need to be long. Seven short answers are enough to get quotes you can compare and a project that keeps to its timeline.

Short answer

A good brief is one page long and answers seven questions. It does not need to be technical. It should describe what you want to achieve, not how it should be built.

The seven questions

What should get better? Write the problem, not the solution. "Customers call to book instead of doing it themselves" says more than "we need a booking system".
Who will use it? Customers, staff, suppliers? How often, and on what kind of screen?
What has to be there from the start? Separate what must be in from what would be nice. What would be nice can become a later stage.
What do you already have? Systems the solution should connect to, an existing site, a visual identity, text and images.
Who produces the content? Text and images are what most often delay a project. Decide early whether you do it yourselves or want help.
When do you need to be done? Is there a date that cannot move, such as a trade fair or a launch? Say so straight away.
Who decides? One person who can answer questions without everything going to a management group saves weeks.

What you can leave out

Technical requirements you do not yourself understand the reason for.
Long lists of features taken from other sites.
Design in detail. Say instead which sites you think work well, and why.

What a good brief gives you

Three suppliers who get the same clear brief give you three proposals you can compare. Three who get a vague conversation give you three guesses.

If you have no brief, that is fine too. It is what the first meeting is for, and after it you get a written proposal with scope, price and timeline.