What Makes a Good Project Brief?

State what should be different when the project is complete. Avoid vague phrases such as “make it better.” A useful outcome might be a launched website, an organized evidence library, a documented workflow or a decision-ready research report.

Who is the work for? A public website, internal operations document and investor presentation may contain some of the same information but organize it very differently. Audience changes the language, depth, format and design.

Explain what already exists. Include current websites, files, research, brand assets, previous attempts, known problems and anything that should be preserved. This prevents duplicated work and helps identify whether the project needs a rebuild or an improvement pass.

Deadlines, budget limits, required platforms, legal constraints, existing technology and unavailable information can all affect the right solution. A constraint discovered at the beginning is a design input. The same constraint discovered at the end can become rework.

Deliverables convert the idea into something reviewable: pages, reports, templates, workflows, research summaries, navigation structures, launch materials or other specific outputs. This creates a shared understanding of what is actually being built.

A project moves faster when completion is measurable. Decide what needs approval, what must function, what must be tested and what can wait for a later phase. “Done” should describe a usable result, not simply the point where time runs out.

Explore DDPW Project Strategy →