The cost of a bad design brief
It’s been three weeks since you enthusiastically spoke to your design team. That joyous first moment of anticipation and potential has been snuffed out by a gruelling back-and-forth of vague questions on Slack and a sense that no one is quite sure what the deliverables are on either side. Your boss is asking questions and you’re starting to feel the pressure. ‘If only the original brief had some detail,’ you think — but wait… A great brief isn’t long, it’s clear. The person carrying out the brief doesn’t need a 20-page doc.
What most briefs get wrong (How not to write design brief)
Vagueness
The number one way to confuse a designer, developer, or anyone producing the final product is to have vague goals. A lot of briefs will start with some background blurb that no one really needs to know and most people won’t read. There is nothing worse than being hit with a 20-page brief and halfway through reading it, you still have no idea what you need to do. We all know that attention spans aren’t what they used to be, so a good brief should be scannable at first sight.
Being too prescribed
The end result should be made clear, but how to get there should be left up to the person carrying out the brief. Nothing saps the creative energy of someone more than being told exactly how to do something — which is basically doing it for them. Trust your team and give them space to resolve the problems themselves. Obviously, with more junior members of the team, some more hand-holding may be needed at times.
Unclear target audience
So many briefs presume that the person receiving it already knows who the end user will be. This is a common mistake with in-house teams when you’re all very close to the product but sometimes forget to take a step back. Is it an internal or external user? Is it a particular subsection of your audience? Who knows… As a designer, I find it useful to also know the frustrations and desires of the audience. This doesn’t always have to go into the brief. You should create user personas where you flesh out who your audience is and go deeper on how your product helps them solve a particular problem in their lives. Another tip here is to constantly refine and update your user personas as the market evolves. After all, people change and so should your product and thinking.
No prioritisation
Another classic designers love to hear is, “It’s all important and it all needs to be done ASAP.” What a designer really hears when you tell them this is: “I’m too lazy to do my job, I hate you, and I want you to work on the weekend to get this done.” If your brief contains multiple tasks, it might be as simple as listing them as P1, P2, P3, etc. Breaking it down into small prioritised chunks will help the person doing the brief feel less overwhelmed — and if the shit does hit the fan and they suddenly get eaten by a shark while on holiday, at least you’ll probably have the most important part done before you send your thoughts and prayers to their family. As a loyal product manager, you know where your priorities are.
No one knows who has the final say
One major problem many briefs have is that once the work is done, the person who has created the brief doesn’t have the authority to sign it off. It gets passed up the chain of command into the clouds of management and comes back with a ton of changes because the person who is signing it off didn’t talk to the person writing the brief.
The dreaded scope creep
“Can you just add..” No, no, no and more no. Without clear goals, it’s easy to get distracted and add more features or requests. Of course, you have to be flexible, but when what you’re working on no longer resembles the original request, this will lead to your team reevaluating their existence on earth. Every brief should have some buffer time built in to allow for the unexpected — but if priorities really do change, then so should the brief.
What to include in a killer brief
- Target audience
You can include user personas here if you need to go into more detail.
Example:
Current external users of the platform who are having problems sending money to their family abroad. See the user persona ‘Frank’ for more detail. - The problem you’re solving (not just “we need a landing page”)
Here you need to go into the problem the user is facing.
Example:
Currently, the user has to go through the entire process every time they send money to a family member. There is no quick way of repeating a transaction. This frustrates the user and leads to mistakes. - Business objectives
Enable quicker and more frequent transactions. - Key technical features or limitations
This might include what is and isn’t possible due to restraints on your backend. - Key stakeholders
Who’s involved in the project. - Timelines
When is the first iteration needed, and any other deadlines this affects further down the line. - Resources and references
These are the things the person carrying out the brief needs. Do they need access to any design files, fonts, brand manuals, design system or codebase?
What should happen when you nail a brief
OK, this isn’t a magic potion that will solve all your problems when managing your team, but it will go a long way to speeding up deliveries of key milestones, stopping endless revisions, and reducing stress on yourself and your team. But most of all, this briefing template will help you produce better results.
Bonus tip: User story
When you need extra clarity and focus, a user story can be written. They can also help to reduce over designing and prioritise what is really needed. Here is an example:
Instead of just saying:
“We need a dashboard for managers.”
Use this:
User story: As a team lead, I want to see an overview of my team’s progress at a glance so I can spot delays early.
Hopefully this will help you in how to write design brief. If you still need more design capacity feel free Speak to use about how we can help.
