How to Write an Effective Digital Project Brief


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!)

Why Should I Bother with a Digital Project Brief?

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).

stack of papers

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.

How & When to Use a Digital Project Brief

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:

  1. Pitching a project to your superiors or coworkers. Spend some time creating a thoughtful, informed, and concise brief, and you’ll be able to state your case for your project efficiently to your (busy) boss or teammates.
  2. Procurement. If you have the green light for the project but need to hire expertise to tackle it, then a project brief will give agencies (or internal teams) a good starting point in the discovery phase. From there, informed questions can arise on both sides and further project discovery can commence.
  3. Throughout the life of the project. Project briefs are not documents to be cranked out at the start of the project and then left to rot in your Dropbox or Drive folder. Instead, they should be continually referred to throughout the entirety of the project. They serve as a guiding light for project success, historical decision-making (yes, they should be updated with notes), and additional information as the project discovery phase marches on.

What Content Goes in a Digital Project Brief?

There’s no hard-and-fast set of requirements for what goes into a project brief, but they usually contain information like this:

  1. Company Overview
  2. Project Summary
  3. Timeline
  4. Budget
  5. Business Goals
  6. Success Criteria
  7. Key Performance Indicators
  8. Challenges

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.



1. Company Overview

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

2. Project Summary

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.

3. Timeline

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.

4. Budget

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.

5. Business Goals

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:

  1. 20% growth in new client acquisition YoY
  2. 10% reduction in manual sales processes in year one (post-site launch)
  3. Development and launch of Innovation arm of business

6. Success Criteria & Key Performance Indicators

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:

  • Launched by [date]
  • No project budget overages
  • Average of 75 leads/month into CRM via lead-generation forms after year 1
  • 100% automation of contacts into CRM via web forms
  • 25% jump in SERP for defined keywords as per Moz Pro SERP after 6 months
  • 20% decrease in internal page/post publishing time against benchmark

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?

7. Challenges & Considerations

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.

My Project Brief is Done – What’s Next?

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!

Related Posts