Project Brief Template

A better brief makes better work possible.

A department requests a brochure. A program manager asks for a new web page. A community team needs event signage by Friday. Everyone knows what to produce—but not necessarily why it matters, who needs it, what is approved, or how success will be judged.

The project brief is the bridge between an idea and a responsible commitment.

For public-sector teams, a useful brief does more than guide design. It clarifies the service or communication problem, establishes decision authority, protects accuracy, surfaces accessibility and language needs, and documents the scope that people are actually approving.

This is a working template, not a procurement contract, statement of work, legal notice, or agency policy. Adapt it to the project and the organization's required processes.

The 12 decisions to make before production

The U.S. Web Design System encourages designing around real user needs, building trust, and considering the complete experience. The CDC Clear Communication Index provides a useful framework for evaluating a main message and call to action. The GOV.UK Service Manual offers additional public-service delivery guidance. These are supporting references, not mandatory elements of this Harbor template.

A brief is not a creative wish list

A brief should answer the questions that affect the assignment. It does not need to dictate every visual decision.

For example, “Design a modern flyer” is subjective. “Help parents understand the new registration deadline and complete enrollment through the official form” identifies a real communication problem. It gives a designer room to solve the problem and gives reviewers a clear standard for evaluating the work.

The master project brief: copy and adapt

Copy the sections below into a document or project-management system. Remove prompts that are irrelevant, but keep the decisions that protect scope and accountability.

01 / Project identity

Project title: [Working name]

Organization and department: [Name]

Project sponsor / decision owner: [Name and role]

Day-to-day project manager: [Name and role]

Brief prepared by: [Name]

Brief version and date: [Version / date]

Requested launch or delivery date: [Date]

Status: [Draft / under review / approved / on hold]

02 / The assignment

What is happening? [Describe the situation in plain language.]

What problem or opportunity should this project address? [Two or three sentences.]

Why now? [Deadline, event, policy, service need, or organizational priority.]

What happens if no action is taken? [Practical consequence.]

Communication or service objective: [What the audience should understand or be able to do.]

What is already decided? [Fixed policy, location, funding, deadlines, legal requirements, or other constraints.]

What is still open? [Decisions that can be influenced during this project.]

03 / Audience and access

Primary audience: [Who needs the result most.]

Secondary audiences: [Other groups.]

Audience task: [What should a person know, understand, decide, or complete?]

What might make the task difficult? [Information, language, disability access, timing, location, trust, technology.]

Research or existing evidence: [Service data, public questions, interviews, previous work, relevant sources.]

Required accessibility and language review: [Responsible staff, applicable standards, formats, translation/interpretation plan.]

How will the intended audience be involved in testing? [Method and timing, if appropriate.]

04 / Message and creative direction

One main message: [Single clear takeaway.]

Call to action: [Specific next step and deadline.]

Three supporting facts:

1. [Fact and authoritative source.]
2. [Fact and authoritative source.]
3. [Fact and authoritative source.]

What is not yet known? [Uncertainty and next update.]

Desired voice: [Clear, welcoming, authoritative, reassuring, celebratory, etc.]

Brand requirements: [Approved identity, logo, colors, type, style guidance.]

References or inspiration: [Links and what specifically works about each.]

Things to avoid: [Unapproved claims, confusing language, unsuitable imagery, sensitive information.]

05 / Deliverables and boundaries

Included: [List the services and outputs covered by the approved scope.]

Excluded: [List requests that would require a separate approval.]

Revision assumptions: [Review rounds, consolidated feedback process, response times.]

Production responsibilities: [Who handles printing, distribution, translation, web publishing, licensing, or event installation.]

File ownership and handoff: [Contractual or policy requirements for source files, licenses, and storage.]

Change-control process: [Who evaluates and authorizes additions to scope, schedule, or cost.]

For contracted work, the executed agreement and authorized change orders control; a project brief should not be used to bypass purchasing rules.

06 / Source material and factual review

Approved content: [Links or document references.]

Data and statistics: [Source, date, and verifying owner.]

Photography, illustrations, and logos: [Location and rights/permissions.]

Existing project files: [Location and version.]

Missing information: [Items, owners, and due dates.]

Who verifies accuracy? [Named subject-matter reviewer.]

What information may change before launch? [Known risks.]

07 / Schedule and dependencies

Hard deadline versus preferred date: [Distinguish them.]

Review turnaround: [Agreed working days.]

Risks and fallback: [What happens if content, approvals, or vendor delivery slips?]

08 / Budget and capacity

Approved budget or planning range: [Amount / pending.]

Budget owner and authorization: [Role.]

Internal staff capacity: [Hours / roles, if relevant.]

External expenses: [Printing, mailing, interpretation, photography, licensing, hosting, venue, or other.]

Procurement status: [Not started / in process / authorized / contracted.]

Budget assumptions: [Quantity, format, number of revisions, or other cost drivers.]

Approval needed for changes: [Authority and process.]

A brief can help define requirements before procurement. It does not itself establish vendor eligibility, funding authorization, or contract authority.

09 / Review, release, and governance

Feedback location: [Single controlled review link or file.]

Approval record: [Where the final signoff will be saved.]

Correction process: [Who verifies and approves changes after publication.]

For a deeper approval workflow, see Harbor's Building a Better Creative Approval Flow.

10 / Acceptance and measurement

What must be delivered to close the assignment? [Specific acceptance criteria.]

What must be true for the audience? [Usability or understanding criteria.]

Quality checks: [Accuracy, accessibility, links, specifications, proofreading, print proof, etc.]

Success indicators: [Appropriate evidence, with known limitations.]

Who evaluates the work? [Owner.]

Maintenance, archive, and records requirements: [Responsibility and storage.]

Post-launch review date: [Date.]

11 / Open questions and decisions

12 / Authorization to proceed

Project brief approved by: [Name and authority]

Approval date: [Date]

Approved version: [Version]

Conditions or exclusions: [Notes]

Next action and owner: [Assignment]

Choose the right brief for the assignment

Not every project needs the full master template. Use the core decisions, then add the fields that matter for the work.

Variation A — One-page collateral or report

For brochures, fact sheets, annual-report sections, presentation decks, posters, and print campaigns, prioritize:

• Primary audience and reading context.
• One main message and intended action.
• Page count, dimensions, print quantity, and distribution.
• Source text, data verification, photography, and permissions.
• Brand requirements and accessible digital version.
• Proofing, print vendor, delivery location, and final file formats.

Scope trap: “Just one more page” may affect layout, print cost, review time, and accessibility testing. Define who approves the change.

Variation B — Public outreach campaign

For community programs, planning projects, public meetings, and participation campaigns, add:

• The public decision and what remains open for input.
• Directly affected audiences and potential participation barriers.
• Outreach channels, distribution responsibilities, and partner roles.
• Meeting logistics, language access, accessible participation methods.
• Feedback collection, records, analysis, and response to the public.
• Required notice or hearing rules, where applicable.

Scope trap: Promoting an event is not the same as designing an equitable engagement process. Define which services the assignment includes. See Harbor's Community Outreach Planning Guide.

Variation C — Website or digital experience

For landing pages, resource hubs, online reports, forms, and service pages, add:

• The specific user task and how it will be tested.
• Content owner, content inventory, and migration responsibilities.
• Required integrations, data handling, security, and privacy review.
• Accessibility acceptance criteria and supported devices.
• Hosting, analytics, domain, redirects, and search considerations.
• Post-launch maintenance, training, ownership, and support.

Scope trap: A designed page and a working service are not interchangeable deliverables. Specify whether the assignment includes development, testing, publishing, and ongoing support.

A completed fictional example: town parks registration launch

Town: Briarfield, a fictional municipality.

Request as received: “We need a flyer and some social graphics to announce the new summer parks program.”

Rewritten project objective: Help parents and caregivers determine eligibility, find program dates and locations, and complete registration before the deadline.

Audience: Caregivers of eligible children; staff who answer registration questions; community organizations helping distribute program information.

Main message: “Summer program registration opens May 4. Check eligibility, locations, and how to register on the official town page.”

Deliverables: One accessible program landing page; one two-sided flyer; two social sizes; a staff FAQ; and a print-ready version of the flyer. The exact quantities and specifications would be confirmed during scoping.

Verified sources: Parks program director owns eligibility, dates, and locations. Registration administrator verifies the application process and contact information. Communications owns approved wording and design.

Access considerations: Test the registration pathway, provide usable alternatives where needed, and confirm language and accessibility requirements with responsible staff.

Out of scope: Registration software replacement, paid advertising, professional translation, and photography unless separately authorized.

Approval path: Program facts → communications/editing → access review → final release authority.

Acceptance: Final assets meet approved specifications; links and contacts work; public and staff instructions match; editable files and publishing responsibilities are handed off.

Measurement: Monitor registration questions and reported difficulties, not simply social-media impressions.

All names, dates, and circumstances above are illustrative. They are not a real project, past-performance claim, or measured result.

Six briefing mistakes worth avoiding

1. Asking for deliverables without identifying the need. Fix it by writing an audience-centered objective first.

2. Letting the scope expand through informal comments. Fix it by recording inclusions, exclusions, revision assumptions, and change authority.

3. Assuming someone else verified the facts. Fix it by naming source owners for dates, statistics, policy, and eligibility.

4. Treating accessibility as a final design pass. Fix it by defining applicable requirements and testing methods at kickoff. See the USWDS accessibility guidance.

5. Giving every reviewer equal decision authority. Fix it by distinguishing subject-matter review, advisory feedback, and final approval.

6. Calling a project complete when the files are delivered. Fix it by defining acceptance, publication, handoff, maintenance, and appropriate outcome measures.

The Harbor Project Brief Readiness Checklist

An original Harbor planning tool. It is not an official procurement or legal compliance checklist.

A. Purpose and audience

• The project problem is clearly defined.
• The objective describes an audience need.
• Primary and secondary audiences are identified.
• The audience's required next step is clear.
• Relevant barriers and access needs are considered.
• Fixed constraints and open decisions are distinguished.
• A project sponsor and day-to-day owner are named.

B. Content and creative

• The main message is understandable.
• Supporting claims have authoritative sources.
• Content and data owners are identified.
• Available assets and permissions are documented.
• Brand requirements and references are supplied.
• Missing inputs have owners and deadlines.
• The intended tone and call to action are specified.

C. Scope and delivery

• Each deliverable has a format and quantity.
• Included services are explicitly defined.
• Excluded services are recorded.
• Revision assumptions are understood.
• Final file formats and handoff needs are specified.
• Production, printing, or publishing responsibilities are assigned.
• Dependencies and schedule risks are documented.
• Budget and change-approval authority are confirmed.

D. Governance and quality

• Required subject-matter reviewers are named.
• Accessibility and language needs are reviewed.
• Applicable legal, privacy, records, and procurement considerations are identified.
• Feedback is collected in a controlled process.
• Final approval authority is identified.
• The exact approved version can be traced.
• Acceptance criteria are documented.
• Links, forms, facts, and production specifications will be tested.

E. Completion and stewardship

• Launch or delivery ownership is assigned.
• The project has an appropriate measure of usefulness.
• A correction and maintenance owner is identified.
• Final assets and decisions have an archive location.
• The next action, owner, and date are agreed.

The kickoff test

Before starting production, ask the team five questions:

1. What problem are we solving?
2. Who needs the result, and what must they be able to do?
3. What exactly are we delivering—and what are we not delivering?
4. Who verifies facts, approves changes, and authorizes release?
5. How will we know the work is ready and useful?

If the team cannot answer these questions, the brief is not finished. That is useful information: it is easier to resolve an unclear decision on page one than after the final design has been produced.

A strong brief gives creative work room to be excellent while giving the project enough structure to succeed.

Sources and further reading

• U.S. Web Design System — Design Principles: user needs, trust, continuity, and accessibility.
• U.S. Web Design System — Accessibility: planning and evaluating accessible experiences.
• CDC — Clear Communication Index: main messages, clear actions, and audience-centered communication.
• GOV.UK — Service Manual: public-service discovery, design, delivery, and iteration.
• GOV.UK — Understanding User Needs: grounding work in actual user needs.
• Section508.gov — Accessible Design Using USWDS: federal digital-design accessibility considerations.

Editorial note: This guide and its templates are original educational working aids. They do not replace an executed contract, authorized scope change, agency procurement procedure, legal review, accessibility assessment, or records-retention policy. The fictional example does not imply a Harbor client relationship or project outcome.