Digital project briefs come in a variety of shapes and sizes, and there’s more than one right way to tackle them. Some are huge – flying in the face of the word “brief” – and some are tiny. Some demand alllll the details, while some demand only a high-level view. One indisputable fact, though, is that project briefs are integral to the success of the project. They force us, as project owners and project teams, to really think and be intentional about why and what we’re setting out to do before we actually start doing it.
Digital project briefs are not the only step, but they are the first in the project discovery phase – so if you’re starting a digital project, be it a website, web app, or mobile app, you’re in the right place. With that in mind, let’s talk about why we need them first before we get into what they look like (spoiler alert: we have a free template for you to use a bit further down!)
You wouldn’t buy a house without outlining what you need, would you? I mean, if you just called up a realtor and said “Yo, gimme a house” and hung up, lord knows what you’d end up with. You could get a cardboard box, a mansion with two butlers, or anything in-between – because no thinking went into the purchase and no parameters were given to the realtor. The same reasoning applies to digital projects (and some digital projects cost just as much, or even way more, than your house).
That’s why we need project briefs. We need them to force us, as project owners, to think about and validate the key pieces of information that go into a project. It requires us to think about the why, the what, the how, and the when of a project that could carry a bunch of risk (and hopefully, reward). It gives a home to information required for project validation and discussion – be it with your boss or an agency – and ideally gives us direction throughout the life of the project. It might seem silly, but it’s easy to get a few degrees off course when you’re deep in the forest; then, miles later, you end up in entirely the wrong location. Oops.
Suffice to say, a properly executed and maintained project brief will avoid that.
So, understanding why you need project briefs is a great start. But… how and when should you actually use one? There are three key situations where project briefs are mega helpful:
There’s no hard-and-fast set of requirements for what goes into a project brief, but they usually contain information like this:
Sometimes, project briefs will include items like User Personas, Technical Requirements (and/or Specifications), and sometimes even Information Architecture or Journey Maps. These are all important steps in any sort of digital project discovery phase – whether or not they end up in the brief or in separate documents doesn’t really matter.
Further to the above, some of this content is dependent on other steps being complete. For example, you can’t have effective Information Architecture without understanding your Users. So, with that in mind, we suggest separate documents for items like Personas and Requirements so you can progress throughout the discovery phase without being hung up. Remember though, all of these project documents – be they Project Briefs, Personas, Information Architecture, or something totally different – should be viewed as living documents that can and should be updated as required. They are not written in stone.
Anyways, the key takeaway on what type of content to put into a Digital Project Brief is that it should describe what needs to be built, why, for whom, when it needs to be done, and how much it should cost. What each section is called doesn’t really matter, but there’s no real reason to not use the outline mentioned above, which is the same format in the free downloadable digital project brief template below.
This section is simply a summary of the business/organization requesting the work. Here’s an example:
[Company] is a pharmaceutical tech company located in Los Angeles, California, that specializes in research and development for cutting edge pharmaceutical products. With over 500 employees, [Company] is established in their field, having been in business since 2001. More information can be found on their website at www.url.com.
This section is a summary of the project/type of work required, and why. Here’s an example:
[Company] is in need of a new website: planning, strategy, prototyping, design, development, content, QA/UA testing — the whole works. The site is not mobile-first, and is built on an outdated version of Umbraco. This, combined with years of content without governance, has led to a disorganized site that’s difficult, costly, and challenging to maintain. Further to that, [Company] has streamlined their business to focus strictly on R&D in the past year – a move that is not reflected in the overall site from a communication standpoint. Finally, [Company] moved to a new CRM in 2016, which was never integrated with the current website which has led to costly manual content management work.
*Note: this is a summary, not to be confused with specific project requirements, which is a whole other part of a proper digital project discovery phase.
This part of the brief can just be a high-level summary of the project timeline. If you want to get into details about timelines for specific deliverables and phases, feel free, but usually there are too many assumptions this early in the game. That’s why we suggest a high-level timeline at this point. It can just read something like this:
The site must be tested, stable, and launched on the production server by [date] in order to fit within this fiscal year and line up with the key dates in [Company]’s marketing plan.
This section is as it sounds – it’s just a description of the project budget, which hopefully you’ve got in place. What websites cost is a whole other post (or series of posts) I’ll write another time.
[Company] has allotted a budget of $XX,XXX for this project (inclusive of all taxes, services, licensing etc.), and a budget of $XX,XXX for one year of post-launch hosting, support, and maintenance.
The Business Goals section should answer the question, “What goals for the business/organization will this project help meet?” Here’s an example:
[Company] has three primary goals for the next two years that this project will help meet:
How will the success of this project be measured? Key Performance Indicators (KPIs) are a great way, if established at the outset, to prove value in the work once it’s complete. Here’s an example:
The success criteria and KPIs for this project are as follows:
A great way to think about KPIs is to ask yourself: what data would I be excited to report back to my stakeholders? If it’s in a case study: what numbers would you be excited to include?
This section should outline the key challenges and general considerations to note. Here’s an example:
There are a few key challenges to note on this project. First, the scope of content to be audited, organized, and migrated is considerable. Second, the CRM integration is technically complex despite the existence of a well-documented API. Third, content managers must be able to create their own lead-generation forms and pages within the design system without development aid. Finally, communicating to our audience exactly what we do without over-simplifying or conversely coming off too complex has proven to be a challenge.
Assuming you have the approval to go ahead with the project, the next step in an effective digital project discovery is to really dig into your users. After all, your users are the people who matter most. The best way to tackle that is by researching and writing up some detailed user personas that relate back to the project brief you’ve just created. So click the link immediately above to read the next post in the series, and happy discovering!