Brief Your Web Devs: Create Briefs That Are Actually Useful

Why proper briefing is crucial

A short disclaimer right away:

This guide focuses on briefing developers, not web designers.  

Browsing through dozens of brief samples available online, we noticed a tendency: many of them include info valuable mostly for web designers, not web developers. If you don’t know the difference, check out our guide on hiring web developers. In it, we go in detail on the differences between web designers and devs. 

Now, why is a brief document so important?

In brief (sic!), because without it, your devs won’t be able to do anything. Or they will, but it’ll be not what the client was asking for. You are the devs’ eyes and ears. You meet up with clients, you hear them out, you package their rambling into meaningful words and pass them on to the devs. Based on the documents you produce, they estimate project costs and deadlines, formalize client requirements into tasks and start working.

The quality of communication between you and the developers directly influences the project during its entire course! And the brief document is what this communication is going to be based on.

This is why you can’t just tell the devs, “You do this!” and slack off.  

In this article, we’re going to analyze what a proper brief should look like, what info is junk to your dev team, and what you can do to facilitate their work. 

Let’s roll.

Brief contents

What you should include in the brief?

Now let’s figure out what info your typical brief to your engineer team should contain. We discussed this matter with Daniel Brady, a Senior Software Engineer at Tapjot, Inc., and he actually opened our eyes to a bunch of things.

Project overview

Even though developers work on technical things, some non-technical info about a project is still required.

Make sure to cover the following points: 

• Desired project goals and outcomes. This is needed to prevent misunderstanding during the course of the project. Explain what the project is intended for. Is it going to be a database? A studying resource? A landing page? An eCommerce solution?
  
  Do cover not just what the client wants, but also what they want to do or achieve.
  
  Daniel believes it’s important for the developers to know answers to the following questions:

“Will meeting these goals provide short-term value, or are they steps towards some longer-term success, or are they both? How will achieving these goals impact the business? And, perhaps more importantly, for each goal, what is the impact of missing it?”

• Project budget. Because some development solutions are more costly than others.
  
• Deadlines.
  
  This point here needs elaboration.
  
  The client, of course, can have their own vision of when they want a product to be delivered. However, it’s your dev team who will be doing all the work. They know better how much time it will take to complete the order (given that you provide them with all the necessary information).
  
  Here’s how Daniel puts it:
  
  “There should be no timeline or deadline given unless it has been agreed to by an engineering lead. This is very important; even time-sensitive/urgent requests need to be vetted by an engineer before committing to it. The only people qualified to provide a valid estimate for the work you want done are the people who will do it, so if an engineer says something will take 4 weeks, and you say, “Okay but the client needs this by X date,” then you need to work with the client to either reduce the scope of the request or find a way to give the team the time they need to satisfy it. Remember, we’re on the same team: we’re not deliberately inflating our estimates to make your life harder! Attempting to force a timeline on an engineer only hurts your relationship with them and the quality of the work they can do for you.”
  
• DoD, or the Definition of Done. What is the end result supposed to look like? On which stage is a project ready to be shown to a client? Should it be a fully-operational and adjusted website or an MVP will suffice? Discuss it with the client and mention it in the brief. 

Functionality

It’s great when the client comes all-prepared, holding a written list of desired website functions in their palms. Like, “Hey, project manager, please tell your devs that I want the users of my website to be able to:

– subscribe to the website’s newsletter

– register an account

– quickly follow the website in social networks

– download a white paper, marketing materials, etc.

– put an item into the shopping cart

– comment on the blog article

– subscribe to the website’s RSS feed

– put stuff up for sale

– leave a message or ask a question on a forum

– contact the support team through the pop-up chat window.

Blah-blah, thank you.”

In this case, you’ll just have to pass down the requirements to your devs! 

Unfortunately, clients mostly come with vague requests like, “You tell me what I want,” or “I want a beautiful fast website with many visitors.” In this case, you and your team will have to work out the project from scratch, thinking over the functionality based on the info you managed to squeeze out of the client. This is when the detailed info on the project goals and outcomes comes in handy. 

The same applies to website navigation. If able, provide the developers with the info on what pages the website will have, and what its organizational structure is going to be. 

Features

Specify any additional features the client wants the website to have. This is often what clients, not developers think about in the first place. It can be anything, like: 

– image galleries

– interactive maps

– website search

– homepage with looped background animation 

– feedback form

– weather widgets

– star ratings

– comment section

The exact list of features will obviously depend on the desired project outcomes, objectives, functions, and navigation. 

References

To illustrate, provide your dev team with references. Ask a client to point out the competitors whose websites possess the desired functionality. 

In fact, references may comprise even the websites not related to the industry your client operates in.

The info you think your devs need, but they don’t

Here’s what your hired developers probably won’t need to successfully do the job.  

Detailed company info and vision

“Green fuel is our passion, and we dream the whole world will one day realize the benefits that dung fuel can bring to humanity. Therefore, we strive to…”

Nope. Developers don’t need to know what your client sees their calling in. They want to know what your client is trying to do with the help of a website. 

Your client’s USP, target audiences, etc.

This is the kind of info web designers will value. Developers turn web design into code and a working website, they don’t design the website itself. 

Mockups

Unlike references that may serve as starting points and do not oblige devs to anything, mockups imply specifics. Unless you and the client know from the very beginning, what the final product will look like (which is rarely the case), avoid using mockups on the briefing stage.     

Branding guidelines and marketing materials

And again, for the engineering team, this is junk. Don’t bother developers with it. Instead, ask yourself a question, 

How can you facilitate your devs’ work?

Play on your own field

“How can I actually help the engineering team instead of being a pain in the neck, jumping out of the blue with the new project requirements three times a day?” Wow, congratulations! A truly marvelous question! Here’s what Daniel advises: 

• Be available for frequent discussions and demos
• Be overly explicit in your communication: try to leave as little as possible open for interpretation
• Be willing to repeat your answers to our questions
• Be timely with communicating any changes to your request, and be ready to re-evaluate the timeline with every change, no matter how small it might seem: sometimes things are easier said than done, and sometimes they’re easier done than said!

In other words, let the developers do technical stuff, and focus on communication. Don’t try to control the engineering team. Instead, do your best to ease their job by providing all the necessary info upon request. 

Talk!

Daniel believes that as a project manager, you should discuss the brief with the engineering lead before providing the client with final estimates. For this to be possible, do send the document to the engineering team in advance! Discuss it with the developers, talk to the client, correct the brief, and hand its final version to the devs.

Use messengers the proper way

Another piece of advice suggests that you don’t call up project-related meetings all the time. This is only distracting the developers from work and expands the time they’ll need to successfully finish the job. Instead, to co-ordinate and monitor the work, Daniel recommends creating a Slack channel for all communication on the project between you and the developers. This way, you’ll have all the info in one place, which is great for retrospectives. 

Also, abstain from using terminology. Showing off is never a thing, especially when working on important projects. 

If we hear you use a technical term we might think you understand more than you actually do about something, which can lead to big communication issues!