It’s an old and overused phrase, but the KISS (keep it simple stupid) acronym is as true today as it was then. This is a philosophy that we apply to many aspects of a web project, not least to the brief itself.
In this short guide, I’ll cover some of the common mistakes that can easily be made (and which can just as easily be avoided), as well as some concrete examples and templates to help you get started with your own brief.
If after reading this you are left with a question unanswered or an uncertainty about anything i’ve written, then please don’t hesitate to get in touch. Just pop me an email and i’ll get right back to you.
What is a brief and why is it so important?
Perhaps the greatest contributing factor I’ve seen in failed web projects, lies in the quality of the brief that was written in the first place. And that’s if a brief existed at all!
As a client, it’s understandably logical to assume that a brief will be written by the developer you work with. Whilst this is true in the grand scheme of things, in the first instance it is often forgotten that it is the responsibility of the client to write an initial brief, for the purpose of:
- Summarising why, from a business perspective, this project has come to be and why it is needed
- Outlining what the primary success factors of the project are (A.K.A the main deliverables)
Take away point #1: Even the best developer in the world will not be able to deliver a project properly if its context and primary deliverables have not first been understood. A good developer should be able to tease this information out of you, but why risk things being lost in translation? Spend the time before hand to write a quick, and short brief to at-least get these basic points across.
The difference between a brief and a specifications document
Before we move on any further, let’s first make a distinction between a brief and a specifications document. The definition of a brief is “a set of instructions given to a person about a job or task”. Whereas a specification is “…identifying something precisely or of stating a precise requirement”. In essence, one is ahem, ‘brief’ and the other is more detailed.
At Raw Jam we like to think of a brief as something that is produced at the very beginning of a project, with more detailed specifications created once the project has started. In fact, and just to confuse matters, we break our specification documents into a series of smaller ‘brief sheets’, which are created periodically throughout the life of the project (more on this below!).
Creating the simplest brief possible
In its most basic of senses, the job of a brief is to clearly outline the project’s objectives, as well as its deliverables. And that’s pretty much it! Sure, we could argue about semantics, discuss methodologies and analyse ideal lengths; but truth be told, the most important thing to get right in a project brief, is to ensure that:
- Wording is simple and to the point
- It doesn’t contain too much jargon that is unique to your industry
- That pretty much anything written, is actionable
A single page brief, that touches on each of the project’s core deliverables with actionable lists attached to each, is infinitely more powerful than a 20 page document that talks about company philosophy, market potential and overly worded descriptions on why a certain feature is needed. A good developer or development team, will always ask you for background information if and ‘when’ they need it.
Your job when writing the brief, is to give your developer or development team the minimum amount of information that will help them understand what fundamentally needs to be delivered for the project to be considered a success. Only you will know what ‘minimum’ means in the context of your requirements, but just remember that writing too much will only make it less likely that your developer will be able to pick out the key objectives for the project.
Take away point #2: Write a complicated, wordy and overly ‘fussy’ brief at your peril! Doing so stands a strong chance of your developer over-quoting you for their work.
If a developer has to struggle to get to the heart of what you’re trying to achieve, then it’s natural that they might feel overwhelmed. The more effort and unravelling of information that the developer feels the project needs on their part, the more costly their work will be.
Another way to look at it is to think of a bad project brief as being similar to a business plan, in that they can take a long time to produce, are often only really needed to appease some sort of a bureaucratic function and most importantly, are generally out-of-date almost as soon as the project has started.
We want our brief to be the opposite of a wordy business plan. We want it to be simple, concise, immediately understandable and easy to read.
A simple brief is great but how and when do we go into more detail?
Remember, at this stage (assuming you are at the point where you are looking for a web developer), the only real purpose of the project brief is to convey your objectives and outline of deliverables to the developer or development team that you end up working with.
Your sign-up process might be complex and may well need further discussion and planning, for example, but right now your developer only needs to know that a sign-up process is needed with perhaps 1 or 2 accompanying bullet points to outline the unique aspects of the sign-up process, as you see it. This is where you need to use your judgement, but generally less is better than more.
Take away point #3: A good developer will always help you expand on the finer details of your project further down the line. As such, concentrate on putting only the high-level deliverables in the brief you write.
In fact, one tactic we use that we have found to be quite powerful, is to create a separate ‘brief sheet’ for each major deliverable of the project. Crucially though, we don’t even think about writing this document until a week or perhaps 2 (depending on the scale of the project) before work on the major deliverable in question is due to start. When we write this brief sheet, we do so following the exact guidelines outlined here! We keep it short (usually just 1 page), to the point and actionable!
The great thing about this approach, is that by the end of the project the ‘collection’ of brief sheets created can be thought of as the project’s specification document. Yet each part of that document is highly focused and stands an incredibly high chance of accurately reflecting what was actually built. Contrast this to a developer writing a single, lengthy specifications document before any work has started at all; and you can imagine how much of the document will be out of date by the time the project has completed.
I’m ready! I want to create a simple brief that will help keep my project on course!
As a recap, hopefully the above has helped:
- Give you an insight into why a clear, yet simple brief can be all conquering (and save you time and money in the long run)
- How your developer or development team will be able to use your initial brief, as a means for creating further ‘brief sheets’ focusing on specific deliverables, as they progress through your project.
With the above in mind, you will most likely want to now start putting your own brief together. Over the years, we’ve refined our own brief template and I’d like to share it with you here.