How to write a brief for a web project.

A Brief That Gets Comparable Quotes

I was sitting in my study last night, cleaning the lens on my telescope, when I remembered a client from back in the day who spent three weeks and several thousand pounds trying to figure out how to write a brief for a web project. They had a forty-page document filled with “synergistic digital ecosystems” and “user-centric paradigms,” but they couldn’t tell me what they actually wanted the website to do. It’s the same old story: people get so caught up in the jargon that they end up paying for a mountain of expensive fluff instead of a functional tool.

I’m not here to give you a template that looks good in a corporate boardroom. I’m going to show you how to strip away the nonsense and write something that actually works. My goal is to help you get the essentials down on paper so you can stop being sold “premium add-ons” you don’t need. We’re going to focus on the meat and potatoes of your requirements—the stuff that actually matters—so you can get your site live and get on with your life.

Defining Project Objectives and Goals Without the Fluff

Defining Project Objectives and Goals Without the Fluff

When people sit down to define their project objectives and goals, they tend to drift into the clouds. They start talking about “synergy,” “brand immersion,” and “disruptive user journeys.” To me, that’s just noise. If you’re building a site, you need to know exactly what it’s supposed to do. Is it there to sell a specific product, or is it just a digital business card so people know you exist? Keep it grounded. If you can’t explain the purpose of the site in two sentences, you aren’t ready to write a brief.

This is where most people trip up during stakeholder requirements gathering. They try to please everyone by adding every bell and whistle imaginable. My advice? Define the web design project scope by focusing on the bare essentials first. If your goal is to get an enquiry form live, don’t let a designer talk you into a complex membership portal you’ll never use. Stick to the mission. Once you know the “why,” the “how” becomes a lot easier to manage without getting lost in the weeds.

Mastering Stakeholder Requirements Gathering Before the Chaos Starts

Mastering Stakeholder Requirements Gathering Before the Chaos Starts

Now, here is where things usually go sideways. You sit down with the people paying the bills, and suddenly everyone has a “vision.” One person wants a minimalist masterpiece, while another wants every blinking widget known to man. If you don’t nail down the stakeholder requirements gathering phase early, you aren’t building a website; you’re building a headache. I’ve seen enough projects stall because someone “forgot” to mention they needed a complex database halfway through the build.

The trick is to pin them down before a single line of code is written. Don’t just nod and smile; ask the uncomfortable questions about what the site actually needs to do. You need to establish a clear web design project scope so that when they come back three weeks later asking for an e-commerce shop on a brochure site, you can point to the paper and say no. It isn’t about being difficult; it’s about protecting your time and your sanity. Get it in writing, keep it simple, and don’t let the “feature creep” turn your afternoon project into a six-month nightmare.

Five Ways to Keep Your Brief From Turning Into a Sales Pitch

  • Stick to the “Must-Haves” and ignore the “Nice-to-Haves.” If you start writing down every bell and whistle you saw in a YouTube demo, you’re just handing a salesperson the blueprint for your budget. Decide what the site actually needs to do, not what it could do if you had a blank check.
  • Be brutally specific about your budget, even if it’s small. Don’t let them “quote you later.” If you tell a developer you have five hundred quid, they’ll try to find a way to make it look like five thousand. Give them a hard ceiling so they work within your reality, not their fantasy.
  • Define your “Success” in plain English. I don’t want to hear about “leveraging synergistic engagement metrics.” Just tell me: do you want people to call a phone number, fill out a form, or just read your text? If you can’t explain the goal to your neighbor, it doesn’t belong in the brief.
  • Set a realistic timeline that accounts for human error. If you tell a builder you need a house by Tuesday, they’ll lie to you just to get the contract. Tell them when you actually need it live, and add a week for when things inevitably go sideways.
  • Document the technical basics early so you aren’t held hostage later. Mention your domain and your hosting preferences upfront. If you don’t, they’ll bundle “managed hosting” into the project at a premium, and you’ll be paying them a monthly subscription for something you could have set up yourself in an afternoon.

The Bottom Line: Keep It Simple

Don’t let the jargon trip you up; if you can’t explain what the site needs to do in plain English, you don’t actually know what you’re building yet.

Stick to the essentials—a domain, a host, and a clear plan—and ignore the sales pitch for “advanced enterprise solutions” you’ll never use.

A brief isn’t a sacred text, it’s a map; use it to stay on track so you don’t spend six months building a skyscraper when all you needed was a sturdy shed.

Cutting Through the Noise

Cutting Through the Noise with clarity.

At the end of the day, a solid brief isn’t about using the most expensive jargon or filling fifty pages with “synergistic digital solutions.” It’s about clarity. You’ve defined what you actually want to achieve, you’ve figured out who needs to weigh in, and you’ve stripped away the unnecessary bloat that agencies love to charge extra for. If you can clearly state your goals and your constraints, you’ve already done more work than most people starting a project. Remember, a brief is just a map to keep you from wandering into expensive territory. Keep it lean, keep it honest, and don’t let anyone sell you a compass you don’t need.

I’ve seen plenty of projects spiral into madness because someone thought they needed a “comprehensive digital ecosystem” when they really just needed a landing page and a working contact form. Don’t let the complexity scare you off. Once you have your requirements down on paper, the hard part is actually over. Now, it’s just about execution—getting your domain, finding a reliable host, and getting the job done. Stop staring at the blank screen and just start building. The perfectionists will still be arguing about font weights while you’re already online.

About Halvard Boateng

A first website needs a domain, a host and an afternoon. The rest is upselling.