4 questions before you call it a brief.

01 / What should be different when this is done?

Start with the intended change. A request for a website or presentation describes an artifact; it does not automatically explain its purpose. Ask what the audience needs to understand or do after seeing it. This gives the team a practical way to evaluate ideas later.

02 / Who needs to use or approve the work?

The audience, project contact, and final approver may be different people. Identify their roles early. A person collecting feedback may not have authority to approve the direction. Clarifying that distinction prevents a review from looking complete when the actual decision is still ahead.

03 / What is already fixed?

Document the real constraints: launch timing, formats, required content, existing brand assets, or platform decisions. Distinguish these from preferences that are still open to discussion. The team can make better creative decisions when it knows where there is room to explore.

04 / What is missing?

Ask about inputs the team does not yet have. Copy, permissions, imagery, and access can all become dependencies. Name who will provide each input and what work it affects. A brief can be ready to start while still containing open questions, as long as those questions are visible.

Turn the answers into a working agreement.

Capture the purpose, deliverables, responsibilities, constraints, and open items in a short document. Share it for confirmation. When the project changes, update the agreement and explain the impact. The value of a brief is not the moment it is written; it is the shared understanding it helps maintain.