Ecommerce Product Image Export Workflow from Figma

An ecommerce image rarely lives in just one place.

The same product visual might show up on a collection page, a product detail page, an email campaign, a paid social variant, and a CMS card that gets cropped differently on mobile. The design team approves the image once, but the production team inherits five different export problems: the hero is too heavy, the thumbnail is too soft, the zoom image is overkill, the filenames are unclear, and someone uploads the wrong version to the storefront.

That is the part TinyImage helps clean up. The win is not only smaller files. The win is turning product image export into a predictable step that fits the rest of the storefront workflow instead of a pile of last-minute asset fixes.

Start by sorting images by storefront job

Most ecommerce teams get into trouble because they export by frame, not by purpose.

Before touching format or compression settings, label each image by the job it has to do:

• pdp-hero: the main product image or lifestyle visual on the product page
• pdp-detail: close-up texture, packaging, feature detail, or alternate angle
• collection-thumb: smaller product grid image that has to stay recognizable fast
• promo-tile: image used in homepage modules, category promos, or sale banners
• email-asset: an image that may be reused in a campaign where weight matters more

That small classification step solves a lot of downstream confusion. A product detail image should not be compressed the same way as a 180-pixel collection thumbnail, and a homepage promo tile does not need the same level of zoom-ready fidelity as a product page hero.

If your team already publishes approved assets into a CMS, CMS Image Publishing Workflow from Figma is the best companion read.

Decide what needs to stay sharp

Ecommerce visuals often mix photography with interface-like details:

• packaging text
• ingredient callouts
• spec cards
• before-and-after comparison labels
• small badges like “new,” “limited,” or “best seller”

Those details can fall apart quickly if the team chases file size without checking how the image will actually render.

A good rule is to ask one question for every export:

What part of this image would cost us money if it became hard to read?

Sometimes that answer is the product texture. Sometimes it is the label on the bottle. Sometimes it is the overlay text inside a promo module. Once the critical area is known, compression becomes much easier to judge.

Use different format rules for different page roles

Treating every product image as a PNG is safe, but it is also one of the easiest ways to end up with bloated storefront pages.

My default approach looks more like this:

• Use PNG when the image has fine edges, embedded text, or transparent backgrounds that need to hold up cleanly.
• Use WebP when the image is photographic and appears in multiple merchandising placements where lighter weight helps.
• Use AVIF when the storefront stack already supports it cleanly and the team wants to push weight down further on image-heavy pages.
• Keep JPG only when the publishing stack or downstream retailer still expects it.

The point is not to sound modern. The point is to match the format to the real usage.

If format choice still feels fuzzy, WebP vs AVIF for Figma Exported Images is worth reviewing before you lock the team into one default.

Build one export matrix before the launch rush

The easiest way to stop repeated Slack questions is to define the export matrix up front.

For one product launch, that might look like this:

• product page hero: higher fidelity, desktop and mobile variants
• product detail images: medium-to-high fidelity, prioritize readable detail
• collection thumbnails: lighter exports, optimize for fast grid loading
• homepage promo blocks: weight-conscious, but still brand-polished
• email campaign images: lighter again, because inbox performance matters

Once that matrix exists, the team can stop debating every single image individually.

TinyImage is useful here because the export pass can stay inside Figma instead of bouncing between Figma, an online compressor, a desktop app, and a CMS upload tab. That usually removes the most annoying part of the workflow: repeated re-exporting after someone realizes the first version was either too soft or too heavy.

Review product images at the size customers will actually see

This is the step people skip when they are busy.

Do not only inspect exports zoomed in on a large display. Review them at realistic rendered sizes:

• a mobile product page width
• a desktop collection grid card
• a promo module inside a homepage layout
• an email slot if the same image will be reused in lifecycle or campaign sends

That review often changes decisions. An image that looks “fine” at 200 percent may feel muddy at real mobile width. A file that looks overly compressed on a retina display may be completely acceptable in a small collection card. Real slot review is where you stop optimizing in the abstract.

For teams exporting more interface-heavy images, Product Screenshot Export Workflow for SaaS Landing Pages covers a similar review discipline from a different angle.

Name exports like someone else has to upload them

Ecommerce asset handoff breaks surprisingly often because the file names are a mess.

Instead of names like final-product-2-new.webp, export files in a way that makes placement obvious:

• olive-oil-pdp-hero-desktop.webp
• olive-oil-pdp-hero-mobile.webp
• olive-oil-collection-thumb.webp
• olive-oil-summer-sale-promo.png

That matters because ecommerce teams usually upload in batches, and the person doing the CMS work is not always the same person who designed the image. Clear naming reduces accidental swaps, duplicate uploads, and mystery files that get reused months later in the wrong context.

A practical TinyImage pass for a launch week asset set

When a launch is close, simplicity beats cleverness.

Here is the pass I would standardize:

1. Group approved product visuals by page role.
2. Remove unused whitespace or decorative padding that adds weight but no merchandising value.
3. Export one fidelity-first version for each critical asset.
4. Export one lighter alternative for grid and campaign usage.
5. Review both against the real slot size.
6. Keep only the version that protects the selling detail and meets the page-speed target.
7. Hand off with placement-based filenames and a short upload note if there are desktop/mobile variants.

What TinyImage does not decide for you

TinyImage will not tell you which crop sells the product best, whether the detail shot should replace the lifestyle shot, or whether the thumbnail needs a different background treatment for the collection grid. That is still merchandising and design judgment.

What it does remove is the wasteful middle layer:

• exporting oversized files from Figma
• recompressing them one by one somewhere else
• guessing which version is approved
• discovering too late that the storefront asset budget got blown

When product image work is recurring, that middle layer is where a lot of time quietly disappears.

A quick launch checklist

Before the assets leave design, check these:

• Every image has a page role, not just a frame name.
• Critical details stay readable at the real storefront size.
• Format choices follow usage, not habit.
• Desktop and mobile variants are separated when the crop changes meaningfully.
• Filenames tell the uploader exactly where the asset belongs.
• The final files are light enough that the storefront is not paying for unnecessary megabytes.

If ecommerce launches keep turning into an export cleanup job, standardizing around TinyImage is a good place to start. The real improvement is not flashy. It is that product images stop becoming a recurring production risk every time the catalog or campaign calendar changes.

Read as Markdown · Related resource index · Site index for AI agents