Asset handoff goes wrong in predictable ways, and nearly all of it is avoidable with a short conversation before export.

The Three Questions to Ask First

  1. What are the display dimensions? Not the design canvas size — the actual rendered size in the interface, at each breakpoint. Everything else follows from this.
  2. Which pixel densities are supported? 1×, 2×, 3×? Web usually needs 1× and 2×; mobile apps often need 3×.
  3. Can it be vector? If yes, most of the export work disappears.

Asking these three prevents the most common failure: exporting at the wrong size and doing it again twice.

Vector vs Raster

Send SVG when: icons, logos, illustrations with flat shapes, anything that scales, anything that needs to change colour with the theme.

Send raster (PNG/WebP/JPEG) when: photographs, complex gradients and textures, images with many effects, or when the SVG would be enormous (a traced illustration with thousands of paths is often larger than a PNG).

For SVG, do the cleanup before handing over: strip editor metadata, remove hidden layers, reduce coordinate precision, flatten unnecessary groups, and convert text to outlines *or* confirm the font is available. A raw editor export is frequently ten times larger than an optimized one.

Raster Export Rules

  • Export at the highest density needed, and let the build generate smaller ones if the pipeline supports it.
  • Use exact pixel dimensions. An asset that's 101 px wide because of a rounding error causes half-pixel rendering and blurry edges.
  • Choose format by content: JPEG or WebP for photos, PNG for anything with transparency or sharp UI edges, WebP/AVIF where the project supports them.
  • Transparent backgrounds for anything that isn't a full-bleed photo — developers can always add a background, but can't remove one.
  • Trim whitespace consistently, or specify the padding deliberately. Inconsistent padding around icons is a classic alignment headache.

Naming That Maps to Code

Use a predictable, code-friendly convention:

icon-search-24.svg
[email protected]
hero-homepage-1920x1080.jpg
logo-primary-dark.svg
logo-primary-light.svg

Rules: lowercase, hyphens, no spaces, size or variant in the name, density suffix by platform convention. Never include a date, a version number like v3-final, or the designer's initials.

What Else to Include

  • A manifest: a short document or spreadsheet listing each asset, where it's used, its display size and any behaviour (hover state, dark-mode variant).
  • Dark-mode variants where the design has them — and say explicitly whether the asset should recolour via CSS or be swapped.
  • The source files, not just exports. Developers occasionally need to re-export at a size nobody anticipated.
  • Fallback guidance: what should render while an image loads, and what happens if it fails.
  • Licence information for any stock or third-party imagery, so it doesn't ship without rights.

Preventing Repeat Rounds

  • Export from a component-based structure so a change regenerates everything consistently.
  • Automate exports where the tool supports it, rather than manually slicing.
  • Provide one extra density beyond what's requested; it costs nothing and saves a round trip.
  • Sit with a developer once and watch them integrate assets. Twenty minutes of observation removes most future friction, because you'll see exactly which of your conventions cost them time.