The simplest handoff test is this: can the recipient open the project, identify the approved deliverables, understand its dependencies and continue the work without access to your desktop or memory? If not, the source file has been transferred, but the project has not really been handed off.
A handoff should preserve continuity, not just files
While you are working, the project contains knowledge that may not exist anywhere in the document itself: which source is current, which render was approved, where linked media lives, which font licence belongs to whom and which export preset the supplier expects. The purpose of a handoff is to turn that hidden knowledge into a package another person can operate.
A useful package therefore answers four things quickly: what can be edited, what dependencies it needs, what output has been approved, and what the next person must know before changing or reproducing it. Anything that depends on “ask me later” is a handoff risk.
Separate source, dependencies and approved output
| Layer | Typical contents | Purpose |
|---|---|---|
| 01_SOURCE | AI, PSD, INDD, AE/Premiere or other editable project files | Makes the authoritative editable source obvious |
| 02_ASSETS | Linked images, footage, audio, illustrations, textures and distributable dependencies | Allows the project to reopen without reaching into the original workstation |
| 03_OUTPUT | Approved PDF, SVG, PNG, JPG, MP4 or production deliverables | Separates usable/approved deliverables from editable working files |
| 04_REFERENCE | Brief, brand guidance, supplier specification, relevant reference | Preserves the context needed to continue decisions |
| 05_README | Version, software, dependency, licensing and production notes | Transfers the knowledge that file structure alone cannot express |
The labels can change. A motion project may split outputs into masters and platform variants; a UI project may use a Figma source link plus exported assets. The important principle is that the recipient never has to guess whether a file is an editable source, a dependency or an approved deliverable.
Package external dependencies before you archive the project
An Illustrator or InDesign file can reference graphics stored elsewhere. It may look complete on your machine and open with missing links on someone else’s. Adobe’s Illustrator Package command can collect linked graphics, optionally place them in a Links folder, relink the packaged document and create a report. Its InDesign packaging workflow similarly gathers the document, linked graphics, eligible fonts and production information.
The broader practice is more important than the command: identify everything that lives outside the source file and decide whether it belongs in the handoff. Package tools help with supported dependencies, but video caches, plug-ins, LUTs, external libraries or cloud-linked assets may need separate treatment depending on the application.
- Resolve missing links first
Do not package a knowingly broken source and expect collection to repair the project.
- Remove obsolete dependencies
A four-gigabyte unused footage folder is not documentation; it is noise and transfer cost.
- Test relocation
Move the package away from its original path and reopen it. A real handoff should not silently depend on your old drive structure.
- Document non-packaged dependencies
If a plug-in, cloud library, LUT or licensed stock element cannot travel with the project, state what the recipient needs and where it comes from.
Font packaging is a licensing decision
Packaging features can make font collection look like a purely technical step, but font files are licensed software/assets. Adobe’s Illustrator documentation explicitly tells users to check the licence agreement before copying fonts into a package. Having a font installed and licensed on your own workstation does not automatically give you permission to redistribute the font file to a client.
A clean handoff records the dependency even when the binary cannot be distributed. List the font family, weights and acquisition/activation path; ask the client or next team to obtain its own licence when required. Convert type to outlines only where editability is genuinely unnecessary and the design system can tolerate that decision—such as a final logo asset—not as a blanket way to avoid font management.
Use filenames to encode decisions, not anxiety
Version names such as final-final-REAL-2 do not communicate a reliable history. A practical naming scheme makes the differentiators visible: project, asset or placement, composition/locale if relevant, output type and a simple sequential version. Approval status can be added only when the approval actually happened.
| Ambiguous | More useful |
|---|---|
| hero_new2.psd | launch-hero-keyvisual-rgb-v06.psd |
| logo_final.png | brand-logo-horizontal-white-rgb-2000w.png |
| filmson.mp4 | launch-film-16x9-en-master-h264-v04.mp4 |
| deck_last.pdf | campaign-deck-client-approved-2026-08.pdf |
Do not force every possible metadata field into a 180-character filename. The point is to distinguish files at a glance; deeper production notes belong in the README or project documentation.
A short README transfers the information folders cannot
For many creative projects, a plain README.txt or short PDF is enough. It should not repeat the brief. It should record the information a competent collaborator would otherwise have to ask before opening, editing or exporting the work.
- Project and handoff date
- Authoritative source file or source link
- Approved/final deliverables
- Required application/version when compatibility matters
- Fonts, plug-ins, codecs, LUTs or other dependencies
- Font/stock/asset ownership and acquisition notes
- Elements intentionally outlined, flattened or made non-editable
- Critical colour profile, frame rate, PDF or supplier settings
- Known open items or deliberate limitations
- Responsible contact/owner
Editable source does not replace delivery-ready output
Clients should not need Illustrator to extract a logo they can place in a presentation. A motion client should not need After Effects to find the approved master film. A printer should not have to reconstruct a production PDF from your source unless that is explicitly their role. Source files preserve editability; outputs preserve the approved state that was actually intended for use.
This separation also protects the archive. Months later, the newest modification timestamp on a PSD or AEP does not necessarily identify the asset that was approved or published. An explicit OUTPUT/APPROVED layer provides evidence of what left the project at handoff.
Run the package as if you were the recipient
- Relocate it
Copy the package to a clean folder or extract the final ZIP somewhere unrelated to the working path.
- Open the authoritative source
Resolve any missing-link, offline-media, missing-font or plug-in warning that would block continuation.
- Open every critical output
Verify the PDF, image, SVG or master render is intact and matches the approved version.
- Follow only the README
Ask whether someone unfamiliar with the job can identify what to edit and what not to overwrite.
- Build the final archive from the tested package
Do not send an older ZIP made before your validation fixes.
Final professional handoff checklist
- Is the authoritative editable source obvious?
- Are required linked image/video/audio assets present and relinked?
- Are missing font/link warnings resolved or explicitly documented?
- Have font and third-party asset redistribution rights been checked?
- Have caches, obsolete revisions and unnecessary test exports been removed?
- Are approved final outputs separated from editable source?
- Do filenames make variant/version decisions understandable?
- Does the README capture software, dependency, licence and technical-production notes?
- Has the package been moved/extracted and reopened independently of the working path?
- Is the file or cloud folder being sent exactly the package that passed that test?