What a good brief contains
A brief need not be a thick document. It does have to answer the questions that would otherwise be asked halfway through the project — when they cost more.
01
Start with the goal, not the pages
The first sentence of a brief should say what the site or app must deliver: enquiries, appointments, orders, applicants or fewer phone calls. As long as that is missing, every discussion about colours and menus is a discussion without a yardstick.
Below that belongs who will use it and with what question in mind. An engineer on a roof, a customer searching from the sofa in the evening, a buyer comparing three suppliers: that leads to different choices.
And how you will know later whether it worked. Often that is simply countable. If nobody counts it, it is not a goal but a wish.
02
The facts you have to supply anyway
Business details as they must be correct everywhere: name, address, phone number, opening hours, service area, chamber of commerce and VAT numbers. These also end up in the structured data, so differences between your site, your business profile and directories work against you.
Prices or price indications, terms, guarantees, certifications and insurance. Choosing not to mention something is also a choice, but be aware visitors will look for that information elsewhere.
Imagery and copy, or the agreement on who makes them. A project designed on placeholder text always has to be adjusted at the end — and adjusting is expensive then.
Access: domain name, current hosting, analytics, the Google business profile and the systems to integrate with. Those accounts belong in your own company's name.
03
What not to nail down
A brief that prescribes the layout of every page rules out better solutions. Describe instead what a visitor must be able to do there — then let the form follow.
The same goes for technology. 'It has to be in this system' can be a good requirement if you already work with it, but if it only comes from someone having heard that name somewhere, it limits needlessly.
Do be strict about the constraints that really are fixed: integrations that must work, an existing visual identity, languages, legal requirements and who internally has to agree. That last one often sets the pace more than all the technology combined.
- One sentence with the goal, and how you will count it
- Who uses it, and with what question
- Business details, prices, terms, imagery and copy
- Access to domain, hosting and the systems that must take part
- Fix the constraints, do not nail down the form
Quick questions on this topic
Do I have to write the copy myself?
Not necessarily, but the knowledge has to come from you. In practice a conversation per topic yields more usable material than a request to write it yourself: most people find talking easier. What you then check are the facts, not the style.
How extensive should a brief be?
Two pages saying the right things beat twenty describing everything except the goal. If goal, audience, facts and constraints are in there, an agency can work with it — the rest comes out of the conversation.
Knowledge base
A question that is not here?
Just ask. Plaincodelab answers even when the answer is that you do not need something.