What belongs in a useful project brief

A project brief should make decisions easier. It needs enough detail to expose constraints while leaving room to discover a better solution.

Describe the change you need

State the current behaviour and the outcome you want to improve. Include the audience, the task and an example of what success would look like. A concrete problem gives the team something more useful than a list of preferred visual effects.

Make the constraints visible

Record timing, content ownership, integrations and any decisions that have already been made. Include who can approve the work and how disagreements will be resolved. Unstated constraints tend to become expensive late changes.

Agree the first review

Define what the team will bring to the first checkpoint and which questions it should answer. A focused review of a small slice of work gives better feedback than an early attempt to show every page.

A brief can be a single shared page. Review it together at the start of each phase and update it when a constraint changes, so the team is not quietly working from several different versions of the same plan.