How to Write a Brief for a Web Project (And Why Most Are Wrong)

Most web projects are won or lost before anyone opens a design tool or writes a line of code. They are won or lost in the brief.

The brief is the document, or conversation, that tells the people building your site what they are actually building and why. Get it right and the execution is clear, the scope stays manageable, and the result does what it needs to do. Get it wrong and you spend the next three months having the same conversations about misaligned expectations.

The most common problem with web briefs is this: they describe a solution instead of a problem.

What a Brief Usually Says

A typical brief looks something like this: we need a new website with a homepage, an about page, a services section, a blog, and a contact form. We want it to feel modern and professional. We want it to work on mobile. We want it done in eight weeks.

That is a spec, not a brief. It tells the team what to build. It does not tell them what problem they are solving, who they are solving it for, or what success looks like.

The team builds exactly what they are asked to build. It ships. And then the client realizes the new site is not converting any better than the old one, because the brief did not say anything about conversion. It was optimized for delivery, not outcome.

What a Brief Should Say

A good brief is built around a problem, not a solution. It answers four questions before anything else:

What is the business trying to accomplish? Not "a better website." What is the actual goal? More qualified leads, lower drop-off on a specific page, the ability to onboard clients without a sales call, or something else concrete.

Who is this for? Not a general description of a target market. A specific person, with specific context, making a specific decision when they arrive on the site. The more specific this is, the more useful it becomes as a guide for every design and content decision.

What is the current situation and what is wrong with it? What is the site doing now? What is failing? What do people do when they land on it? This gives the team the baseline they need to understand what change actually means.

What does success look like, specifically? Not "more traffic." A measurable outcome: a conversion rate on a specific page, a number of inbound requests per month, a reduction in support volume because the FAQ answers more questions. Something you can check later.

The Five Things a Good Brief Includes

Once the problem is clear, a good brief should also include: the business context, the audience, the specific success metric, the constraints (budget, timeline, technical environment), and the list of what is explicitly out of scope.

That last one is underrated. Out of scope is not just about limiting the work. It is about aligning expectations before the project starts. The most common source of scope creep is things that were never clearly excluded. If you do not say the brief does not include copywriting, the assumption is that someone is handling it. Specify what is not included and you avoid a lot of friction.

What Changes When the Brief Is Right

When a brief is built around a problem instead of a solution, the people executing it can make better decisions at every step. They know when a design choice serves the goal and when it does not. They know when a feature request is worth the added complexity and when it is scope that will not move the needle.

They can also push back when something does not make sense, because they understand the why behind the project. That pushback is valuable. It is what separates a team that builds what you asked for from a team that helps you build what you actually need.

The brief is not a formality. It is the foundation. And the best time to get it right is before anyone starts building.

If you want help writing a brief before your next web project, let's work through it together.

More from Rainmakers

• What Is Web Consulting — the honest conversation before execution starts.
• When You Don't Need a New Website — sometimes the brief reveals a different problem entirely.
• The 3 Questions I Ask Before Any Code — how to frame a project before it starts.