How to write a project brief for a website (with examples)

In this series, we’re talking about how to write website requirements. Make sure you check out Part 1, where we talk about separating the “what” and “how” when building a website.

If you are in the process of building a website for the first time, updating your existing site, or re-platforming your website (such as moving it from one content management system technology, or CMS, to another) the biggest risk you run is you or your agency jumping into writing code too quickly. 

  • THE OLD WAY: Ten years ago agencies would follow a waterfall model, where every requirement would be written down, wireframed, designed … even before a single line of code was written. This was problematic because there is no way to know *all the things* that come up in software development ahead of time, and projects would be way over budget and way under in scope.
  • THE NEW WAY: Then, Agile software development became a thing to try to fix. It’s meant to be fast and iterative allowing you to design –> build –> test –> repeat, quickly. The idea was to get *something* live so you can improve along the way, not wasting time on things you thought were important but really aren’t. Unfortunately, my experience has led me to see how this new way is also problematic because although the theory is correct, a lot of Agile product teams jumped into writing code too quickly. They’d think, “We must go quickly!” and forget to first identify what direction to go in.
  • THE RIGHT WAY: Helping out some of America’s largest companies with their digital strategy, we have found that “Agile + long-term product strategy” is how to build a website the right way. You must first define a vision (where you want your product, project, or organization to be), then have a formal discovery project (the process of finding out, or discovering, what needs to be built and how it can be built), write requirements, and then have a roadmap (an actionable plan to get you from where you are to where you want to be) before you implement Agile.

An important part of this process happens with a project brief. It allows you to define what you’re doing, how it points back to your business objectives, and gets everyone on the same page—way before a single line of code is written.

If you’re unfamiliar with what a project brief is, let’s start with a quick overview.

What is a project brief?

There are many different variations of a document like this. It may be called a project charter, point-of-view (POV) document, or a project brief, but the purpose is the same: get everyone on the same page.

You want a document with key definitions, recommendations, an easy-to-understand vision of what you’re doing, and why you’re doing it. This gets the collective team closer to the final solution before any design work is started.

Who should be in charge of writing the project brief? 

The Business, who we defined in Part 1 of this series, should be the owner of the Project Brief. It’s important that the Business ensures that they can explain what needs to be done and why. Technology will influence the project brief and should be part of its creation, but the project brief is created by the Business for the Technology teams.

It takes any “but you didn’t tell us” away because everything is written down and communicated.

Sample project brief

Use this as a guide, modifying it to the needs of your project. 

Note: Don’t overthink this and don’t worry about how long or short your brief is. A large, online check-in feature had a 30-page project brief, due to the complexities of their changing brand strategy and the amount of research that went into deciding what to do. A small email campaign could be accomplished in ¾ of a page.  It just depends on the complexities of your project.

Add or remove sections as you see fit. 

Section 1: Purpose of the document

When writing a document like this it’s important to think, “If someone was to pick this document up off the floor, would it have everything they need to know?” Don’t assume that they know what you’re talking about, as this is where projects can go awry. 

You always want to start with the purpose of the document. This is typically a few sentences, but no more than two paragraphs. Use clear language and state the purpose of the document in a succinct way.


Coming out of our group kick-off and discovery meeting on Tuesday, 7/25, this document is meant to summarize the goals, outstanding issues, outcomes, and the process/deliverables needed to successfully build a new Locations section of our website. 

This document captures the perspectives, epic user stories, and features needed for the Global Site Search project, which is part of the Taxonomy initiative.  

Section 2: Vision

Does your company have a vision that it is pushing towards? What are your company goals? Does it hold a certain belief or take a stand that the project must fall in line with? Make sure you capture that here. 

It’s important to ensure that project-level decisions map up to a vision that unifies everything underneath it. There must be a business reason that you’re kicking-off this project and you need to make sure everyone knows what that is. Are you looking to grow revenue by a certain percent? Switch your advertising dollars to digital? Make wayfinding easier by putting detailed location information online? 


The 2020 vision for our digital ecosystem is to create a best-in-class patient and consumer experience. We will allow for a patient or consumer to move from each section of the digital ecosystem, easily understanding the service they are looking for, where they can physically go to access that service, and what doctor will provide the service they need. 

The hypothesis for this project is unified data to make it easier for a patient to find care. 

Section 3: History

What has happened that has led up to this point? Often project team members (which can be from other departments, or even other companies, if you’re working with a third-party vendor) don’t have the context you may have, so make sure you catch them up.

  • Are you wanting to have your website be a sales tool? Write out how you have gotten to this point.
  • Does your website need to have a more comprehensive location listing? Write out how this section has evolved and where it stands today. 
  • Is your online check-in system or self-serve system antiquated? Document the research that proves this. It’s the way the Business is able to explain why you’re doing this to the Technology side of your organization.


We first built online appointment notifications in 2008 to streamline operations. If customers don’t have to wait for long periods of time, they are inherently happier. This functionality was groundbreaking, as it allowed customers to check in via a computer and wait at home. They’d get a phone call when it was time to come in and then waited no more than 10 minutes once they arrived. 

But, we need a fresh look into how online appointment notifications can be better utilized. How are today’s customers different from customers in 2008? What are our customer’s new pain points and how do we solve them? How can we stay true to the simplicity and convenience of online appointment notifications while modernizing them to fit today’s needs? 

Section 4: Research

It’s not uncommon to have customer research that goes before the formation of a project. For example, you may get feedback from customer service agents that your billing system is horrible. So, you crack open the billing system box (although, pretending it doesn’t exist sounds easier!) and start to uncover customer pain-points. You might work with an agency to help identify the areas that need the most improvement, you might have customer interviews done to hear first-hand what customers are looking for, or look into analytics to find answers.

If the Business has research that has led up to this point, include it in this document. It’s important for your Technology partners to understand the why, not just the what. You can identify this through:

  • Customer and patient personas
  • Customer research
  • Customer interviews
  • Employee interviews
  • Competitive benchmarking your website
  • Heuristic analysis
  • Usability testing

The easiest way to unify a typically fractured project team is by agreeing that you need to make your customer’s lives easier.


In-person interviews were conducted in three markets (Portland, San Francisco, and Phoenix) at five locations. The following process was used: (1) As customers left, we introduced ourselves as part of the technology team, wanting to do a short survey; the participant would get a $10 gift card in exchange for their time. (2) Legal waiver form was signed, agreeing to us being able to use their feedback to improve our system(s). (3) Project team members would ask a series of questions. (4) 10 customers were asked questions at each location, giving us a total of 50 face-to-face responses. 

A survey was sent out to the 55,000+ email list. Individuals that received this survey were current customers (had used our services in the last 3 years) and were asked general questions about how they utilize their smartphone, as well as about their experience. 345 responses were received. 

The detailed results of these tests are included in Appendix A. 

Section 5: Points of view

A point of view is one of the most powerful parts of a Project Brief. A point of view is a statement, definition, or perspective. It allows your organization to unify around a standard set of beliefs. 

What kinds of information should be included? Anything from definitions to perspectives. 


A location within our hospital system is a physical place a patient must come to in order to receive care. 

Getting a customer physically to one of our locations is the primary goal of our Location’s section. Therefore it should include wayfinding information as its top priority. 

Our company is a business a consumer can go to in order to transport natural gas off of their wellhead. 

We are one company with many markets and many locations. 

No matter which location you go to, you can expect a consistent experience while receiving individual service. 

For each point of view, write out 1-3 sentences (if needed) to explain the point to the product team.

Section 6: Goals

What are you trying to do? There is no way the project team can define a plan unless it points to something. Your goals need to be clear, easy to understand, and specific. 

  • Do we want to make the website faster? What does faster mean? Say, “The website should have a score of 70 or higher when ran through Google PageSpeed Insights.”
  • Do we want to make it easier for the site user to find information? If we had customers fail usability tests in the research phase, then list out what should happen in usability tests after the project is complete.
  • Do we want to make sure a site visitor never comes to a dead end? What does that look like for the goal?


Tie our site search into the Taxonomy so customers can utilize common language search terminology. 

Simplify search from four separate search functions to one, allowing the user to learn one way of searching. 

Implement a follow-up CRO (conversion rate optimization) project that will last 6 months to improve site search from its initial form at launch. 

Identify technology gaps we cannot currently solve. 

The important thing for goals is to stay away from flowery language that doesn’t really mean a lot to the team. “Creating a better experience” sounds like you’re giving a speech at a marketing conference, not building real solutions to help your customers. Don’t fall into that trap!

If you are struggling with writing a document like this, engaging with a third-party partner as Branch Strategy can help. We can help you ask the right questions of your team, determine how your project fits into your larger business goals, and get the Project Brief complete so it saves you money, allowing you to build the right website the first time.

Make sure you check out all five parts of our series, Writing website requirements:

  1. Part 1: Stay in your lane: separating the what and how when building a website
  2. Part 2: How to write a project brief for a website (Current Article)
  3. Part 3: Write high-level business requirements (Coming Soon)
  4. Part 4: Estimate the time and cost (Coming Soon)
  5. Part 5: Rank priorities (Coming Soon)

You might also enjoy