I’ve been self employed for six years as a freelance WordPress developer, and in that time I’ve dealt with hundreds of briefs and requests for work. To give you an idea, at the time of writing I’ve got 45 entries in my “contact form” Gravity Form, and about 25 in various other forms. Not all are requests for work, but considering I delete the form entries every 90 days, it’s quite a lot. In that time I’ve seen great briefs, and terrible briefs. I thought I’d write a post as to what I consider to be in a good website development brief.
Why should you write a good brief? Well, the main reasoning is that you save time and money in the long run. Furthermore, it tends to lead to a better web development experience. If things are spelled out then it can be helpful for the freelancer in defining your needs for the project. Because if it’s not defined, it’s either not being done (leading to a poorer web development experience) or there will be some wiggle room introduced into the budgeting (meaning it costs more to you). Spending an hour or two on a brief can really help focus the developer and also focus you as to what is important, and it’ll more likely be a successful project.
With a good brief it can really help a relationship begin on the right footing. In this post I’ve tried to look at what is within these good briefs, and prepare what I would include in an ideal brief.
Begin with an overview of the development project
About 50%-75% of the brief will be taken up with the project and what it should contain.
I tend to look at first what you’re looking to try and do and what you’re trying to achieve. Start there and work your way back. For web development the end goal is usually one of three items:-
- A new website.
- New functionality for existing website.
- Bug fixes for an existing website.
If it’s a new website, include details of the functionality and conversions. What would success for the website be for you? Will there be an online store? Do you need leads coming in?
If it’s new functionality I’d probably look towards a standalone WordPress plugin for my development. What does this new feature need to do? Where will it be on the site and how will it interact with the current site?
Finally for bug fixes I tend to focus on the bug: where is it occurring (URL’s are the best here), what you are expecting the result to be and what are you receiving?
If it’s a new build it’d also be handy to know any potentially unusual features your build will have. A good WordPress developer should know things like a contact form plugin, or a Google Map plugin, and recommend them. But do you need other custom functionality? These are things like a CRM system enquiries need to feed into, or you have a payment gateway that you would like to use for your WooCommerce store. It’s a good idea to mention it. Give an overview of all of these potential things. If you’re not sure, include it, a good freelance developer should be able to filter this.
Include bullet points on everything else
Following this, I’d probably look at everything else. I’d probably put these in an individual headers or a bullet point list below, these don’t need to be long (I’d probably not include more than 2 sentences for each), but it’d be good to know. If you don’t know, that’s fine! It can be discussed with the freelance web developer.
- Design, Copywriting and Training – Who is responsible for this? Is this something for the developer to source or will you be providing it? How proficient would you say you are at WordPress? Would you need training?
- Budget – The big one. Obviously you don’t know but ballpark figures for what you’re willing to spend would be incredibly helpful around here. As this can dictate the approach.
- Hosting & Maintenance – It’s handy to know the host as each one tends to have it’s own quirks. It also is good to know what sort of maintenance is expected going forward.
- Any sort of information on the current website – This is probably important if you’re not rewriting the content and looking to import the content. What is it built in?
You should be able to fit your project onto two sides of A4
Although you should try to include everything you can, the above really should be able to be fit into one side of A4 paper. Certainly it shouldn’t be more than two. Ideally I don’t want to be spending more than 1 hour on a quote. If you find yourself writing more than 2 sides of A4, particularly for the project overview, I’d recommend splitting the project into phases – and mentioning in the first phase that it will be a phased project.
RFP’s?
Maybe a side issue, but I tend to not answer any requests for proposal. These are usually long documents, often with not much introduction, and is usually a box ticking exercise to get quotes when the client has already got a company. In my 15 years of web development work I’ve never won a single piece of work through a request for proposal. I put a question out and not many developers answered RFP’s. One said they did but they worked in a specific field and had a dedicated member of staff involved. I do have a Request an RFP form for these, oddly it’s never been filled in 🤷.
If it’s too daunting, I can talk you through it!
This blog post was done as a bit of a guide to make you (or hopefully you) an ideal client of mine. I’m very much aware that it isn’t always the case, but the above is the process and questions I ask you when you jump on a fact finding call with me. So if you’d prefer to do that for your project and let me write a good website development brief for you, then let’s arrange a chat! I’m always interested to hear about projects.