We read a lot of briefs
Timelines
Feature lists
Competitor references
Brand guidelines
Preferred platforms
Budget ranges with caveats
Sometimes a mood board.
What's almost never in there?
A clear picture of who the site is for
What the audience needs to do
What success looks like once the site is live.
That's not a criticism. It's a pattern. And it's one worth breaking before a single line of code gets written.
The brief sets the foundation
From a development perspective, the brief isn't just a document - it's the foundation everything else is built on. Get it wrong and you're not just building the wrong thing, you're building it on an unstable foundation.
Features get added mid-build. Scope creeps. Decisions that should have been made in week one get made in week eight, when changing them costs three times as much.
A brief that answers the right questions upfront doesn't just make the developer's job easier. It makes the whole project faster, cleaner, and far less likely to need unpicking six months after launch.
What's usually in the brief?
What the site needs to look like
What pages it needs to have
What platform it should run on
When it needs to go live
These things matter. But they're answers to questions that shouldn't be asked first.
What's usually missing?
A returning customer looking to re-order will have a different experience to a new prospect trying to understand whether you're the right fit. If the brief doesn't distinguish between them, the build won't either.
If someone lands on the homepage and does exactly what you want them to do – what happened? Where did they go? What did they click? What did they leave having done or decided? If you can't answer this, neither can the site.
Existing infrastructure. Integration requirements. Internal teams who'll need to manage content after handover. These aren't afterthoughts, they shape platform choice, architecture, and build approach from day one. Finding them out in week five is a problem.
A beautifully built site handed to a team with no capacity to maintain it will degrade quickly. The CMS choice, the content model, the editorial workflow — these need to fit the people who'll actually use them, not just the people commissioning the build.
Why this keeps happening
Briefs are usually written by people who know their business well and assume that knowledge is shared. It isn't. What's obvious internally – the way customers buy, the questions they always ask, the journey that actually converts – needs to be made explicit before it can be designed or built around.
There's also a tendency to brief on solutions rather than problems.
"We need a resource hub"
is a solution.
"Our prospects can't find supporting information at the point of decision"
is a problem.
Understanding the latter leads to a better build.
What a stronger brief looks like
It doesn't need to be longer. It needs to answer different questions.
On users: Who are the primary audiences? What are they trying to achieve? What do they know, and not know when they arrive?
On outcomes: What actions matter most? What does conversion look like for this site, specifically?
On content: What exists already? Who owns it? Who will manage it post-launch?
On constraints: What integrations are required? What's the existing tech stack? What's non-negotiable, and why?
On success: How will you know in six months whether the project worked?
