How to Write a Really Good Web Project Brief

Posted by Paul on November 2, 2017

Why should you go to the effort of writing a good web project brief? Surely that's the job of your web agency and all you have to do is ask for one of their best websites! Well sure they should work with you and use their experience to guide you but it's likely that you'll know what you want and what you're trying to achieve better than anyone and you can't assume they'll automatically understand this, so it's very important to get your most important requirements written down at the beginning.

If you do this, not only will your project go more smoothly, take less time, be exactly what you want but there's a good chance it will also end up costing less.

I've written before about the benefits of writing good bug reports, and writing a good brief for a project is similar - it's all about being specific about what you want and making sure the agency understand that.

The Worst Possible Brief

Sometimes we get RFQs (Requests For Quote) such as:

"how much for a website?"

Or:

"i want a website just like {insert industry leading competitor here} how much is that?"

In the first case the problem is that the sorts of website we build range from an incredibly simple holding page that could be done in an hour at £50 to a very complex ecommerce website with custom design and custom features costing £10,000+

In the second case, while examples are good, we can't take a look at a website and deduce all of its features - many will be only accessible via a backend admin and we can't know what backend systems it integrates with. It may be a simple site, it may not be, and even if we could deduce all of its features, we wouldn't necessarily know which ones are important to you.

How to Write a Better Brief that Will Save you Time and Money

Let's be realistic here though too - it would be quite unrealistic for us to expect a beautifully written specification document that's perfect in every way and includes all of the info we need every time - although this does happen and we always appreciate it when it does!

But what I'd recommend in most cases is a page or so in an email detailing the things that are most important for you and are critical to achieve. Most of our projects can be split quite neatly down the middle between Design and Development. Some of our projects are purely design, most are purely development. Here's how to write a good brief for either:

Design

Design is about achieving the right look and feel for your customers, the look and feel that will appeal to your target market and make them want to buy. Design alone can have a significant impact on sales, so it's important to get right. That's why it's usually important to include:

  • Examples of competitors' websites that you like and importantly, why?
  • Examples of competitors' websites that you don't like and importantly, why?
  • What do you sell?
  • Who is your ideal customer?
  • Do you already have a logo and branding that you'd like to stick to?

Development

I think a lot of people get scared off here because they're afraid to show what they don't know about programming. Don't be! You don't have to write a really technical requirement or even use technical terms to write a good technical brief. Sure it can help us if you do include some technical things like links to any technical documentation or APIs you'd like to use, but as long as you tell us the important business goals from even a really high (10,000ft) level, our job is then translating those in to the code that makes them work.

The brief for every technical project will vary from the development of a payment gateway to a custom multi-seller marketplace, but luckily the only thing a client needs to write is what the end user will experience while using the software, that's it. We'll do the rest. So here are some points to try and include:

  • What is the high level business goal of this project? For example if it's for a payment gateway, the goal would be "to allow website customers to pay with Stripe" or if it's for a shipping extension it might be "to charge customers more if they are outside the EU".
  • Will your project be based on any existing software such as OpenCart or even a specific extension? If so include a link to it.
  • What will your user see at various points? It may seem obvious to you but it's often worth specifying. To take the example above with the payment gateway, it would be worth specifying that it should appear on the checkout page as another payment option.
  • If your project is being built on top of an already existing website, it's always worth listing the version of the software that you're currently using as they will affect what extensions are available and what features are built in.
  • It's by no means necessary, but including simple drawings, diagrams or screenshots can often be incredibly helpful.
  • The real key though, so I'll repeat it, is to specify what the user will see on screen during their process of using the system.

Summary

A web agency will often add "contingency" time for unknowns in estimates so while you don't have to write a complex requirements document, the more specific you can be about what you want to achieve, the better the result and potentially the lower the cost!

Still unsure what to include in a Request For Quote? Let us know in the comments!

blog comments powered by Disqus