A useful brief is short enough that marketing, IT and the person who will edit the site can all read it. It is specific enough that two agencies would not invent two different projects from it.
Name the people and the jobs.
Write down who the site is for, and what they came to finish. A customer checking a product. A candidate applying for a role. A partner looking for a document. If a page does not serve one of those jobs, ask why it is in the first release.
Include the people inside the organisation too. Who approves a page, who translates it, and who is allowed to publish. A brief that only describes the public website misses the tool your colleagues have to use every week.
Say what must come from somewhere else.
List the systems the site has to read or write: CRM, ERP, a payment provider, a login, a catalogue. You do not need the technical design. You do need the name of the system and the job it supports.
Languages belong on the same page. If Arabic and English are both required, say which pages exist in both, and which team owns the translation. Leaving that until design is underway is how layouts get redrawn.
Draw a line around the first release.
Write down what will not be in the first launch. A later phase is a plan. An unspoken later phase is a disagreement waiting for the build.
Dates are allowed. A date without a boundary around scope is a wish. Put the boundary in the brief, then the date means something.
Bring it to the first meeting.
You do not need a finished specification. You need something the room can edit. Cold Banana would rather start from a plain brief and improve it than start from a pile of page designs that skip the questions above.
If you are briefing a website project in the UAE, those four headings are enough to begin: people, jobs, systems and the edge of the first release.
