If you want to create or start a website, it all starts with a brief. It does not matter that initially no one else will work with you. It is useful for you, but specially, for everyone else that unfortunately can not read your mind and will work on it once started. By then, you don’t want to spend hours explaining what brought you to your current stage, or having to remember all the things you did consider right back when you started.
Still, I am not sure what your knowledge level is, so I am gonna be as obvious as possible while making sure it can be a perpetual reminder for everyone, including me, of what to include as a consideration, and update it as needed.
If you don’t have a brief yet, keep reading, alternatively, you can skip ahead to what I think it should contain.
A not so brief overview of what a brief should be
In marketing and web development, or in any project for that matter, we tend to start by asking or creating an outline that provides a shared understanding to anyone involved of anything we consider important to get to a desired objective. It will be read by people over and over again, and by pointing to its inclusions and omissions, becomes a measurement of the readiness to tackle it effectively.
Top down view
Briefs should be considered incomplete pieces. The name already implies that they are short in nature, and that breaking things down should be the next task, creating documents that can be read separately, still allowing people to get the complete picture first, then dive into those areas that are needed for their part in it.
But it doesn’t end there. For each part of the brief, there can and will be breakdowns, technical overviews or proposals, that will also start with a brief, so start small and be concise to keep only the priorities. The rule of thumb should be that if the project can be successful without it, it should probably not be on the initial brief. You can noted down separately, but wait to integrate it as a nice to have later in the overview, or you risk prioritising the wrong things.
So in a nutshell, at any point in the lifetime of a project, the brief should be seen as the most important takeaways point of all the guesswork that started it all and the point of entry to anyone wanting to understand it.
It should be taken as a summary of what is ahead, not as the end all be all in isolation. A good project manager will have a brief for every aspect of a project, even briefs for tasks that require it.
Consider working on that initial brief the fluid moment in which things can easily be changed just by typing. It is the perfect moment to write, draft and edit things, to have a solid explanation of what your project is.
Because by the time quoting starts, it should remain static and unchanged, in order to ensure there are no feature-creeping and that everyone’s understanding is in line towards that very same goal that started it.
If something on the brief is wrong or needs changing once a payment has been made, I would always recommend creating a brand new copy (leaving previous ones as references) and agreeing on the new version before dating it and versioning it (e.g. v1.2) in order to think twice about doing so.
It implies a lack of foresight that shouldn’t be treated as bad thing, but as a perfect time to reopen the core ideas, assess how important the changes are, and why it happened. It means that there is a need for further insight to avoid side effects (one change might change other things further down the line) so it should never be unilateral. Anyone should provide input so the new version becomes the agreed vision to follow.
The reason for it is that if used correctly, the brief is always the go to place to start in case of doubt, an agreement of what was asked of the professionals by the clients, even if done collaboratively.
If a question arises, any member of the team should go to the initial brief and dig down to see if it is covered by the requirements, either as a needs to have or a must have, if the question is relevant, solved or needs ultimately needs to be raised to the project manager, that can act accordingly and diligently. That way, the next person in line won’t need to repeat the question, avoiding distractions and enforcing the vision on how to proceed.
Using questions can be a great way to figure the scope of the project
Instead of offering a template, for which they are a lot of them available, I want to provide a process that could unlock a methodology of thinking, funnelling things into taxonomies: tool, asset or resource. That way you think of the way they are meant to be utilise, that will translate in covering maintaining your agency, not giving it away.
Feel free to start on a blank page and answer those questions in order, without getting caught up in the details. It will give you a measurement of what you thought you wanted, but let you rethink the goals, when and how you will be achieving it as opposed to a thing to have because someone else has it.
Once you are done, don’t rewrite the initial answers, you will most certainly need them, so start on a new page, answering them again but with a narrower focus on a particular resource or tool that will be necessary for it to be completed. It will automatically tell you if focusing on a particular part of the project is more beneficial at this stage, and how many are necessary for you to achieve the goal. It will remove brain clutter that you don’t want to answer yet, so write it down on a separate page with a list of those ideas or nice to haves you can come back when you are done with the most important parts. The best example is to want a website before you have the branding. So to that end, you run towards the main goal by rushing a logo that will affect the website in a major way. By thinking of the logo as a small branding project first and infusing it with your ethos and core values, not only you will be on your way of deciding them and solidifying them, but you will cascade all those decision to the next tasks and even though it might take longer, the path already walked in a shallower task will save magnitudes of time on all the next steps, being driven by those insights.
The core questions would be:
- What is the objective of your project?
- Who is it targeted to?
- A project can be broad, can it be considered a standalone tool, a standalone resource, a standalone asset, or a mixture of both and/or multiple of them?
- If so, can you break it down into separate assets, resources or tools and highlight those that will require a new brief, and how complete do you think will be that list?
- What features the (or each) tool, asset or resource must have in order to achieve the objective?
- What urgency do you have in reaching your objective and is there a timeline that would prevent it success?
- What budget do you have in order to reach these objective?
- Is there any information, including client information, usage statistics or acceptance that will result from using that resource or tool, and if so where will it be stored and how do you plan to use it in future?
- What are the methods of measuring the success and threshold of failure for the tool or resource itself?
As you see, answering these questions, as shallow the answer can be, will help you break down what you need, from the overall goal to the nitty gritty of the parts you might need with their own separate answers while helping you check if you are going too broad or too narrow. No matter what, you end up with a part of the project that comes from choosing what you want, what it entails and if you are ready to use it fully and in a way that can ensure its goal.
Good theory requires a good example
In my case, I would make the mistake of starting to do the brief of my own portfolio like this:
- The objective of the project is to launch a multimedia website that I can build up over time to showcase all my skills.
- It is targeted mainly to prospective clients, but I also want to reach people interested on what I do and have to say with free information and art to build a name for myself and possibly monetise it in due time.
- It can be considered a standalone website, but it is a combination of assets I will create, tools I will need to manage it and measure it and it will be a resource to share through blog posts and the main website.
- I can anticipate that I will need a logo, information about me, a selection of the portfolio items I want to start with, a way of contacting me and at least some articles of what topics I am passionate about.
At this stage, it is quite obvious that the list would be incomplete, so I will drop the website brief there, and start a new one with one of the listed necessities, drilling down to what I myself can achieve within a timeframe that doesn’t leave me exhausted and racing for a result that won’t be guided by clear and assertive choices.
Maybe start a new brief for a set of articles for your new website, which you can then clearly categorise, make sure covers a good range of topics, is aimed at the priority segments of your audience and slowly, come to realise through doing it that images, research and examples will also be needed.
If the output of that session becomes a list of ideas for articles, links to sources that will help and finding the stock images to visualise the writings, you can then turn those into a positive feedback loop, coming back to the website brief once done to add them as a resource you already have, or as the need for copywriting to help you finalise each of them with a brief already done.
A lot of experts will appreciate this type of summaries, without them being exhaustive, so they can have input on what is misguided or what needs to be added, so any length is good.
The reason I advice to do this, is that no one will ever teach you how shallow or how deep things need to be, but the process of failing upwards through this exercises is what allows you to gain lateral thinking, to save you from coming up short when describing what you need, but don’t exhaust yourself on tasks that you are not prepared for yet. That back and forth is what I hope will become your own compass.
If you tackle this yourself, even if you won’t do the final work, you are gaining many skills that will speed things up no matter what.
Organically, you will start to go one step further to test ideas quickly, for example, by deciding to make some of those articles a deep dive into your core values, your audience and your process. You will cover two needs at once and reintegrate the data in that initial brief. Or write about yourself, turning them into a related links in your about page that will trim it to a more pleasant experience.
That zoom out, focus in, and zoom in way of thinking is what I try to bring to the table, although something it can be misunderstood if not explained correctly.
That’s why I wanted to offer this advice and explainer to as many people as I can. In time and with polish, I hope it becomes a resource, a tool and an asset that starting from a realistic finished thing.
Leave a Reply