Designing an AI Poster Generator as a Reviewable State Machine

An image generator can return a file. A production tool has to preserve intent while the user moves from product data to a reviewable ad.

This article is an interface-level design exercise. It is based on public workflow descriptions, not source code, private architecture, benchmark results, or a hands-on product test. The goal is to define a reusable frontend contract for any system that turns a product reference into advertisement poster variants.

Start with the objects, not the screens

A three-screen flow—upload, configure, result—looks simple until each screen hides several different objects. The upload is not merely a file; it is a product reference plus extracted claims that may be wrong. The configuration is not merely a style picker; it is a creative brief with channel constraints. The result is not merely an image; it is a variant that needs review status and provenance.

A useful minimum model might look like this:

type ProductFact = {
  id: string;
  label: string;
  value: string;
  source: "extracted" | "user";
  confirmed: boolean;
};

type PosterBrief = {
  audience: string;
  primaryClaim: string;
  supportingFactIds: string[];
  style: string;
  aspectRatio: "1:1" | "4:5" | "9:16" | string;
};

type PosterVariant = {
  id: string;
  briefRevision: number;
  assetUrl: string;
  status: "generated" | "needs-review" | "approved" | "rejected";
  reviewNotes: string[];
};

The important field is briefRevision. If a user corrects a selling point after generating three images, the UI should make stale variants distinguishable from variants made with the corrected facts.

Model extraction as a proposal

The public page for Advertisement Poster AI describes uploading a product image, automatically extracting product category, selling points, and target audience, and allowing those details to be edited before generation. That edit step should be treated as a confirmation boundary.

An extraction result is not truth. It is a proposal with a source and a review state. The interface should answer:

• Which values came from automation?
• Which values did the user change?
• Has the primary claim been confirmed?
• What happens to existing variants after a fact changes?
• Can the user return to the reference without losing the brief?

Avoid a single “Looks good” button if different facts have different risk. A wrong product category, a slightly broad audience, and an unsupported performance claim should not be visually equivalent.

Make generation states explicit

The apparent happy path is short:

empty -> reference_ready -> facts_reviewed -> brief_ready
      -> generating -> variants_ready -> approved -> exported

Real use adds branches:

generating -> failed -> retrying
variants_ready -> brief_edited -> stale_variants
variants_ready -> rejected -> regenerating
approved -> resized -> resize_review

Representing these states prevents ambiguous controls. “Generate” should not remain active when required facts are unconfirmed. “Download” should not silently imply approval. “Regenerate” should say whether it keeps the same brief or creates a new revision.

The wider Nextify product family includes multiple ad-creation workflows. A consistent state vocabulary across tools would help users recognize the difference between creating, reviewing, and exporting, even when the media type changes.

Separate creative variation from channel adaptation

Two operations often share one button but have different meanings:

1. Creative variation changes the visual hypothesis: scene, hierarchy, message, or style.
2. Channel adaptation changes dimensions and may recompose the same hypothesis for a placement.

If these are mixed, users cannot tell whether a vertical output is a crop, a re-layout, or a new concept. Store the relationship explicitly:

type VariantRelationship =
  | { kind: "creative-sibling"; parentId: string }
  | { kind: "channel-adaptation"; parentId: string; placement: string };

The UI can then group one creative direction across feed, story, and display placements while keeping a different direction in a separate group.

Define review as data

A production-ready review panel needs more than thumbs up or down. At minimum, give reviewers named checks:

• product identity and proportions;
• headline spelling and required copy;
• claim supported by confirmed input;
• logo and brand-color treatment;
• focal hierarchy at thumbnail size;
• safe-area and crop behavior;
• contextual details such as hands, apparel, or jewelry;
• destination-specific policy or legal review.

The system does not need to automate every check. It needs to make unresolved checks visible. A generated asset can be visually complete while still being operationally incomplete.

A compact review record could be:

type ReviewCheck = {
  key: string;
  result: "pass" | "fail" | "not-reviewed" | "not-applicable";
  note?: string;
  reviewer?: string;
};

Test the transitions, not only the components

Component tests will confirm that an upload button or ratio selector renders. Workflow tests should confirm that state changes preserve or invalidate the right data.

Useful cases include:

Scenario	Expected behavior
Replace the reference image	extracted facts return to unconfirmed
Edit the primary claim	previous variants are marked stale
Change only aspect ratio	original creative direction remains linked
Generation fails	brief and confirmed facts remain intact
Approve one variant	sibling variants remain independently reviewable
Export without completed checks	UI presents unresolved review status

Use selectors and API contracts from the real implementation when automating these tests. Guessed DOM selectors or timing values would turn an illustrative test into false confidence.

Keep the product boundary visible

Poster generation can accelerate exploration and packaging. It does not prove that a claim is legal, that a design will perform, or that an output is correct in every placement. The interface should avoid collapsing “generated,” “approved,” and “effective” into one status.

The best state model makes that boundary ordinary. Users should be able to see what the system proposed, what they confirmed, what changed, and what still needs review. That traceability is what turns an impressive generation demo into a dependable creative workflow.