DEV Community

Choco111
Choco111

Posted on

A Reviewable Data Model for Marketplace Product-Image Generation


An image generator can return a file. A marketplace production system has to preserve why that file exists, which product facts it represents, which listing role it serves, and whether a reviewer has actually checked it.

This is a frontend and QA design memo based on public workflow descriptions. It is not source-code inspection, private architecture documentation, or a hands-on product test.

Separate facts from presentation

The public Nextify pages describe two related but different workflows. The TikTok Shop Product Image Generator page describes reference photos, market/language/ratio settings, hero images, detail shots, lifestyle scenes, and shoppable-photo sequences. The Shopee Product Image Generator page describes a workspace for reusable assets, coordinated store visuals, banners, and option images for colors, sizes, bundles, and packs.

The model should not store all of that in a single prompt. Product facts need a stable source and confirmation state. Presentation decisions can vary by marketplace, placement, and campaign.

type ProductFact = {
  key: "name" | "color" | "material" | "dimensions" | "included" | "sellingPoint";
  value: string;
  source: "reference" | "merchant";
  confirmed: boolean;
};

type ImageRole = "hero" | "detail" | "lifestyle" | "banner" | "option" | "shoppable-sequence";

type ListingBrief = {
  marketplace: "tiktok-shop" | "shopee";
  market: string;
  language: string;
  ratio: "1:1" | "4:5" | "9:16" | "16:9";
  role: ImageRole;
  productFacts: ProductFact[];
  changedVariable: "background" | "lighting" | "copy" | "option" | "seasonal-style";
};
Enter fullscreen mode Exit fullscreen mode

The role matters because a banner and a hero image should not inherit the same text density or composition rules. The changedVariable matters because a generated sibling should be comparable to its parent.

Model options as data, not decoration

For a product with three colors and two pack sizes, do not rely on filenames or visual memory. Store an option record and the matching reference images:

type ProductOption = {
  optionId: string;
  labels: { color?: string; size?: string; bundle?: string; pack?: string };
  referenceAssetIds: string[];
  displayOrder: number;
};
Enter fullscreen mode Exit fullscreen mode

The generation request can then say “create an option image for blue / two-pack” instead of asking a model to infer which variation is intended. A reviewer can compare sibling options while keeping camera distance and subject scale stable.

Make revision and approval explicit

A useful state path is:

draft -> facts_reviewed -> configured -> generating
      -> generated -> reviewing -> approved -> downloaded
                         |             |
                         v             v
                       stale         rejected
Enter fullscreen mode Exit fullscreen mode

Changing a confirmed product fact should mark existing candidates as stale. Changing only a background may create a creative sibling. Changing the marketplace ratio should create a placement adaptation that requires a new crop review. These relationships are different and should be visible in the UI.

Do not infer approval from file existence. A generated image can still have a wrong label, an inaccurate product shape, an unreadable translation, or a promotional message that does not belong in the selected placement.

Define marketplace-specific checks

Check TikTok Shop example Shopee example
Recognition mobile hero and detail clarity thumbnail and catalog clarity
Context lifestyle or shoppable sequence store visual system or banner
Options product feature/detail emphasis color, size, bundle, or pack comparison
Localization market, language, ratio market, language, ratio
Review compare output with reference compare output with reference and option record

The table is a design aid, not a statement of marketplace policy. Actual channel requirements should be checked against current official guidance before publication.

Test failure paths, not only generation

  1. A required product fact is unconfirmed: generation remains blocked or visibly warns the reviewer.
  2. A reference photo is replaced: dependent candidates become stale.
  3. An option label changes: sibling images retain their previous revision and are rechecked.
  4. A ratio changes from square to vertical: composition and text safe area require review.
  5. A translated selling point changes: the source language, translation, and reviewer remain linked.
  6. A generated detail introduces an unsupported feature: the candidate cannot be approved without correction.

The real DOM selectors and API contracts belong in tests only after the target implementation is known. The reusable principle is to keep product truth, marketplace context, presentation choices, and approval state visible as separate data.

Conclusion

Marketplace image generation becomes easier to scale when the system remembers the job of each image. A hero shot, a detail image, a banner, a lifestyle frame, and an option comparison can share product facts without sharing the same composition. That separation gives teams speed without losing traceability.

Top comments (0)