What a good web design brief actually looks like (and why most agencies don't ask the right questions)

Most web projects don't fail in development. They fail in the brief. The scope is vague. The goals are undefined. The client has a vision that was never surfaced, and the agency started designing before they understood it. The result is a drawn-out approval process, multiple rounds of revisions, and a final product that doesn't quite do what anyone needed it to do.

A good brief isn't a Google Form with a text box for "describe your project." It's a structured conversation — a discovery process — that surfaces the information a development team actually needs to build the right thing. Here's what that looks like.

Goals and success metrics

The first question isn't "what do you want it to look like?" It's "what does success look like six months after launch?"

Good answers are specific and measurable: increase contact form submissions by 40%, reduce bounce rate from the services page below 50%, achieve a cost-per-acquisition from organic search below £30, generate 20 qualified leads per month from the new site.

Bad answers: "something modern and clean," "we just want to look more professional," "we want to rank higher on Google."

If a client can't articulate success metrics at the start, the first task of discovery is helping them find them. A website with no defined goal is a website that can never succeed or fail — which means there's no basis for evaluating whether it was worth building.

Audience definition

Who is this site for? Not in abstract terms — "SME decision makers" or "UK consumers" — but with real specificity. What do they already know about your product category? What objections do they typically have? What are they comparing you against? What device are they most likely using when they first encounter your brand?

Audience definition affects every content and design decision: the reading level of the copy, the prominence of social proof, the length of the page, whether you lead with price or value, whether you explain the category or assume knowledge.

If a brief doesn't contain a real audience definition, the agency is designing for itself.

Competitive landscape

A good agency will research your competitors before they open a design tool. They need to know what the category convention is — so they can decide whether to follow it (for trust) or deliberately break it (for differentiation). They need to know what your direct competitors are doing badly, because that's often where the design opportunity is.

This doesn't mean copying anyone. It means understanding the visual and content language your target audience is already calibrated to — and making informed decisions about where to position within it.

Technical requirements

Most agencies will ask "do you need a CMS?" and stop there. A thorough technical discovery covers:

• What integrations does the site need? (CRM, email platform, analytics, booking systems, payment gateways)
• Who is managing content after launch, and how technically confident are they?
• What are the performance requirements? (E-commerce sites with high traffic have different infrastructure needs than a five-page brochure site)
• What is the hosting situation? (Existing infrastructure to work within, or greenfield?)
• Are there SEO redirects required from an existing site? (This is often discovered at the last minute and causes launch delays)
• What are the accessibility requirements? (WCAG 2.1 AA is the standard for public-sector work and increasingly expected across the board)

Missing a technical requirement in the brief means discovering it mid-project, which means scope changes, timeline changes, and uncomfortable conversations about cost.

Content ownership

This is the question that kills more web projects than any other: who is writing the content, and when will it be ready?

A shockingly large number of web projects are held up — sometimes for months — because the client didn't realise they were responsible for supplying page copy, case studies, team photography, and product descriptions. Discovery should establish, in writing, exactly what content the client is providing, what the agency is producing, and what the delivery timeline is for each.

Designs built around placeholder content routinely break when real content arrives. The hero headline is three times longer than expected. The product descriptions are too short to fill the grid. The team photos are all different aspect ratios. Content requirements should inform the design, not be squeezed into it after the fact.

Timeline and budget

Clients sometimes avoid disclosing budget because they're worried about being charged the maximum. The result is proposals calibrated to guesswork — either too expensive (wasted time on both sides) or too cheap (the agency underscopes and everyone ends up unhappy).

A real budget conversation should include: total available budget, how it's split between design, development, and content, whether there's an ongoing retainer for maintenance, and what the hard deadline is (and why). A hard deadline without a reason attached is often negotiable; a product launch date or a trade show is not.

What a bad brief looks like

A bad brief is a Google Form with fields for "company name," "website URL," "describe your project," and "what's your budget range?" It's five minutes of a client's time and it tells an agency almost nothing useful. The agency fills in the gaps with assumptions. The client fills in the gaps with expectations. Neither set of gaps is written down. Three months later, both parties are frustrated that they're not getting what they expected.

If an agency sends you a Google Form and calls it a brief, that's a signal about how rigorous the rest of the project will be.

At Shro Web, every project starts with a structured discovery conversation — not a form. We work through goals, audience, technical requirements, and content before we open a design tool. It takes longer at the start. It saves months at the end.

If you're planning a new website and want to approach it properly, get in touch. We'll start with the right questions.