Web Development Brief

How to write a web design brief

A web design brief is what turns "we need a new website" into something you can price, staff and build. Get it right and the estimate holds, the design rounds converge, and the launch date means something. Get it wrong and the first three weeks of the project are spent discovering what the client actually meant.

The failure is rarely that clients won't tell you. It's that nobody asked them the right question in the right order. Most briefs collect preferences — colours, competitor sites they admire, a rough budget — and skip the things that decide the build: what the site has to do, which systems it has to talk to, and what success looks like as an outcome rather than a feature list.

Below is the structure of the web development brief in Coligna: eight sections, twenty-four questions, in the order a client can answer them. Copy the structure, or send it as a live link and let the prospect fill it in.

The eight sections, and what each one is for

About Your Business. Business name, industry, current site, size, market, primary services. Firmographics look like a formality; they aren't. The same feature brief costs differently for a five-person studio and a regional distributor, and you can't judge tone, scale or integration burden without knowing who's asking.

Project Goals. The primary goals, the definition of success, and the desired timeline. This is the section that most briefs get wrong — see the next heading, because it deserves its own.

Design and Content. Design preferences and inspiration, existing brand assets, competitor sites to be aware of. What matters here is the word existing: a client with a finished brand system and one with a logo in a Word document are two different projects, and this is where that surfaces.

Target Audience. The ideal customer described in prose, plus the business model — B2B, B2C or marketplace. Ask for prose deliberately. A client who can describe their customer in two sentences knows who they're selling to; a client who can't has a positioning problem the website won't fix.

Website Functionality. Required features, the single primary call to action, and the biggest pain point with the current site. The pain-point answer is worth more than the feature list — it tells you which requirements are real and which are wishes.

Integrations. Which tools and platforms the site has to connect to: CRM, payments, email, analytics. Every integration named here is scope, and every one discovered later is a change request.

SEO & Marketing. Target keywords and whether analytics is already in place. Two questions, deliberately — this is a starting signal, not an SEO audit. If organic growth is a real objective, it needs its own discovery, and saying so upfront is more honest than pretending a two-field section covers it.

Compliance & Technical. Regulatory requirements, hosting preference, and a catch-all for anything the structure didn't reach. The catch-all earns its place: it's where clients mention the thing they assumed you already knew.

Two questions clients answer badly — and two the brief doesn't ask

"What does success look like?" — and insist on an outcome. Asked plainly, most clients answer with a feature list: a new homepage, a blog, a contact form. That's a description of the site, not a result. Push for a number and a direction — double inbound demo requests, cut the support calls about pricing in half. It's the single highest-leverage question on the form, because everything downstream gets measured against the answer.

"Pick as many goals as you like — now name the one action a visitor should take." Goals and calls to action get conflated constantly. Goals are what the business wants; the call to action is the one thing a visitor does. A site with four competing primary actions has none.

Two more worth asking in the kickoff call, even though the template doesn't ask them:

"What are you not asking for?" Explicit exclusions cost nothing to collect and save the argument in week six.

"Who signs off, and who else has opinions?" The approver and the stakeholders are rarely the same people. Finding out after the second design round is expensive.

From brief to project

A brief that sits in an inbox is a document. A brief that carries its answers forward is infrastructure.

In Coligna, a submitted brief lands in your inbound queue, sectioned and typed the way it was asked — not pasted into an email thread. From there it becomes an estimate, the estimate becomes a proposal, and the accepted proposal becomes a live project carrying those original answers with it. The client's definition of success is still attached to the project six weeks later. See how the full lifecycle works →

That's the difference between a template and a live brief: a PDF gets filled in once and filed. A brief-capture link is shareable, needs no account from the prospect, and starts the work the moment they hit submit.

Frequently asked questions

Adjacent: selling products rather than services? The e-commerce store brief covers catalogue, payments and fulfilment.