What should a website brief contain?

Why the brief decides the quality of what you receive

If you describe the project differently to each studio, you get numbers you cannot compare and a set of proposals solving slightly different problems. A single written brief sent to everyone is the only way to find out whether a higher quote is worse value or better scoping.

It also protects you. A brief that states what the site must achieve gives you something to hold a proposal against, instead of judging on whether the presentation was persuasive.

The six sections that matter

Two or three sentences each is enough. Precision matters more than length.

• The business. What you sell, to whom, and what makes people choose you over the alternative. Studios that understand this write better proposals; studios that do not will produce something generic.
• The objective. What has to be different after launch, in terms you can observe. More qualified enquiries, fewer phone calls asking about availability, orders taken without manual re-entry. Not looking more modern.
• The audience. Who visits, what they arrive knowing, and what they are trying to do. If there are two distinct audiences - customers and operators, for instance - say so, because that usually doubles the interface work.
• Content and functionality. The sections the site needs and anything that has to do something: forms, reservations, payments, accounts, search, a second language. This is where the real scope lives.
• Integrations. Every system it must connect to, including ones you consider trivial. An existing CRM, a stock system, a courier pricing feed, an accounting export. These are the most commonly omitted items and the most common cause of a revised quote.
• Constraints. Budget range, deadline and why it exists, existing brand assets, hosting or platform you are committed to, and anything that cannot change.

What to leave out

These make a brief longer and the responses less useful.

• The technology. Specifying a framework or CMS before the requirements are understood removes the studio's ability to recommend the right one - and if they only know one, that tells you something worth knowing.
• Page-by-page wireframes, unless a specific layout is a genuine requirement. Otherwise you are buying execution of your design rather than expertise.
• A list of sites you like, without saying what you like about them. Say what the reference does well - the clarity of the navigation, the way the products are compared - not that it looks nice.
• Hiding the budget. Withholding it does not get you a better price, it gets you a proposal aimed at the wrong scale. A range is enough.

The checklist

Copy this. If you can answer every line, your brief is ready to send.

• What the business does and who it serves
• What has to be different after launch, stated observably
• Who the site is for, and whether there is more than one audience
• The sections and pages the site needs
• Anything the site must do: forms, reservations, payments, accounts, search
• Whether the site is single or multilingual
• Every system it must connect to
• Whether content and images exist, or need writing and producing
• Whether your team must be able to edit content independently
• Existing brand assets, and whether they can change
• Budget range and deadline, with the reason for the deadline
• Who will approve decisions during the project
• What happens to the existing site, if there is one

Four questions that reveal the real scope

Ask yourself these before sending. Each one routinely uncovers a requirement that was not in the first draft.

• What does someone have to do manually today that the site should handle instead?
• What question do customers ask you most often that the site fails to answer?
• What happens after a form is submitted or an order is placed - who does what, in which system?
• What would make you consider the project a failure, even if it looked good?