Why you need a project brief
Introduction
When starting a design project, creating a brief is one of the first steps.
Yes, you can start a project without a product brief. But take it from me; you really don’t want to. You’re so much more likely to end up in the wrong place if you start based on different conversations. So always ask for a brief.. and a kick-off meeting if we’re now asking for things! 😀
What is a brief?
“The purpose of a project brief is to capture they key details of a project and ensure the team is aligned on what is being asked” - InVision
Product managers will typically come to you with a project brief when asking you to work on a new project. The brief will have a specific structure that the team decides based on what is most relevant to them.
A product brief should communicate what to build and why. The brief should answer the following questions at least:
Why are we building this specific product/feature?
What is the problem our product is trying to solve?
Who are the users we are focusing on for this product/feature?
What is our timeline?
How will we measure success?
The brief will give you all the information you need to kick-start the project and to understand what direction you need to be going in. It almost acts like a sort of map.
Who writes the briefs?
The Project Manager typically creates this with input from designers and engineers. The project managers will have completed their research and discovery phase, giving them all the information to complete the brief. The brief will be a working document which evolves as you learn more during the discovery process.
The benefits of a project brief
Starting a project without a brief is a common mistake. A brief helps prevent confusion and keeps things organised.
1. Direction
The brief offers a clear understanding of the expected result of your project. It provides a roadmap for the project's direction based on the business strategy. The direction is determined through research and analysis conducted by the Product Manager before creating the brief.
2. Encourages collaboration
The brief should be completed in collaboration with Product Managers, Engineers, and Designers. This ensures that all team members understand the content of the brief and have an opportunity to ask questions to gain clarity and suggest improvements based on their individual knowledge.
Working on the brief together ensures everyone is aligned before the project starts. During my current project, myself the engineers and Product Managers have been discussing the details of the project to understand what direction we should be taking with the project as we have multiple options we can explore. We do this by analysing all the research and data the Product Manager has collated so we can make an informed decision
3. Opportunity for discussions
Working on the brief together allows team members to discuss and have constructive conversations to gain clarity on the project. The team can improve the brief based on these conversations.
4. Clarity
The brief ensures everyone understands the end result, clarifying what is expected from the outcome.
5. Business Strategy
The brief should clearly state how the particular product or feature will contribute to the business's overall success. This understanding is crucial in order to assess the impact that the team's work will have on the business as a whole. By understanding the positive impact of their work, team members will feel more motivated and driven to accomplish their goals.
How can I use briefs?
I have created a brief template that I use for my projects. It consists of various sections that I fill out with information gathered from the Product Manager's documentation. Usually, this information should have already been gathered by the PM. However, I find that putting it in this format makes it more digestible for me compared to lengthy text documents. Additionally, it allows me to share the information with others who may only need a quick glance.
I run through this template with the PM to ensure I understand all relevant details.
Here is an overview of the sections of the brief structure I use filled out for this example project:
How to use on your job
Have a conversation with your product manager and ask them to talk you through their process when starting a new project. This is so you understand each other’s ways of working, which is very important.
By the end of our conversation, you will clearly understand whether the ore dealing with has a process for briefs. If ’for briefs. If they need a method for handling briefs or are unsure, you can suggest using the above template. However, if they already have a process, you should check if any crucial sections are missing from the method you need to proceed with the project.
This is a friendly reminder that project briefs should not contain solutions. If a solution has been included, kindly ask what the overarching goal of that solution is, and then add the goal to the brief while removing the specific solution.
There is a section for hypothesis, where the solution can be included to acknowledge the ideas presented. It's essential to consider all ideas that may be valuable and to keep in mind that the brief is not the place for specific solutions.
If there are any unanswered questions, create a section assigning team members to find the answers. Giving relevant team members is essential as you need someone responsible for getting the answer.
Conclusion
During this brief process, the aim is to give you enough clarity and information so you can start working on your project. There are numerous ways you can gain clarity on a project.
Using the documentation from the project manager may be sufficient. Alternatively, like me, you may need a visual way to comprehend the information. So, find what suits you best.
Once you start using strong project briefs, you’ll see how it makes your project much easier to work from as you are set up for success.
