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

Now, it’s true that we shouldn’t expect a project brief to contain all the answers right from the get-go. In fact, any good project should plan to explore and solidify the brief further in a discovery phase.

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.

Project brief guidelines

So what do we find in an ideal client brief? Well, we like complicated things that can be explained simply. If you are a new business, a good, tight value proposition is a good place to start. Beyond this, whether you are starting from scratch, replatforming, or rebranding, it’s the same guiding principles that will shape all good briefs. Just describe the ‘how’, ‘why’ and ‘what’.

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

Make it accessible

Something that we all get caught up in after having worked in an area for a while is terminology that is unique to an industry. Unless we are also very familiar with the jargon it’s best to avoid this, as it risks confusion and can lead to differing interpretations.

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.

The post How to write a great project brief appeared first on Browser London.