Modeling Two Thumbnail Briefs Without Mixing Creative Intent

The problem is not the prompt field

A thumbnail editor can expose one upload button, one prompt, and a row of style chips. The surface looks simple, but two requests with similar wording may need completely different state. “Make it intense” for a Roblox meme video can mean saturated color and exaggerated scale. For a 3 a.m. investigation it can mean darkness, one clue, and restrained text.

If the UI stores both requests as one string, later steps cannot tell whether a red arrow is part of the story or decoration. The result may be polished while losing intent.

The public Steal A Brainrot Thumbnail and 3AM Clickbait Thumbnail experiences suggest a useful boundary: templates establish a visual direction, while the creator describes the actual scene.

Give the brief explicit dimensions

The model above keeps mood, subject, action, proof, emotion, and aspect ratio visible. proof is the detail that makes the promise believable: a game item, a door, a timestamp, or a frame from the video. It gives the reviewer something more concrete than “make it viral.”

A mood field is a constraint, not a prompt replacement. A brainrot preset may suggest high saturation and oversized type; a late-night preset may suggest a dark base and one highlighted clue. The user can still change both.

Keep source, concept, and treatment separate

An uploaded image can supply composition. A YouTube URL can supply context. The brief explains the moment to emphasize. Treatment records effects such as an arrow, glow, night-vision texture, or face adjustment so reviewers can see what changed.

This separation also improves error handling. If an upload exceeds the accepted format or size, show the error beside the file while preserving the subject, text, and selected mood. If a URL is malformed, do not erase the prepared brief. A retry should recover the same creative intent.

type Mood = "brainrot" | "lateNight";
type Brief = {
  mood: Mood;
  subject: string;
  action: string;
  proof: string;
  emotion: "curious" | "shocked" | "hyped" | "uneasy";
  aspect: "16:9" | "9:16";
};

Review the promise, not just the pixels

Ask four questions: Is the subject identifiable at feed size? Does the text add information? Is the highlighted clue present in the video? Would the opening seconds support the emotion shown? For brainrot, test whether overload still contains one readable joke. For late-night suspense, test whether darkness leaves a focal point.

When the creator moves from a video idea into original design work, Thumbs.ai is the broader workspace context. The implementation lesson is portable: model the source, brief, and treatment as separate objects, then make each transition reviewable.

Make the review state observable

The review object should preserve enough context to answer “why is this candidate here?” A useful record includes the source kind, brief revision, selected mood, aspect ratio, treatments, and a stable candidate ID. It does not need to expose private model details. It needs to make a user-facing comparison possible.

For example, keep the source and brief immutable while generating a variation set. If the variation axis is emotion, hold subject, proof, and text constant. If the axis is aspect ratio, compare safe-area behavior without changing the focal object. The UI can then label the difference honestly instead of presenting a row of unexplained alternatives.

Cancellation is another seam worth testing. When a creator changes the brief, abort the old request or ignore its response. Otherwise an earlier, slower result can replace the current candidate and make a correct input look wrong. The same rule applies to navigation, retry, and switching between template families.

These details are small, but they reduce support questions. A creator can see which source was used, what the prompt meant, what changed, and which step can be retried. That is a more durable abstraction than a single “generate” button with a pile of hidden assumptions.

Contract-level tests

Test the seams that users notice: an invalid file should preserve the prepared brief; a cancelled request should not publish a late candidate; a changed aspect ratio should keep the focal subject; and a batch of candidates should identify the exact treatment that changed. These are UI contracts, not claims about a private generation model. They can be tested with mocked responses and a small set of fixtures.

Keep the error copy actionable. A message such as unsupported format should say what can be uploaded, while an unavailable source should suggest choosing another reference. Separating these states makes logs easier to read and gives the editor a clear next step. A visible retry action should return to the last valid state instead of opening an empty form.