Templates

Project Brief Template for Agencies

A project brief is the contract between you and the client.

It defines: What you're doing, why, for whom, by when, and how you'll measure success.

Without it, scope creeps. Timelines slip. Everyone's frustrated.

The Template

Use this structure. Adapt it for your work, but keep the core sections.

Project Overview

Project name: [Client name] - [Project type]

Duration: [Start date] to [Delivery date]

Budget: $[Amount]

Key contacts: [Client point person, Your account manager]

Project Goals

Primary goal: What is this project trying to achieve?

Example: "Redesign the website to increase conversion rate from 2% to 3%."

Secondary goals: Are there other objectives?

Example: "Improve mobile experience. Update brand to current guidelines. Migrate to new CMS."

Scope of Work

What's included:

  • Homepage redesign
  • Product page updates
  • Mobile optimization
  • Content updates

What's NOT included:

  • Copywriting (client provides)
  • Photography (client provides)
  • Third-party integrations (handled separately)

Be specific about what's NOT included. This prevents scope creep.

Timeline

Discovery: [Dates] Design: [Dates] Revisions: [Dates] Final delivery: [Date]

Break the project into phases with specific dates.

Deliverables

Design: Wireframes, mockups, final designs in Figma

Handoff: HTML/CSS or theme file, ready for development

Documentation: Brand guidelines, design specs

List exactly what you're delivering.

Revisions

Included rounds: 2 rounds of revisions per phase

How revisions work: Client provides feedback in one document. You complete revisions and send updated version.

Out-of-scope revisions: Anything beyond 2 rounds costs $[Rate] per round.

Define what's included and what's extra.

Success Metrics

How we'll measure success:

  • Design approved by [Date]
  • Website live by [Date]
  • Conversion rate tracked and reported monthly

Make it measurable, not subjective.

Assumptions

We're assuming:

  • Client provides content by [Date]
  • Client has 48 hours to provide feedback
  • Client has final decision-maker available for approvals
  • No major scope changes after [Date]

These protect you. Set expectations upfront.

Risks and Dependencies

Risks:

  • Late content delivery delays timeline
  • Unclear feedback slows revisions
  • Third-party issues (hosting, integrations) outside our control

Dependencies:

  • Client website access
  • Client brand guidelines
  • Client analytics setup

Identify potential issues so you can plan.

Payment Terms

Payment schedule:

  • 50% due upon signing
  • 50% due upon delivery

Invoice dates: [Specific dates]

Clear payment terms prevent disputes.

How to Use This

At kickoff: Present this brief to the client. Walk through it together. Get approval and signature.

During project: Reference it when decisions need making. "Is that in scope per the brief?"

At completion: Check it. Did you deliver everything? On time? On budget?

Common Sections to Add

Content requirements: What content does the client need to provide?

Technical requirements: Any specific platforms, CMS, hosting?

Brand guidelines: Link to brand documents the designer should use.

Competitor reference: Links to competitor websites for inspiration.

Stakeholders: Everyone who needs to approve work.

The Critical Section: Scope

The scope section prevents 80% of project problems.

Be specific: Don't say "design the website." Say "design the homepage, product page, and pricing page. Design 3 additional templates (blog, customer story, case study)."

Specific > vague. Always.

Red Flags in Your Project Brief

  • Vague deliverables ("nice website")
  • No timeline
  • Unclear revision rounds
  • No success metrics
  • Unclear payment terms

If you see these, your brief needs work.

The Client Signature

Have the client sign off on the brief before work starts.

"By signing below, you confirm you understand and agree with the project scope, timeline, and budget."

This prevents "I didn't know this was included" disputes.

FAQ

How detailed should the brief be?

Detailed enough that anyone on the team can understand the project without asking questions.

For a small project, 1 page. For a large project, 3-4 pages.

What if the scope changes mid-project?

Update the brief. Get new approval from the client. If it adds time or cost, create a change order and add it to the budget.

Should I include design direction in the brief?

No. That's in a separate design brief. This brief is about scope, timeline, and budget.

Can I use the same brief for all projects?

Use a template, yes. Customize it for each project. Every project is different.

What if the client won't sign the brief?

Then don't start the project. An unsigned brief means no agreement.

Your protection disappears. Get a signature before the first day of work.

Should I share the brief with my team?

Absolutely. Your team needs to understand scope, timeline, and deliverables.

The brief is your guide for execution. Everyone should read it.

How often do scope changes happen after signing?

Often. Clients change their minds. When they do, don't just add it. Create a change order, update the brief, and adjust the timeline and budget accordingly.

What if the client disagrees with what's in the brief after signing?

Point to the signature. They agreed to it.

If they're claiming they didn't understand something, clarify verbally but stand by the signed document. This is why reading through the brief together matters.

Ready to see all your tasks in one place?

Sync all your project management tools.

Start Free Trial