Designing a Style-Preset Thumbnail Flow Without Building a Clone Button

typescript dev.to

Designing a Style-Preset Thumbnail Flow Without Building a Clone Button

“Make it look like this creator” sounds like a simple product requirement. In an interface, it is not. The request bundles several different jobs: identify a composition, preserve the user’s subject, infer an emotional direction, generate variations, and prevent the result from becoming a copy of someone else’s identity.

This post is a black-box UX exercise based on visible controls, not a description of any company’s private implementation. The goal is to design a flow that treats a creator-style preset as a structural starting point rather than a one-click clone button.

Model the inputs by responsibility

A reference image, a YouTube URL, a selfie, a template, and a text prompt should not collapse into one untyped payload. Each input has a different role and failure mode.

type Reference =
  | { kind: "upload"; file: File }
  | { kind: "youtube"; url: string }
  | { kind: "template"; templateId: string };

type Subject = {
  image: File;
  emotion: "surprised" | "excited" | "focused" | "custom";
};

type Brief = {
  premise: string;
  focalObject?: string;
  mustAvoid: string[];
};
Enter fullscreen mode Exit fullscreen mode

The separation makes the UI easier to explain. The reference supplies structure. The subject supplies the person who belongs in the thumbnail. The brief supplies the video-specific story. mustAvoid gives users a place to state boundaries such as “no logos,” “no copied face,” or “do not add money.”

Make the workflow visible

The public Mrbeast thumbnail page shows several template options, reference upload and YouTube-link routes, a selfie input, emotional directions, and generation of multiple versions. That suggests a useful staged flow:

  1. Choose the structural reference.
  2. Add the user-owned subject.
  3. Describe the actual video premise.
  4. Generate candidates.
  5. Review for clarity and originality.

Do not hide all five stages behind one empty text box. Progressive disclosure reduces uncertainty, and each stage can display a specific recovery action.

type EditorState =
  | { value: "choosingReference" }
  | { value: "addingSubject"; reference: Reference }
  | { value: "writingBrief"; reference: Reference; subject: Subject }
  | { value: "generating"; requestId: string }
  | { value: "reviewing"; candidates: Candidate[] }
  | { value: "recoverableError"; code: ErrorCode; retryFrom: Step };
Enter fullscreen mode Exit fullscreen mode

This is why raw TypeScript should stay inside fenced blocks on DEV.to. Without the fence, the browser can interpret angle brackets or collapse indentation, turning a useful model into broken prose.

Validate references without pretending they are permissions

An uploaded image should be validated for type and size before submission. A URL should be parsed with the platform’s URL API, not split with a fragile string expression. But technical acceptance is not legal or ethical permission.

Add plain-language copy beside the reference field: “Use images you own or are allowed to reference. The reference guides composition; it does not grant rights to names, faces, logos, or artwork.” This is more useful than burying the boundary in terms no one sees during creation.

For creator-named presets, state that no affiliation is implied. The generated output should be reviewed for accidental likenesses and protected branding, especially when the reference contains a famous face.

Keep errors attached to the failed step

Avoid a single error state. Users need different actions for an unsupported file, an unreachable URL, an empty brief, and a generation timeout.

type ErrorCode =
  | "unsupported_file"
  | "file_too_large"
  | "invalid_reference_url"
  | "brief_too_vague"
  | "generation_timeout"
  | "candidate_unavailable";
Enter fullscreen mode Exit fullscreen mode

An unsupported file should return the user to upload. A vague brief should preserve the reference and subject while highlighting the premise field. A timeout should offer retry without duplicating the request. Store a client request ID and ignore late responses after the user begins a new generation.

Review candidates against a rubric

Four visually different outputs are not necessarily four useful alternatives. Present each candidate with the same review questions:

  • Is the focal subject recognizable at mobile size?
  • Does the image express the real premise of the video?
  • Does text add information instead of repeating the title?
  • Are important elements away from vulnerable edges?
  • Does the design contain the user’s own identity?
  • Does it accidentally reproduce a real person, logo, or distinctive artwork?

Allow rejection reasons. “Face changed,” “wrong object,” and “too similar to reference” can guide a targeted revision. The product should never imply that a preset guarantees clicks or virality; performance depends on the video, audience, packaging, distribution, and many other factors.

Export only after the boundary check

Before export, show a compact confirmation: the user owns or can use uploaded assets; names and logos have been reviewed; the thumbnail represents the video accurately; and the candidate has been checked at small size. This is not a substitute for policy enforcement, but it puts the decision at the moment it matters.

If the user wants to move beyond one named preset, Thumbs.ai provides the wider creation context. In product architecture, keep the generic workspace distinct from a creator-style entry page so the user can graduate from reference-driven exploration into a reusable channel system.

Test transitions, not screenshots

The highest-value tests exercise state recovery. Upload a valid selfie, fail the reference URL, fix it, and confirm the selfie remains. Start generation, cancel, and verify that a late response cannot replace the current state. Reject a candidate for similarity, revise the brief, and confirm the rejection reason is carried forward.

A style preset is useful when it teaches structure and accelerates exploration. It becomes risky when the interface treats identity as a filter. Explicit input roles, recoverable state, visible originality checks, and honest performance language keep the workflow on the productive side of that line.

Source: dev.to

arrow_back Back to Tutorials