An AI video interface can look like a short sequence: choose an actor, add text, click generate, download. A production workflow contains more objects than that sequence reveals. A script is a claim-bearing document. An actor may be a library selection or a likeness-backed custom asset. A generated clip is a candidate, not an approved advertisement.
This is an interface-design memo based on public product descriptions, not source-code inspection, a hands-on test, or a statement about a particular system's architecture.
Begin with typed inputs
The public Nextify pages describe workflows around AI avatars, text, voice controls, emotion, gestures, product demonstrations, and video preview. That is enough to define a useful domain model. The AI Influencer Video Generator page frames an influencer-style route with selected or photo-based avatars, while the AI Commercial Actor page frames an actor route with prompts or references, actions, and product-in-hand presentation.
Do not reduce those routes to an unstructured prompt string. Capture responsibility boundaries in data:
type Actor =
| { source: "library"; actorId: string }
| { source: "custom"; assetId: string; likenessPermissionId: string };
type CreativeBrief = {
productFacts: string[];
approvedScript: string;
placement: "vertical" | "square" | "landscape";
changedVariable: "hook" | "actor" | "delivery" | "scene" | "product-proof";
};
type VideoCandidate = {
id: string;
actor: Actor;
briefRevision: number;
status: "generated" | "reviewing" | "approved" | "rejected";
reviewNotes: string[];
};
The point is not that every application needs these exact names. The point is that assetId and likenessPermissionId should not vanish once a custom actor is selected, and that a candidate should retain the brief revision that produced it.
Make stale output visible
Suppose a reviewer corrects an unsupported product statement after three videos exist. If the interface treats the script as a mutable field without revision history, those candidates become ambiguous. Were they made before or after the correction?
Model the transition explicitly:
brief_draft -> facts_checked -> ready_to_generate -> generating
generating -> generated -> reviewing -> approved -> exported
reviewing -> brief_revised -> stale
reviewing -> rejected -> ready_to_generate
exported should not be the automatic successor of generated. A rendered file only proves that a file exists. It does not establish that the product looks right, that the script is supportable, or that the actor asset may be used for the intended placement.
Represent review as named checks
One generic approve button loses useful information. A review record should make checks independently visible:
type Review = {
productIdentity: "pass" | "fail" | "unreviewed";
scriptAndClaims: "pass" | "fail" | "unreviewed";
actorRights: "pass" | "fail" | "unreviewed";
speechAndCaptions: "pass" | "fail" | "unreviewed";
productInteraction: "pass" | "fail" | "unreviewed";
placementCrop: "pass" | "fail" | "unreviewed";
};
Product interaction deserves its own check when a workflow includes a product-in-hand scene. A polished frame can still show a distorted package, unclear contact, or a misleading relationship between the person and product. Keep that concern separate from general image quality so it is not silently waived.
Test the decision boundaries
Workflow tests should exercise what becomes invalid, not only whether a Generate button appears.
| Scenario | Expected result |
|---|---|
| Custom actor has no permission record | Generation is blocked with an actionable reason |
| Product fact changes | Existing candidates retain their old revision and become stale |
| One hook changes | Candidate relationship identifies the changed variable |
| Render succeeds | Candidate enters reviewing, not approved
|
| Crop changes for a placement | A new placement review is required |
| A reviewer fails captions | Export remains unavailable until resolution |
Avoid pretending an illustrative type model supplies real selectors or API contracts. Use the actual implementation to add those details. The design goal is narrower: make the system show what it generated, what a human checked, and why a candidate may not yet be used.
Keep creative speed and approval distinct
Avatar and actor tools can accelerate production of candidate directions. They cannot independently verify rights, claims, brand suitability, or channel policy. Treating those boundaries as first-class state is not bureaucracy; it prevents a fast creative loop from turning “generated” into an accidental synonym for “approved.”
Top comments (0)