Imagine commissioning a new kitchen without telling the fitter how many people live in your house, whether you cook every night or mostly order takeaway, or what your budget actually is. You'd end up with something technically functional but completely wrong for your life. Now imagine that scenario costs £40,000 and takes nine months to complete.
That's what a vague web brief does. Every time.
Across UK agencies, there's a running — if slightly exhausted — joke about the brief that arrives as a twelve-page document full of aspirational language, contradictory objectives, and a design reference that's a competitor the client secretly wants to copy but would never admit to. It's funny until you're three months into a project that's already gone off the rails.
The Brief That Tries to Please Everyone
Most bad briefs don't come from lazy clients. They come from too many cooks. The marketing director wants brand awareness. The sales team wants leads. The CEO wants it to look "premium." The IT manager wants it to integrate with a legacy CRM system nobody else knew existed. Finance wants it done cheaply. And someone's cousin who "knows about websites" has already sent over some thoughts.
What emerges from this process is a document that reflects every competing priority without resolving any of them. The agency reads it, nods politely, asks a few clarifying questions that don't get clear answers, and then makes a series of educated guesses. Three months later, the first design review turns into a three-hour meeting where everyone realises they had a completely different website in their heads.
This isn't a hypothetical. It's the single most common pattern in UK web project failures, and it plays out from sole traders in Sheffield to enterprise firms in the City of London.
Why Stakeholders Overcomplicate It
There's a psychological dimension to the bad brief that's worth understanding. When a business is investing significant money in a new website, the people involved feel pressure to justify that investment by loading the project with objectives. More features. More pages. More functionality. More ambition.
This is partly ego — nobody wants to be the stakeholder who asked for something too simple. It's partly fear — what if we launch and it doesn't do everything we might ever need? And it's partly a fundamental misunderstanding of what a website is actually for.
A website is not a company brochure, a sales deck, a customer service portal, a recruitment tool, and a thought leadership platform simultaneously. It can serve multiple purposes, but only if those purposes are clearly prioritised and designed around. When everything is equally important, nothing is important — and the result is a site that does many things adequately and nothing brilliantly.
The Anatomy of a Brief That Actually Works
A good brief is not a long brief. In fact, there's a strong argument that any web brief longer than four pages hasn't been edited enough. Here's what it genuinely needs to contain.
A single primary objective. Not three objectives, not a hierarchy of five. One. What is the most important thing this website needs to do? Generate enquiries? Drive e-commerce sales? Build credibility with a specific audience? Everything else flows from this.
A clearly defined audience. Not "businesses of all sizes" or "anyone interested in our services." A specific, honest description of the person most likely to convert. Where are they browsing from? What do they already know about you? What's their biggest concern before they make contact?
Honest context about the business. What are the genuine strengths you want the website to communicate? What are the constraints — budget, timeline, integration requirements? What has and hasn't worked on previous digital efforts? Agencies work better with honesty than with optimism.
A small number of design references with specific reasons. Not "we like this website" but "we like the way this website handles navigation on mobile" or "we want the same sense of warmth this brand communicates in its photography." References without context are almost useless. References with context are gold.
A named decision-maker. This is perhaps the most practical point on the list. Briefs that require sign-off from a committee at every stage don't just slow projects down — they dilute every creative decision until nothing has any edge left. Someone needs to be empowered to make calls. Identify them before the project starts.
The Discovery Phase Is Not Optional
Many UK businesses treat the brief as the start of the project. In reality, it should be the output of a discovery phase — a structured conversation between the client and agency before any creative work begins.
A proper discovery process involves workshopping the objectives, auditing existing digital assets, reviewing analytics, interviewing real customers where possible, and mapping the user journey from first awareness to conversion. It takes time and it costs money. But it consistently produces briefs that are clearer, more grounded in reality, and far less likely to result in expensive mid-project pivots.
Agencies that skip discovery to get to the "exciting bit" faster are doing their clients a disservice. Clients who resist paying for discovery because it "doesn't produce anything tangible" are misunderstanding where web projects actually go wrong.
When the Brief Changes Mid-Project
Even a well-written brief can unravel if the goalposts shift during delivery. New stakeholders arrive with new opinions. A competitor launches something that changes the framing. The CEO attends a conference and comes back with fresh inspiration.
The antidote is a change management process agreed at the outset. Any significant deviation from the original brief should require a formal review — not because agencies are inflexible, but because scope creep is how projects double in cost and halve in quality. A clear brief, defended by a clear process, is how good websites get built on time and on budget.
The website that works isn't always the most ambitious one. It's the one that was built around a clear purpose, a real audience, and a brief that everyone understood before anyone opened Figma.
