How to brief a web development agency (and get better results)
A good brief is the single biggest factor in getting a good result from a web project. Here's what to include and what to leave out.
After years of receiving project briefs, some excellent, most not, I've noticed a pattern. The quality of the brief almost perfectly predicts the quality of the project. Not because agencies can't handle ambiguity, but because a clear brief means the client has thought through what they actually need, and that clarity carries through every decision that follows.
In my experience, the most common problem isn't too little information, it's the wrong information. I regularly receive briefs that are twenty pages long but never mention the target audience, or specify a colour palette in exhaustive detail while saying nothing about what the website needs to achieve.
Start with the problem
The single most useful thing you can tell a development agency is why you need this project. Not "you need a new website" but "our current site doesn't generate enquiries" or "customers can't find products" or "I've outgrown our CMS and content updates take days." The problem shapes everything, the approach, the priorities, the technology choices. Without it, the agency is guessing.
What to include
A good brief covers: what the business does and who it serves; what the website needs to achieve (specific, measurable goals if possible); who the primary audiences are and what they need; what's wrong with the current situation; any technical constraints or requirements (existing systems to integrate with, compliance requirements, hosting preferences); timeline and budget range. On budget: I know it feels uncomfortable to state a number, but it saves everyone time. There's a massive difference between a £8,000 project and a £40,000 project, and knowing the ballpark lets the agency propose something realistic.
What to leave out
Design direction is fine to include as inspiration, but avoid prescribing solutions. "We want a mega menu with five levels of navigation" is a solution, the underlying need might be "visitors struggle to find what they're looking for," which might be better solved with search, or a simpler information architecture, or a different navigation pattern entirely. Tell us the problem; let us propose solutions.
Similarly, don't specify technology unless you have a genuine reason. "We want it built in React" only makes sense if you have React developers on staff who'll maintain it. If you don't have a technical preference, say so, a good agency will recommend the right tool for the job.
The things people forget
Content. Almost every web project underestimates the content workload. Who's writing the copy? Who's providing the images? What's the sign-off process? If the answer is "I'll sort that out later," the project will stall. The best briefs include a content plan or at least acknowledge that content is a workstream that needs resourcing.
Maintenance. What happens after launch? Who updates the site? What's the expected frequency of changes? This affects technology choices significantly, a site updated weekly by a non-technical team needs a very different CMS approach than one updated quarterly by a developer.
If you're putting together a brief and want a second pair of eyes on it, or you'd like our brief template, just ask, I'm always happy to help shape a project before it starts.
Chris Ryan
Managing Director
17+ years in full-stack web development, most of it leading teams agency-side across e-commerce, CMS platforms, and bespoke applications. Specialises in infrastructure, system integration, and data privacy, with hands-on experience as a Data Protection Officer. Founded Innatus Digital in 2020 to offer the kind of honest, technically-led partnership that he felt was missing from the agency world.