How to write a good project brief
Awesome. You’ve got an idea for an online business and you’re ready to get start building a project brief.
Creating the project brief
At this stage, it can be helpful to create what’s often called a project brief—a document that outlines a summary of your idea, how you imagine it working, and what work needs to be done to get it there.
You might hear a project brief also being referenced as a project proposal, project summary, project breakdown, or scope of work document.
A project brief is the document that defines the scope and requirements for a project. It contains an overview of the goals for the project and functionality necessary to complete them. This is shared with the people you’re working with on the project so they can understand how you see the product you want to build.
From the moment you come up with an idea for your product you’ve already created the beginnings of a project brief in your head. Now you need to get this thinking down on paper.
A project brief can vary from a brief outline to a detailed document. Which option you go with largely depends on the level of control you’d like to have in the creation process.
Let’s put that brief to work
We’ll match you with the perfect freelancer for your project
More creative control with a ‘loose’ brief
If you want to give more control to the people you’re working with on the project, it can be helpful to create a project brief that encourages trying different routes rather than narrowing in too much on a specific direction.
For example, when we redesigned the homepage for our website, crew.co, we went with a ‘loose’ project brief because we wanted to try a different design concept than any of the options we had previously considered.
‘LOOSE’ BRIEF EXAMPLE:
REDESIGN OF THE CREW HOMEPAGE
We’d like to refocus the design of our site crew.co starting with the homepage. We can handle the copy, layout, and/or integration.
You’ll have a large amount of creative control and can deliver the final product as a .psd.
- ‘Submit your project’ CTA
- Main navigation (Submit your project, Work on projects, Professionals, Login)
- Benefits of posting a project on Crew
- Learn more about Crew (Projects, People, How It Works)
- Highlight the quality of the talent
- Press links
- Link to manifesto
- Footer navigation
Our goal with this ‘loose’ type of brief was to include enough detail about the elements we thought were important to have on the homepage but not influence the design direction by being overly controlling.
This is why we mentioned “You’ll have a large amount of creative control” in the summary and why we didn’t provide links to any examples of sites we enjoyed.
We chose to work with a designer who had a style we enjoyed and we let him decide on the right direction. Since we wanted a new perspective on our design, we didn’t want to block different possibilities with a narrow project brief.
A ‘Tight’ project brief gives less creative control
Sometimes, you might be building something where you have a more clear idea of how the product should be built either because of similar past projects, input from customers, and/or data you’ve come across. In this case, giving too much creative control with a ‘loose’ project brief might not be the best option.
In this situation, a more focused project brief would likely be helpful to provide the clearest direction for the professionals working on the project. The goal of a project brief for this type of project is to share the knowledge you have so the people working on the project have the right insights to execute on your vision.
For instance, here is a ‘tight’ project brief we created for the design and development of this series of lessons for “How to Build an Online Business.”
‘TIGHT’ PROJECT BRIEF EXAMPLE:
DESIGN AND DEVELOPMENT FOR HOW TO BUILD AN ONLINE BUSINESS LESSONS
We’re creating a section on crew.co with a collection of interactive guides to help people who are interested in building a website/app learn more about the process (i.e. what to send your designer, how to give feedback, etc.).
We have the copy for the first guide pretty much ready and we’re looking for a front-end designer/developer to create the HTML/CSS style for the different elements (i.e. definitions, images, video embeds, etc.) and layout for the first guide.
To stay consistent with the site, we would like to use similar styles to what we currently have in our stories section.
We follow an OOCSS pattern and use SASS as a pre-processor. Your code will be reviewed by our front-end engineer for quality and consistency.
The Expected Delivery
- All .psd’s associated with the design of the first guide
- A README file should be included with instructions for building and deploying the codebase
In the case of the How to Build an Online Business project, there was a specific style we were after this is why we mentioned in our project brief: “To stay consistent with the site, we would like to use similar styles to what we currently have in our stories section.”
We also outlined very specific requirements for the development environment such as providing minified and unminified versions of our CSS and JS files and outlined the code pattern (OOCSS) and the pre-processor we prefer (SASS).
The goal of a ‘tight’ project brief is more about executing on tasks that are relatively well-defined compared to a ‘loose’ project brief.
Timeline, budget, payment
In addition to requirements, a project brief usually includes details about a timeline for completion, budget, and how payment will work.
When does the work need to be done? For projects with many complex features and design requirements it can be optimal to estimate a ballpark time frame for completion rather than a specific date. For instance, something like, “the project will likely be completed in about a month” would be better than setting a specific date like “the project will be completed by May 19”.
There are many different ways features can be done and fit together, and not every feature takes the same amount of time to build. If your app or website includes complex features, it can be hard to give an exact date for completion at the onset of the project. Fitting every feature and element in your product together in the best way requires attempting different routes. Without allowing time flexibility to try directions as the project progresses, you may end up rushing to meet a deadline, sacrificing the quality of your product.
As Julie Zhuo, a designer at Facebook, illustrated in her piece about product design mistakes, restraining the exploration process is like leaving a treasure map unexplored. By limiting the timeline of the exploration process you may be missing treasure troves of product ideas and solutions.
Another methodology is what’s commonly referred to as the triple constraint. It’s the necessity of budget, scope, and time to all work together to meet your business objectives. This usually requires a bit a of compromise to ensure the project is successful.
The easiest way to think of this is to decide which aspects of your project are fixed and which are flexible. Do you have a fixed budget or is it more flexible? What about timeline? Do you have a defined launch date already? Understanding what is essential to your project will help you make the tough decisions about what should be sacrificed (if necessary).
The scope of your project will often be one of the biggest influences to consider. Typical large projects like a multi-featured mobile app or a made-from-scratch web app will require a more open timeline and a flexible budget.
If, however, the feature set is relatively straightforward and clearly defined (such as adding a feature like ‘forgot your password’ or designing a single-page website), an expected timeframe can be more accurate.
It’s all too easy to get hung up on the first version of a product, trying to pack every feature into it. But when we look at the lifetime of a product, the first version is rarely (if ever) the final.
Take a look at how the location check-in app Foursquare iterated their design throughout their first two years.
Foursquare started without much custom visual design, instead mostly using the default Apple iOS elements. They slowly started bringing in more branded UI elements and new features as they gained traction and mid-2011 were able to bring on a group of dedicated UI and UX designers who focused solely on the iPhone application.
This was possible because time was a key factor for them. They chose to sacrifice the scope of design in order to be one of the first companies in their space.
A project brief usually includes an estimated budget. Although it can be difficult to estimate a mobile or web project before any work has begun, it’s helpful to put at least an estimated ballpark range for a budget.
This helps give an idea of expectations for everyone on the project. A project with a budget of $10,000 will have different considerations than one with $1,000.
The terms of payment outlines how money will be sent. Sometimes this could mean an upfront deposit before work starts or setting up project payment into different parts as the project is completed.
On Crew, we recommend splitting up projects into different parts with an expected timeframe and budget for each part.
For instance, if your project was designing a mobile app, you could break payment into 3 chunks based on completed tasks:
|Payment 1||Payment 2||Payment 3|
|Design of one main screen of the app||Design of 5 remaining app screens||Revisions/tweaks to existing designs|
A good project brief provides a general direction for your project. Like a map, a project brief can be as precise as turn-by-turn directions from Google Maps, or more like a compass, guiding you loosely in the right direction but allowing for more exploration.
Overall, a project brief is successful if it helps everyone working on the project understand the business goals (i.e. increase sign ups, get a minimum product working in the market to test demand, etc.) and the right information to make the best product decisions possible.
If you’re thinking of starting a website or mobile app project, go here and we’ll help you create a project brief.