What is a project brief? It might seem self-explanatory, but the art of writing a well-thought-out and well-structured project brief is not to be underestimated. After all, this foundational document will help set your project up for a great start.
Looking to start a digital product development project? It doesn’t matter whether it’s a large-scale ambitious plan or you just want to add a couple of functionalities to an existing solution. It’s not that important if you already have a feature roadmap or just the seedling of an idea. Whatever your situation may be, there is one document you’re sure to encounter at the very start – a project brief.
This central document that helps get your project off the ground is probably well-known to those who’ve already done many excursions into the digital world but may be an enigma for those with less experience.
With almost 20 years of project work under our belt, we’ve seen as many briefs as we have clients – great ones, mediocre ones, and outright terrible ones.
Allow us to share some tips so you can make sure your brief falls into the first category.
What is a project brief? The document that helps us help you
One of the main purposes of a project brief is to ensure alignment between everyone involved in the project: stakeholders, project managers, designers, developers, clients. Before commencing the actual project, it’s of crucial importance that everyone is one the same page regarding the main goals and project parameters.
A project brief is a concise document that a client creates to outline the key details of their engagement with a digital agency. It contains the key objectives, scope, and requirements of a digital product or project.
This is how a project brief helps you:
- Pushes you and your team to be intentional about what you’re setting out to do
- Makes you validate the key pieces of information that go into a project
- Saves time on explanations
- Lowers the possibility of misunderstandings
- Reduces the time from the initial contact to decision-making
This is how a project brief helps us:
- Allows us to understand the foundations of a project
- Serves as a grat starting point for our discussion about creating something valuable
- Enables us to organize your workshop and de-risk your project
- Gives us grounds on which to check team availability
- Helps us to give you more accurate and more timely estimates
You will notice that the benefits for us also translate into benefits for you. By providing us with the right information in an organized way, you’re giving us a tool we can use to support you better.
How to write a good project brief
When writing a project brief, these are the five core questions you want to answer: what, why, for whom, when, and how much.
What is it that you want to build? Is it a mobile app, a web app, or maybe both? Is it a platform for an IoT system? Maybe it’s really specific: a mobile application for booking hair styling services built in Flutter. Tell us as much or as little you know, and by all means, support it with any links, resources, or other prep work that has been created.
What problem does your future digital product solve? Don’t worry, we’ll define that in detail during the discovery process, but it’s better for you to think about it beforehand. Knowing why you’re doing what you’re doing will help you make important decisions that await you. Here’s a great example of one of our clients’ why: because people in Africa lack the right tools to manage their finances independently.
You need to know your users. Again, we’ll explore that in much more detail later on, but chances are you already have a pretty solid grasp of your target audience. Are they in their 20s or in their 50s? Tech-savvy or not so much? You are (or might be) our client, but the product is not about you, it’s all about them.
What is your projection for when you would like to have a working product out in the world? Are there any strict deadlines to follow? Your when is another important factor in setting up the project because we need to check our teams’ availability. It can also influence the scope of your project – if you’re really pressed for time, you might be wise to reduce the number of features or just go with the MVP.
Finances are a sensitive issue people tend to get anxious about, but in this case, our best advice is – don’t be. This is not a poker game. It’s best that you’re upfront with your budget because that allows us to support you in the best way possible within the given limitations. Don’t ask how much it costs, but rather ask us how we can fill your bucket.
The contents of a project brief
Now that you’ve successfully answered the question “What is a project brief?” and gained a better understanding of what you are actually after, we can get more practical. Here are some of the common categories that usually populate project briefs. We’d be happy to have all of these defined, but if you can only provide a few, don’t worry. We will help you fill in the blanks.
|Project overview||Your what and your why are at the forefront here. Lay out the basics but keep it…brief.|
|Business goals and OKRs||What do you want to achieve? Attract new users, provide better service to existing ones, enter a new market or include a new demographic? For example “a thousand new users in one year.”|
|Scope and technical requirements||Your desired features, functionalities, and any constrains. Are there any specific technical specifications or technologies that need to be used or considered in the development process? For example, platform compatibility, hosting requirements, or integration with other systems.|
|Challenges||What might present the biggest hurdle during the course of the project?|
|Design materials and assets||Any existing designs, UI/UX wireframes, journey maps, sketches, etc. Any branding material including logos, color themes, typographies, and the like.|
|Target audience research findings and data analytics||Third-party research and analysis, user feedback and testing results, customer geographical and demographical information, and traffic data, if available.|
|Timeline and milestones||Your when. If there’s a specific timeline you need to adhere to in order to secure funding, meet fiscal deadlines, opportunise on a specific market trend, let us know so we can manage the project’s schedule. It is also very useful to have a best case/worst case timeline scenario.|
|Budget and resources||Your how much. Don’t forget, this one is very important. Along with the budget, you can also include information about the resources required, including personnel, tools, and materials.|
|Links to existing products in the market||Do you already have some digital products in your portfolio? If so, we’d like to know about them. Bonus points if you have demos available.|
|Competition||Another thing we’re sure to tackle during discovery workshops, but if you already know who your main competitors are, let us know. Feel free to include similar or complementary products we can draw inspiration from or use as an example of what not to do.|
|Contact information, communication tools||Seemfully self-evident, but often overlooked. Provide the names and contact information for team members who will be the main points of contact during the project’s course. You can also add their role, level of involvement in the project, and their area of expertise. Identify the stakeholders and decision-makers. If there’s a preferred communication method, let us know.|
This list is by no means exhaustive. However, it should serve as guidance as to what we find useful when starting a project. Sometimes clients will sit on all this information and never think that it might be relevant for the product they’re setting out to build. The list above gives your team a great resource to align internally before you approach us or any other partner. It will be a great asset during the preparatory phase.
What a project brief doesn’t need to contain
Reading the list above, you might be fooled into thinking that the more you provide, the better. That isn’t necessarily true. While we’ve seen project briefs that are basically “I need an app” written on a post-it, we’ve also seen clients overdo it.
So – as much as it’s ill-advisable to define things by what they are not – in this case, we find it useful to point out a couple of items you might think would be wise to include, but in reality would be of little use to us.
Here are the dont’s for a project brief:
|Everything you have||Half of it might not be what we need, and half of it might not be what we want.|
|Information about adjacent unrelated products||Sometimes clients have a large and diversified product portfolio, and some of these products belong to their other branches or have little connection to the product at hand. |
|Patent and IP information||It’s ok, we trust you on this.|
|Legal documentation||Let’s try to avoid the situation where we have to get our own legal advisor to help us decipher what’s relevant for our project. If there is some legal limitation or requirement really important for the product itself, just sum it up briefly.|
|Team information and biographies||The contact information as described above will suffice. If you want to provide some additional info about the people who’ll be working on the project, a link to their LinkedIn profile will do.|
|Marketing material||Not to be confused with branding materials mentioned above. Only include that which is branding-focued or influences the UX and design in some way.|
|Fundraising disclosure||That’s entirely your thing. We’re happy with your overall budget information.|
Sometimes more is better, and sometimes more is just – more. When we’re sifting through hundreds of pages of unnecessary documentation, we’re losing time, and you know what time is on a project.
What is a project brief? Time to put it to work.
Hopefully, our guide helped you understand what makes a solid project brief. Before jumping to making this into a to-do list, it’s important to understand the idea behind it. The purpose of a project brief is to present us with the right information, so we can support you better.
When you have all your info in order, it will be much easier for you to start a conversation with your future design and development partner, and it will be immensely easier for that partner to set up your project on the right track from the very start.