A project often becomes difficult because the parties imagined different outcomes. One person expected a simple brochure; another expected copywriting, photography and several versions for different audiences. A clear project brief makes those expectations visible before work begins. It should help delivery, not merely describe the ambition.
GOV.UK's user-needs guidance separates the outcome somebody needs from the features a team might build. That distinction is useful for client work too. The method below applies it to a small project brief. Formal contractual questions should go through the appropriate review process for your business.
Describe the outcome and the deliverable separately
Start with the client's purpose: “Visitors at the trade show need to understand our three service packages.” Then describe the deliverable: “A four-page print-ready brochure using approved package descriptions and supplied photographs.” The outcome explains why the work exists; the deliverable defines what you will produce.
Ask how the result will be used. A brochure intended for a print shop needs different output requirements from a document sent by email. Record file formats, dimensions, language versions and any accessibility requirements relevant to the use. Ask about these details before design choices depend on them.
Make inputs and decisions visible
List what the client will supply and when: approved text, logos, images, product details and one decision-maker's feedback. Note which tasks depend on those inputs. If a delivery date assumes complete text by Monday, write that assumption explicitly. A schedule without dependencies can look firmer than it is.
Agree who can approve work. Several stakeholders can contribute comments, but somebody needs to resolve conflicting directions. For the brochure example, ask the client to combine internal comments into one reviewed response. Otherwise, the supplier may waste time interpreting whether two incompatible requests have equal authority.
Specify review stages
Divide the work into sensible checkpoints. An outline review checks structure and content before detailed layout. A draft review checks the presentation. A final proof checks corrections before output. Give each stage a purpose so that a late strategic change can be recognised as a different kind of work.
Define what constitutes useful feedback. “The text is too small for a visitor reading it while standing” explains a problem. “Make it pop” does not. Encourage reviewers to describe the issue and its context, while allowing the person doing the work to suggest an appropriate solution.
Handle changes through a small decision process
When a new request arrives, record it, identify the affected work and explain the effect on the schedule or resources. Seek agreement on the revised plan before carrying out work that depends on that change. The process need not be elaborate; a clear written summary can be enough for routine projects.
Imagine the client asks for a second brochure version for a different audience. The content, layout and review effort may all change. Offer a choice: keep the original version and date, or agree a revised scope and schedule. Avoid treating every request as equally small simply because it arrived in a short message.
- Purpose: the audience's task and the client's intended outcome.
- Deliverables: formats, quantities, versions and agreed boundaries.
- Inputs: what is needed, from whom, and by which date.
- Decisions: who combines feedback and approves stages.
- Reviews: each checkpoint's purpose and expected response.
- Changes: how impacts are documented and agreed.
Close the loop at delivery
Check the output against the agreed deliverables and explain any remaining action the client needs to take. For a print-ready brochure, that might include sending the file to the chosen printer and confirming a production proof through their normal process. Do not assume the delivery file completes every downstream task.
A brief cannot predict every discovery. Its value is giving both sides a shared starting point and a sensible way to respond when the work changes. After delivery, note which ambiguity caused the most rework and improve that part of the next project's brief.
Sources and further reading
This original guide was prepared with AI assistance. Examples are illustrative. The edition date is an assigned date in this 2026 catalogue. See our editorial policy and report a correction.