How to Send Design Files to a Client: Build the Package Before You Export

Updated

An open brand handoff package holds selected final assets while sketches, review sheets, and alternate designs remain outside it.

Start with what the client needs. Decide what each file is for, whether it must be editable, which format fits, and what guidance to include. Then export only the files the handoff needs.

The logo is approved, but the working folder is not a deliverable.

It may contain rejected directions, review PDFs, temporary exports, editable masters, and several versions of the same asset. Opening the export menu does not tell you which of those files the client should receive.

Before exporting, turn the agreed scope into a handoff manifest.

A package is complete when every agreed use has a clearly identified file the right person can use—not when every possible format is exported.

That standard works in both directions. It reveals a missing file when the client has an agreed use with nothing suitable to open. It also reveals unnecessary files that have no recipient, task, or place in the scope.

Start with the agreement, not the file formats

First, write down what the project includes.

Use the signed agreement, approved change orders, and final written decisions. Identify:

  • the selected design direction;
  • the final deliverables;
  • the approved variations;
  • whether editable source files are included;
  • any excluded concepts, working files, or review rounds.

This is a project-scope check, not a universal conclusion about ownership. Payment alone does not answer which source files belong in a particular handoff, and neither does a generic industry checklist.

If the agreement clearly includes an editable source file, prepare the selected final source for delivery. That does not require sending every exploration, rejected direction, or untidy working file created along the way.

If the agreement excludes source files, do not add them merely because a logo-package template contains a Source folder.

If the agreement is unclear or disputed, resolve that question with the client—and seek qualified advice when necessary—before assembling the package. The export stage is too late to invent the boundary.

Build the handoff manifest before exporting

Create one manifest entry for every agreed use:

Deliverable:
Recipient:
What will they use it for:
Editability: ready to use / production ready / editable
Source file included under the agreed scope: yes / no
Format:
Usage note:

The recipient is the person who must use or pass on the file after handoff. That may be the client owner, a marketing teammate, a web developer, a print vendor, or a future designer.

What they will use the file for should be concrete:

  • place the logo in a presentation;
  • add it to a website;
  • send it to a sign printer;
  • consult the brand rules;
  • adapt the approved artwork later.

Avoid entries such as “logo files” or “for future use.” They do not tell you what the file must do.

Once the tasks are named, run two checks:

  1. Does every agreed use have a file?
  2. Does every file have a justified use?

If the first answer is no, the package is incomplete. If the second answer is no, remove the unexplained file or explain why it belongs.

Decide source file or final export

The required editability changes the file you prepare.

Ready to use

The recipient should be able to place the asset without changing the design. A client adding a logo to slides or a social profile usually needs an export, not the file used to construct the logo.

Production ready

A specialist needs an asset prepared for a defined output. Ask the printer, fabricator, developer, or other vendor for the required specification rather than assuming one “print file” or “web file” fits every workflow.

Editable

A future designer or production partner needs to modify the approved work. Include a cleaned native or interchange source only when that editable handoff is part of the agreed scope. State the software and any external assets required to use it.

This classification keeps “source file” from becoming shorthand for “everything in the working folder.” The relevant question is whether an editable final file is both agreed and necessary for the job.

Choose a format because of the use

Formats should follow the manifest rather than become the manifest.

  • Scalable logo use: An SVG can serve a web developer who needs approved artwork that scales without becoming a raster image.
  • Everyday digital placement: A transparent PNG can serve a client placing the logo into slides, documents, or social graphics.
  • Print production: Supply the print-ready format and specification confirmed by the vendor. Do not assume every printer wants the same file.
  • Reference material: A PDF can carry brand guidelines in a form intended for reading rather than editing.
  • Future editing: A cleaned native or interchange file can serve a future designer when editable source access is included in the agreement.

These are mappings, not a mandatory five-format package. One project may need all of them. Another may need only a guidelines PDF, a transparent image, and a scalable web asset.

The file still has to work for the person receiving it. If the client cannot use the design tool, provide an approved export through a method they can open, label it clearly, or identify the specialist who should receive it.

Worked example: the Harbor Café identity

Nora is an illustrative independent brand designer finishing an identity for Harbor Café.

The approved scope includes:

  • primary and compact logo variations;
  • light and dark versions;
  • a short brand-guidelines document;
  • social avatar exports;
  • the selected editable vector source.

It does not include rejected concepts or review-round files.

Before opening her export settings, Nora creates five manifest entries.

1. Client owner: slides and social posts

  • What they need it for: Place the logo without design software.
  • Editability: Ready to use.
  • Source access in scope: No for this task.
  • Format: Transparent PNG exports in the agreed variations.
  • Usage note: Identify which file belongs on light and dark backgrounds.

2. Web developer: website implementation

  • What they need it for: Add the approved logo to the website at different display sizes.
  • Editability: Implementation, not logo redesign.
  • Source access in scope: No for this task.
  • Format: SVG exports of the primary and compact variations.
  • Usage note: Mark which variation is primary and when the compact version is intended.

3. Print vendor: menu and sign production

  • What they need it for: Reproduce the approved logo to the vendor’s specification.
  • Editability: Production ready.
  • Source access in scope: No for this task.
  • Format: The print-ready vector PDF requested by the vendor.
  • Usage note: Identify the approved print colour version.

4. Client team: brand reference

  • What they need it for: Check the logo, colour, and typography guidance.
  • Editability: Read-only reference.
  • Source access in scope: No.
  • Format: Harbor-Cafe-Brand-Guidelines.pdf.
  • Usage note: Start here before choosing an asset.

5. Future designer: agreed adaptations

  • What they need it for: Edit the selected final vector artwork for future applications.
  • Editability: Editable.
  • Source access in scope: Yes.
  • Format: The cleaned native source named in the agreement.
  • Usage note: State the required software and identify any external assets or licensing constraints.

The manifest exposes both kinds of package error.

A review PDF has no agreed use, so Nora leaves it out. If the client also needs a file for an agreed use that has no manifest entry, Nora adds the entry and prepares the missing file before delivery.

The result is not “every common logo format.” It is the set Harbor Café needs for the uses Nora and the client agreed.

Turn the manifest into an identifiable package

Nora organizes the files by what the recipient will do with them:

Harbor-Cafe-Final-Identity/
├── 00-START-HERE/
├── 01-EVERYDAY-USE/
├── 02-WEB/
├── 03-PRINT/
├── 04-GUIDELINES/
└── 05-SOURCE/

The exact structure should change with the project. A smaller package may not need six folders. A larger one may need separate sections for campaigns, templates, photography, or other agreed deliverables.

The names inside each section should identify the asset without requiring the recipient to open several files:

Harbor-Cafe-Logo-Primary-Dark.png
Harbor-Cafe-Logo-Compact.svg
Harbor-Cafe-Logo-Primary-Print.pdf
Harbor-Cafe-Brand-Guidelines.pdf

Put a short guide or manifest first. It should state:

  • what is included;
  • which section serves each use;
  • which variation to choose;
  • whether editable source files are included;
  • who to contact when an unlisted format is required.

If a large brand package needs a walkthrough, put the same orientation in a short start-here guide so it travels with the files.

That way, the next recipient gets the same orientation without relying on the original call.

Run the package acceptance check

Before choosing how to send the files, inspect the package against the manifest:

  1. Is every file part of the selected, agreed deliverable?
  2. Does every agreed use have a file?
  3. Is each file ready to use, production ready, or editable as required?
  4. Does each source file have both an agreement basis and a real use?
  5. Can the intended person open the file or pass it to the correct specialist?
  6. Does each filename identify the asset and variation?
  7. Does the start-here guide explain unfamiliar formats and exclusions?
  8. Are rejected concepts, temporary exports, and review files absent?

Do not add files simply to make the package look larger. Do not remove a necessary format merely to make it look tidy.

Now choose how to deliver it

Once the final package is defined, delivery becomes a separate decision.

The client may need continued access in Figma, a final folder in Drive, a one-time transfer, or another method. The Google Drive alternative for client delivery explains how to choose among those jobs without assuming Drive must be replaced.

Litehost can enter here as one possible browser-link delivery method for selected final files. It does not decide the project scope, source-file entitlement, formats, or active design collaboration. Use it only when a client-ready link fits the package you have already defined and after confirming the selected files behave as intended.

When every agreed use has an identified file and every included file has a stated use, the package is ready to deliver.