Where to begin

For most web projects, whatever their size, they start with a ‘brief’. The brief comes into play at the point where a decision is made to go forward with an idea and someone is sought to help deliver it. It doesn’t matter if the provider is internal or external but some form of communication is needed to make the idea happen and this is where the brief comes in. The brief can be called many things depending on the organisation; examples include “invitation to tender”, “request for quote”, “design brief”, “website brief”. However in essence they all do the same thing: they inform the potential service provider(s) of what the customer wants so that they can provide a quote or an estimate as required.

One of the most common concerns I come across working with both agencies and with end clients is the question around what should go into a brief. It is possibly one of the most important documents that is produced, as it sets out high level expectations and will inevitably be referred to further down the line; but it is often one of the weakest documents because of lack of understanding or knowledge of the people producing them at this point in the proceeding. When a brief doesn’t have enough (or the right) information then agencies and service providers find this frustrating because their quote will inevitably be wrong to some degree and a sacrifice on time or money is likely to have to be made at some point during the project. This isn’t good for anyone.

So, in summary, a good brief saves money and keeps good relationships! With this in mind, I have put together a checklist you can use to help ensure that the key information has been covered in your brief. This is not a suggested format, but rather a list of areas which should be covered within the document. The format and how this is interpreted will be different for every piece of work e.g. a brief for a new design for an e-newsletter doesn’t need to be as comprehensive as a brief for a new website, but the salient points remain the same.

Checklist of information to put in your brief

1. Who are you? Include some background information on the organisation/group/company commissioning the work.
2. What is the purpose? Give details of what are you trying to achieve and why are you looking for work to be done. By thinking about the purpose of what you are trying to achieve it is easier to break down what you need. This is an area I will go further into on a future blog.
3. Who is your audience? It is important to think of all the potential types of audience for the concept: who is likely to use it, and who you want to target to use it; and if there are several types of users then it may be appropriate to prioritise them.
4. Who are your content providers? Provide information on whether or not the content is likely to be static or change frequently, who is going to provide the content and if there is any authorisation process required before it can go live. This all helps ensure a fit for purpose solution that need not incur large ongoing maintenance costs.
5. What types of content will your web site/application have? Intranets often are used as places where documents and templates are stored for employees e.g. HR forms; however external applications may be less about documents and more about words, video and/or sound.
6. What support level do you require? Considerations here could be if a website needs to be hosted then do you need backups or a guarantee that the site will be up over 99.95% of time, or maybe you have a requirement for an application to be built for a time specific event and there is likely to be heavy usage during that time, in which case you may wish for extra support.
7. Have you any branding/logo/legal requirements? These may be dictated by the source of funding e.g. a need to meet certain high accessibility standards, or there may be  corporate brand guidelines that need to be adhered to.
8. What marketing and user interactive elements do you intend to have at launch/in future? This may not be applicable for all solutions however if you intend to capture user data, or if you are likely to link into Social Media applications then knowing this up front can save you alot of time and money.
9. Are there any future requirements or technical constraints which should be considered? Considerations here could be the technical platform that your website is sitting on e.g. is it operating on Microsoft or Linux; or it could be that you know in the future you are going to do a large TV advertising campaign and therefore the application needs to be able to support an increase in visitors at that time.
10. What information do you want to receive back from the companies tendering? If your organisation needs references, prices broken down by various elements, or would like to receive information back from companies in a particular format (word/presentation/hard copies) then informing them up front can save time and confusion later.

Finally: remember the brief produced should give enough information to potential providers that they can return a realistic quote and some potential solutions for your needs. However, the brief should not dictate design or solutions. By working on design and solutions as a collaborative process with the chosen provider (internal or external), you can make use of their expertise to find the best end result.