How to write a great project brief

Image for post
Image for post

We love meeting new clients and exploring new ideas for projects; we wouldn’t be working here if this wasn’t the case. It may come as a surprise, then, to learn that we can’t always immediately dive in and get started on every project brief we receive.

Even if an idea has real potential, the alarm bells will start ringing loudly here in the Browser office if it looks like a brief hasn’t received the tender love and care that it requires!

Discovery can fill in the gaps

However, having a good project brief in place before undertaking a thorough discovery sets a project up for success. For instance, a good brief articulates a clear vision and communicates tight objectives which can help facilitate the onboarding of a new team of designers and developers. Naturally, there are a number of other factors that will influence progress during a build (resourcing, communication, technical challenges), but it’s a lot easier to patch up a leak than save a sinking ship.

Our highest priority in any project is to build the right product, and the best product possible, ensuring the most value for our clients, and a good brief is a big part of this.

Image for post
Image for post

Project brief guidelines

  • How this idea came about, from a business perspective.
  • Why development is needed, or why it’s the right time to develop.
  • And what the success metrics will be.

Furthermore, other questions that should guide the brief are:

  • What research have you already done to support this?
  • Who are your competitors? (if any)
  • Who are your stakeholders? Your users?

Do we think that there is an ideal brief template? Well, yes and no.

One thing we’ve found is that less is often more. It’s not that a brief has to be a single page word document in a specific format or anything as rigid as that, but if you use the guidelines above to structure the required information, it should be to the point and summarised.

After all, we’ll be working closely with our clients throughout the build, so we fully expect more detail to come out and evolve at various stages throughout the project anyway, so a brief doesn’t need to be completely exhaustive.

Depending on the size of the project we might even break the original brief down further into mini-briefs (often called epics or user stories in Agile development parlance) before sharing with the team anyway, allowing the work to be dealt with in more digestible chunks.

Image for post
Image for post

Make it accessible

Imagine giving your builder free rein on your house build project, including only that you are looking for something a bit more ‘modern’. Who knows what you’ll end up with!

Just like any project team, digital or otherwise, we want to be on the same page as our clients. We want to know the little things, and the big things from the offset, to make sure that any work that we end up doing is right for the business, the users, and is ultimately a success, as per the brief.

About Browser

Originally published at www.browserlondon.com on February 4, 2019.

Shaping and creating innovative, user-focused digital products and services - www.browserlondon.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store