An image-generation feature becomes difficult to operate when it stores only prompts and output URLs. An ecommerce listing needs more context: which real product was referenced, what role an image serves, which facts were confirmed, what changed between variants, and whether anyone has reviewed the output against the item being sold.
This is an interface and QA design memo grounded in public workflow descriptions, not source-code inspection or a statement about any private implementation.
Separate product facts from gallery roles
The public Nextify pages describe related workflows with different emphases. Shopify Product Image Generator describes an image series containing main views, feature graphics, collages, use scenes, and supporting angles. Temu Product Image Generator describes main images, close-ups, relevant scenes, and using up to three reference photos of the same item.
Do not encode those differences in a single free-form prompt. Store product evidence separately from a gallery role:
type ProductReference = {
assetId: string;
view: "front" | "back" | "side" | "detail" | "packaging";
authorized: boolean;
};
type ProductFact = {
key: "name" | "material" | "color" | "dimensions" | "included" | "sellingPoint";
value: string;
confirmed: boolean;
};
type GalleryRole = "main" | "feature" | "multi-angle" | "detail" | "use-scene" | "supporting";
An image can then be assessed by the job it is meant to do. A main image should not be approved by banner criteria, and a close-up should not be expected to explain the entire product.
Preserve the generation request
The generation record should hold the visual direction and revision that produced a candidate:
type GalleryCandidate = {
id: string;
marketplace: "shopify" | "temu";
role: GalleryRole;
referenceIds: string[];
factsRevision: number;
ratio: string;
changedVariable: "background" | "lighting" | "composition" | "copy" | "scene";
status: "generated" | "reviewing" | "approved" | "rejected" | "stale";
};
If a merchant changes the package quantity or corrects a material, candidates generated under the old facts should become stale; they should not silently masquerade as current. If a team only changes the background, the UI can display the result as a sibling rather than an unrelated file.
Make approval granular
Generation is not approval. A reviewer needs independent checks for product identity, packaging text, colors, included parts, claim support, translated text, and role-specific framing.
type Review = {
identity: "pass" | "fail" | "unreviewed";
details: "pass" | "fail" | "unreviewed";
copy: "pass" | "fail" | "unreviewed";
sourceRights: "pass" | "fail" | "unreviewed";
placement: "pass" | "fail" | "unreviewed";
};
This is especially important for close-ups. A detail image can be visually convincing while adding a seam, fastener, button, or material pattern that the real item does not have. A review note should name the failed check instead of reducing the decision to a thumbs-down.
Test state transitions rather than just components
| Scenario | Expected behavior |
|---|---|
| A source photo is replaced | dependent candidates become stale |
| A reference lacks authorization | generation is blocked or visibly warned |
| A product fact changes | prior image revision remains traceable |
| Ratio changes | a placement review is required |
| A main image is reassigned as detail | role-specific checks refresh |
| Generated text is altered | copy review becomes unreviewed |
Actual selectors and API contracts should come from the implementation, not an illustrative article. The reusable decision is simpler: retain evidence, preserve the image role, and require a human record before an output is treated as listing-ready.
Conclusion
A gallery is a small information system. Main views, feature proof, use scenes, and details may share the same product facts while answering different shopper questions. A model that makes those distinctions explicit lets a team generate faster without losing the ability to explain what was created and why it was approved.
Top comments (0)