How to deliver design files to clients — no 'final' chaos

You open your sent folder. There are three attachments from the last client review: a PDF called homepage_v3_FINAL.pdf, a JPEG someone exported from Figma with red MS Paint markups, and a Google Drive folder called "FINAL_ASSETS". Nobody knows which one to build from.

This is the scene you can end. You do not need more folders. You need one clear answer to the question clients always ask in some variation: which file is final?

How to deliver design files to clients (and stop the 'which file is final' chaos)

You want developers to ship the right thing. You want the client to sign off. That primarily comes down to two rules:

• Have one canonical source of truth.
• Make it trivial to prove something is approved.

Here’s a practical handoff that actually works in freelance and small-studio situations, whether you use Figma, Sketch, or an ancient PDF workflow.

1) Decide the canonical source before you export anything

Pick the place you’ll treat as the source of truth. Usually that’s a Figma file or a versioned folder in Drive. Tell the client upfront: “The Figma link is the source. Exports are snapshots.” Say it in email, in the handoff README, and in the approval step.

If you can keep everything in Figma, do it. If the client insists on PDFs for legal reasons or a designer on the team needs InDesign, accept it — but make the mapping explicit.

2) Naming: short, consistent, useful

Trash the ritual of FINAL_FINAL_v3_reallyFINAL.png. Use a simple pattern. I recommend:

• project-component_version-status_date.ext

Examples:

• acme-homepage_v3_approved_2026-06-10.fig
• acme-logo_v1_production_2026-06-10.svg
• acme-assets_v1_exports_2026-06-10.zip

Notes:

• Use ISO dates (YYYY-MM-DD). They sort.
• Use status: draft | review | approved | production.
• Don’t write "final" alone; it becomes meaningless.

3) Deliver exactly three things (minimum)

1. The source file or link (Figma link, .fig, .sketch, .indd). This is editable. Label it clearly as the source. 2. A production folder of exports developers/printers use (SVGs, optimized PNGs/JPGs, PDFs). Include device/usage labels (logo_primary.svg, hero_1920x1080.jpg). 3. A README (short!) that lists file purposes, fonts and license info, color codes, export specs, and the official approval evidence and date.

That README is your friend. Put it at the top of the handoff folder and in the body of your delivery email.

4) Versioning rules everyone can agree on

• Stop with v1, v2, v3 unless you track change purpose. Instead, note the action: v2_review, v2_client-edits, v2_approved.
• Tag the approved version with a date and the approver: v2_approved_2026-06-10_ALICE.
• If you use Git-like history or Abstract, reference that commit/branch in the README.

5) What to include in a ready-for-dev export checklist

• All final artboards/screens exported at required resolutions.
• SVGs cleaned of editor metadata.
• Raster images optimized and high-res copies for print.
• Fonts: specify embedded vs attached; include license files or use web fonts.
• Color tokens and hex/RGB/CMYK values.
• Interaction notes or a clickable prototype link.

If it’s for print, add bleed, crop marks, and the export setting used.

6) Approval: make it explicit and irreversible

An approval email is okay. A typed signature is better. Even better: capture approval directly on the files. Use a quick approval workflow so the client doesn’t say "we never approved this" later.

Tools help here. For quick, account-free approvals and a typed-signature sign-off, collect approvals with ClientMarkup. You can link the approved snapshot in the README and include the approval timestamp and signer name. That single approved file becomes your legal snapshot.

Most disputes aren’t about design. They’re about "which version do we agree was final?" Capture that agreement.

7) Folder structure that scales

Example handoff root (keep it shallow):

• ProjectName_Handoff_2026-06-10/
• README.md
• Approved_Source/ (e.g., Figma link or .fig)
• Production_Exports/ (SVG, PNG@2x, PDFs)
• Dev_Package/ (specs, tokens.json, Zeplin/Inspect links)
• Fonts_and_Licenses/
• Approval/ (signed approval screenshot or ClientMarkup link)

Keep the structure identical across projects. Developers and clients will thank you.

8) Email + Folder + One sentence in the README

Your delivery email should be three parts: what you’re delivering, what they must confirm, and a single next step. Attach the README or paste it into the email body.

Example sentence to paste into the README and email: "The canonical approved files are in Approved_Source (Figma link). The production exports are in Production_Exports. By replying APPROVED to this message or signing via the provided ClientMarkup link, you confirm this is the version for production."

9) Practical edge cases

• Client asks for all source files and fonts? Deliver them but include license files and a note: "Fonts licensed to CLIENT; do not redistribute."
• Client annotates a PDF with marks? Ask them to annotate the source or drop pins on a shared Figma / ClientMarkup link. Scanned markups are fine as requests, not approvals.
• Multiple stakeholders? Require one official approver. Keep a CC list for visibility.

10) Quick handoff template (paste-ready)

• Source (canonical): [Figma link] — last edited 2026-06-10 — status: approved_2026-06-10_ALICE
• Production exports: /Production_Exports/
• Dev notes: /Dev_Package/
• Fonts & licenses: /Fonts_and_Licenses/
• Approval evidence: /Approval/approved_2026-06-10_ALICE.png or ClientMarkup link

Delivering design files to clients is not a ritual. It’s a contract of clarity. Make the contract small, obvious, and signed. You’ll lose fewer hours chasing versions, and the devs will ship what you designed.

When you hand this off, close the loop: upload the snapshot, paste the README into email, and get the one-line approval. Then archive the exact approved folder. That archive is your fallback — concise, dated, and defensible.