Design Asset Handoff Guide: Folder Structure, Naming Conventions & Export Presets (Checklist + Templates)

Overview

Organizing design assets for clients starts with separating working files from approved deliverables. A client should be able to open the main delivery folder and understand what is final, what is editable, and what each file is for. Avoid treating the handoff as an archive of everything created during the project. Unused explorations, duplicate exports, and unlabeled revisions create uncertainty.

A practical handoff has four layers:

• Read first: a brief guide containing the project name, delivery date, included files, software requirements, and any usage notes.
• Final exports: approved files prepared for the intended channels, such as web, social media, or print.
• Source files: editable Figma, AI, PSD, XCF, Canva, or other working documents, when included in the agreement.
• Supporting assets: fonts, icons, linked images, color references, mockups, and documentation that someone may need to update the work.

Use a consistent top-level structure such as:

PROJECT_NAME_HANDOFF/
├── 00_README/
├── 01_FINAL_EXPORTS/
│   ├── WEB/
│   ├── SOCIAL/
│   └── PRINT/
├── 02_SOURCE_FILES/
│   ├── FIGMA/
│   ├── ADOBE/
│   └── CANVA/
├── 03_BRAND_ASSETS/
│   ├── LOGOS/
│   ├── FONTS/
│   ├── ICONS/
│   └── COLORS/
├── 04_MOCKUPS_PREVIEWS/
└── 05_ARCHIVE_OR_EXPLORATIONS/

Adjust the structure to the project rather than creating empty folders. For a single poster, a smaller package may be clearer. For a brand kit, separating logo variations, color specifications, typography, and usage examples is usually more useful. The related graphic design asset workflow guide can help establish this system earlier in the project.

Checklist by scenario

For a web or app handoff

• Confirm the approved design version and remove outdated screens from the final folder.
• Export raster images at the dimensions requested by the developer or platform. Retain the original aspect ratio unless a crop is intentional.
• Provide SVG files for suitable logos, icons, and simple vector illustrations, after checking that they render correctly.
• Include image dimensions, intended placement, and whether an asset is decorative or functional.
• Use clear light and dark logo variants where both interface contexts require them.
• Document fonts, weights, colors, spacing, and component states if the handoff includes a design system.
• Check that linked images and fonts are either included, properly licensed, or replaced with approved alternatives.

For websites, avoid assuming that an editable source file is also a production-ready asset. A Figma frame may communicate layout while an exported SVG, PNG, or optimized image is what the implementation actually needs. If a team uses a specific delivery convention, follow it consistently across every screen.

For social media and content publishing

• Create folders by channel or content series rather than delivering one long list of numbered images.
• Include the intended aspect ratio and a plain-language description in the filename or README.
• Export a final upload version without guides, comments, or hidden objects.
• Keep an editable master separately from flattened publishing files.
• Check text at the smallest expected viewing size and inspect the edges for accidental cropping.
• Include alternate versions only when their purpose is clear, such as a text-free image or a dark-background variation.

Templates should be tested before delivery. If you are passing along editable design templates, verify that text fields, image replacements, layers, and instructions work as expected. See the editable design template audit checklist for a more detailed test process.

For print, posters, and packaging

• Confirm the printer's required dimensions, color mode, bleed, trim, safe area, and file format before exporting.
• Use a print-ready PDF preset or the printer's supplied specification when available.
• Inspect placed images for sufficient effective resolution at final size.
• Check overprint, transparency, clipping masks, linked assets, and missing fonts in the source file.
• Supply a proof or flattened preview so the recipient can compare the final file visually.
• Label dielines, folds, varnish, foil, or other special production layers separately and clearly.

Print requirements vary, so the export table is a starting point rather than a substitute for a printer's specification. For a more detailed preflight process, use the print-ready design template checklist.

Suggested export reference

What to double-check

Naming conventions

File names should answer three questions: what is the asset, which version is it, and where is it intended to be used? A useful pattern is:

project_asset_variant_channel_size_version.ext

For example: northstar_logo_white_web_1200px_v03.svg is more informative than logo-final-final2.svg. Use a consistent separator, keep version numbers explicit, and reserve words such as FINAL for approved delivery files. If a file is superseded, move it to an archive rather than leaving multiple competing finals in the main folder.

Licenses and usage notes

Record the source and permitted use of fonts, stock imagery, vectors, icon packs, and mockup templates. Do not assume that an asset can be redistributed simply because it was free to download. If fonts are not permitted in the handoff, provide the font name, license guidance, and an outlined or exported version where appropriate. The font license and usage matrix is useful for documenting this decision.

Visual and technical QA

• Open a sample of every delivered format outside the design application.
• Compare exports with the approved design at 100% scale where possible.
• Check transparency, color appearance, image sharpness, line breaks, and clipping.
• Confirm that filenames match the README and that links do not point to private or temporary locations.
• Download the complete package as the recipient would and test it from a clean folder.
• Check accessibility-related details relevant to the handoff, including readable contrast and meaningful text alternatives for documented web assets.

Common mistakes

• “Final” folders containing every version: Deliver one approved set and archive the rest separately.
• Missing dependencies: A source file with uncollected fonts, images, plugins, or linked files may not open correctly for another person.
• Format without purpose: Do not send five exports of the same asset without explaining when each should be used.
• Unclear editability: State whether a file is flattened, partially editable, or fully editable.
• Ignoring platform requirements: Social, web, and print outputs have different constraints. Create channel-specific folders and notes.
• Overlooking permissions: Include license notes and avoid handing over assets that the recipient is not allowed to reuse or redistribute.
• No handoff message: A short delivery email should identify the link, summarize the package, call out limitations, and invite confirmation of receipt.

A concise delivery message can follow this pattern: “The approved files are in the PROJECT_NAME_HANDOFF folder. 01_FINAL_EXPORTS contains upload-ready web, social, and print files; 02_SOURCE_FILES contains editable documents; and 03_BRAND_ASSETS contains supporting logos, colors, fonts, and icons. Please review the README for format notes and licensing details. Confirm that the package opens correctly and let me know if a required channel or variation is missing.”

When to revisit

Use this checklist before every client or team handoff, especially after a late design revision. Review the folder template and export guidance at least annually, and sooner when a major design tool changes its export workflow or when your team adopts a new format. Recheck tool-specific instructions approximately every six months if the package depends heavily on Figma, Adobe, Canva, or another platform.

Also revisit the system before seasonal content planning, a website redesign, a new print vendor, or a brand refresh. Platform requirements for Shopify, Webflow, social channels, and printers may change, so keep those notes separate from universal naming and QA rules. At the start of the next delivery, duplicate your clean folder template, remove unused sections, update the README, run the scenario checklist, and test the package from the recipient's point of view. That small routine turns a one-time handoff into a dependable creative workflow tool.