Copy-and-fill project brief
Use this as a starting point. Delete anything that does not apply and add project-specific requirements before sending it to a freelancer.
PROJECT NAME: [Name of project] BUSINESS OUTCOME: [What should this project accomplish?] BACKGROUND: [Relevant context the freelancer should understand] TARGET AUDIENCE / USER: [Who is this for?] REQUIRED DELIVERABLES: - [Deliverable 1] - [Deliverable 2] - [Deliverable 3] REQUIREMENTS: - [Non-negotiable requirement] - [Non-negotiable requirement] PREFERENCES: - [Preferred style, approach or feature] - [Optional preference] NOT INCLUDED: - [Explicit exclusion] - [Explicit exclusion] STARTING MATERIALS: - [Files, copy, brand assets, data or access supplied by buyer] REFERENCES: - [Example or reference] - [Example or reference] CONSTRAINTS: - [Technical, brand, legal or operational constraint] DEADLINE: [Target completion date] MILESTONES: 1. [Milestone / deliverable] 2. [Milestone / deliverable] 3. [Milestone / deliverable] ACCEPTANCE CRITERIA: - [What must be true for the work to be accepted?] - [Required checks, formats or functionality] REVISION POLICY: [Number of rounds and what counts as a revision] FINAL FILES / HANDOFF: - [Final exports] - [Editable/source files] - [Repository or account access] - [Documentation] APPROVAL OWNER: [Person responsible for final approval]
Treat the completed brief as the project's reference point. If the work materially changes later, update the written scope instead of relying on memory.
Project brief structure
Write the outcome first
Begin with what the project is supposed to accomplish. This gives the freelancer context for decisions that cannot be captured by a checklist.
Separate requirements from preferences
A requirement must be satisfied. A preference is desirable but negotiable. Mixing the two makes feedback unnecessarily difficult.
Use the brief as the reference point
When revisions or scope questions arise later, return to the agreed brief instead of relying on memory.