Describe what the design must communicate
Explain the audience, location and intended action before naming a format. Provide approved wording or identify who owns the content decision. Distinguish mandatory information from suggestions, and explain which brand assets are locked. A designer should be able to see whether the task is attracting attention, explaining an offer, identifying a place or guiding a visitor. These purposes can require different hierarchies even when the physical output dimensions are the same.
Provide constraints that are actually known
Attach the selected system’s current template and record its version, units and scale. Give finished dimensions, viewing sides, material or mounting constraints and any confirmed safe areas. Mark unmeasured positions and proposed materials as open questions. Identify the rights attached to supplied logos, photography and fonts. Do not ask the designer to infer compatibility, licensed use or final production geometry from a cropped screen image of an older job.
Define deliverables and review responsibilities
State which outputs are needed: a concept, review proof, editable source, production file or several local variants. Name the content owner, visual reviewer and selected technical provider. Record the first review date and the conditions required for release. Comments should be collected against a specific proof version. A design brief can permit exploration without accepting production, so avoid describing a concept request as approval to make the finished work.
Worked example — fictional
A fictional campus needs reception graphics for an open day. The brief states the visitor action, approved destination name and measured sign position. It permits local opening times in a defined field but retains a locked logo. The designer receives a template and a request for a layout concept, not an assumption that a browser preview is print-ready. One department supplies a different building name; the named content owner resolves it before the next proof. The accepted wording and subsequent proof version remain linked to the same brief.
Briefing pitfalls
Avoid asking the designer to solve a content ownership dispute by choosing whichever wording fits best. Supplying several logo versions without explaining their status creates another decision instead of an asset pack. A past successful print does not establish that the same file is suitable for a different frame or substrate. Name the actual open question and responsible person so design exploration does not silently become technical acceptance.
Avoid preventable review loops
Check that reviewers have authority for their decisions and can see the relevant information. Resolve competing content instructions before passing them back as design changes. When the campaign changes, record what differs and which deliverable is affected. Use the brief tool and export the current constraints with the task. The useful result is a designer who can act on specific inputs while seeing the questions that still need responsible answers.
Take this to the next job
- Explain audience and intended action
- Supply approved content or its owner
- Attach the exact template and asset rights
- Name required deliverables
- Separate concept, proof and technical acceptance
