A delivery note should answer the questions a recipient needs to use the files immediately. It is neither a diary of the illustration process nor a substitute for clear filenames. Identify what is included, which files serve which purposes, what revision is approved, and any practical dependencies or limitations the recipient must understand before placement or editing.
Lead with the supplied artifacts and their roles
State the project and revision identifier, then list the main file groups in plain terms. For example, the package may contain a wide website header, square card, print PDF, and layered source. Explain dimensions or color differences only where they matter. A recipient should not have to infer whether two similarly named images are alternative crops, different quality levels, or an accidental duplicate.
Identify the approved version and any earlier file it replaces. If this is a corrected delivery, name the superseded revision explicitly. Avoid vague language such as use the newest one, because copied files may have misleading timestamps. The note should remain understandable when forwarded without the surrounding conversation or when the package is reopened months later by someone who did not participate in review.
Describe editable-source dependencies concisely. Mention required fonts, linked resources, application version considerations, or known conversion limits that affect the agreed workflow. Include where permitted resources are located or how to obtain excluded ones. Do not describe a source as fully editable if important text or effects were deliberately flattened; explain the actual boundary between preserved appearance and editable construction.
Include only information that changes the recipient's next action
For print work, reference the confirmed supplier specification and approved proof where relevant. For transparent assets, note intended background variants or whether a shadow is already included. For screen images, state the intended placement if dimensions alone are ambiguous. These details help prevent predictable integration errors, such as adding a second shadow or using a small card image as a large print source.
Call out any agreed exception or unresolved integration check honestly. If the recipient must verify a platform crop or font availability, state the required action and responsible role through the existing project process. Avoid inventing assurances about environments you could not inspect. A concise limitation is more useful than a broad claim that every file will work perfectly everywhere.
Keep transfer and access instructions clear when the files are delivered through a link or archive. Identify any relevant expiration or password process according to the agreed channel, without mixing sensitive credentials into public notes. Check that the intended recipient can locate the package. The delivery message should point to a concrete artifact, not merely announce that the illustration is finished somewhere on your computer.
Archive the note with the exact package it describes. If a later correction changes the contents, issue an updated note tied to the new revision rather than silently reusing the old description. A useful delivery note provides a compact map from files to purposes and actions, allowing the recipient to proceed confidently while preserving a factual record of what was supplied and what still required their attention.