A project brief brings together the problem, objective, audience, scope, deliverables, constraints and approval responsibilities. For identity, website or content work, it should explain what needs to change and how the work will be accepted, giving everyone a shared reference before delivery.
Explain the problem before the appearance
“We need a modern website” describes a desired impression. It does not explain whether visitors misunderstand the services, see an outdated business or struggle to request a quotation. Describe the current situation and the observable change you need.
Include examples of existing materials and identify what should remain. When sharing a visual reference, explain whether you value its structure, writing or project presentation. A link alone leaves too much open to interpretation.
Define the audience and content
State who will use the output, what they already know and which decision it should support. Procurement materials serve a different situation from a first introduction. Record the central message and information that must appear.
List available approved copy, images, logos, service information and documented projects. Assign responsibility and dates for missing inputs. Content readiness affects delivery and belongs in the brief from the beginning.
Agree on outputs and boundaries
Describe deliverables concretely. For a website, distinguish writing, page design, development, content entry and integrations. For an identity, separate the visual system from its applications.
Also document exclusions, agreed review rounds and the people responsible for approval. This allows both sides to assess scope before production starts.
Establish approval criteria
Replace “make it better” with useful questions: Can the intended audience understand the offer? Does the material work in its intended setting? Are both languages consistent? Will the team receive the files it needs to use the work?
A hypothetical company profile review might check factual accuracy, service hierarchy, image suitability and bilingual consistency. Taste still matters, but it no longer carries the entire decision.
A project brief template you can complete
| Field | What to record |
|---|---|
| Background | The company’s situation and what has changed |
| Problem | An observable customer or team difficulty, with an example |
| Objective | What should become clearer or possible after the project |
| Audience | The primary user and other decision participants |
| Scope | Included work, exclusions and required integrations |
| Deliverables | Outputs, languages and necessary formats |
| Inputs | Available materials, missing items and their owners |
| Approval | Reviewers and the final decision maker |
| Constraints | Agreed budget, timing and relevant requirements |
| Acceptance | Conditions to verify at handover |
For a website, “two languages” is not enough. Clarify who writes, translates and enters content, which pages are included and whether forms and integrations are covered. The brief need not contain every technical detail, but it should expose decisions that still require agreement.
How should new requests be handled during delivery?
Record the request and compare it with the approved scope. Correcting an error in an agreed element differs from adding a page, language or function. If the request changes the outputs, document its effect on timing, cost and inputs, then obtain approval from the responsible person before implementation.
Keep a version number and approval date for the brief. Resolve conflicting feedback into one decision instead of sending simultaneous instructions to the delivery team. Everyone should know which version they are working towards and who resolves a change in requirements.
Ask the delivery team to restate the brief before work begins. Differences discovered at this stage are easier to resolve than differences discovered after production.
Continue with: Positioning and messaging workbook · Direction and strategy
