How to Brief a Web Project So You Get What You Wanted

Most disappointing web projects were briefed badly, and the responsibility for that is shared. Suppliers should ask better questions; clients often do not know which answers matter. Here is what makes a brief useful, from the receiving end.

Say what the website is for

Not 'we need a new website' but what has to be different afterwards. More enquiries from a specific service. Fewer support calls asking questions the site should answer. Staff able to update prices without calling anyone. A site that does not embarrass you when a referral checks it.

This is the single most useful thing in a brief, because it determines every subsequent decision. A site built to generate enquiries looks different from one built to reduce support calls, and without knowing which you want, a supplier will guess.

Describe who visits and what they need

Who arrives, from where, and what they are trying to establish. A site serving industrial buyers doing due diligence needs different things from one serving consumers deciding in ninety seconds.

If you have analytics, share it. Actual behaviour beats assumptions, and a supplier who sees that seventy percent of traffic is mobile and lands on three specific pages will make better decisions than one working from a description.

Be honest about content

Say who is writing it and by when, or say that you need it written. Content is the most common cause of delay on web projects — more than development capacity — and pretending it will appear is how a six-week project becomes a five-month one.

If content will be slow, say so. A supplier can plan around a known constraint and cannot plan around a surprise.

State the constraints you actually have

Budget range, deadline and why, existing systems that must be integrated, brand guidelines, anyone with approval rights, and any technology decision already made and not open for discussion.

Withholding the budget range is common and counterproductive. It does not get you a better price; it gets you a proposal that may be entirely the wrong shape, and a wasted round for both sides.

Insist on these, whoever you hire

Your own domain, hosting, repository and analytics accounts, with access granted rather than ownership transferred. A staging environment where you can see work before it goes live. Documentation at handover. A named person responsible for the project.

And a written scope specific enough to be checked — number of templates, what content is included, what happens after launch, and what is explicitly out of scope. Ambiguity in a scope is resolved later, usually in an uncomfortable conversation.

Then let the supplier disagree with you

A brief that specifies solutions rather than problems limits what you can get. If you have said 'we need a video background on the homepage' rather than 'the homepage does not communicate what we do', you have closed off better answers.

A supplier who tells you a requirement is a bad idea, and explains why, is more valuable than one who agrees with everything. That is what you are paying for.