DEV Community: Zhe

Designing an LLM Leaderboard That Can Survive Change

Zhe — Wed, 09 Sep 2026 07:16:28 +0000

Designing an LLM Leaderboard That Can Survive Change

An LLM comparison page is easy to sketch and hard to keep honest. The first version usually has a table, a score column, and a sort button. The second version has multiple model families, benchmark updates, pricing changes, provider outages, and users asking why two “top” models disagree.

This is an interface-level design memo, not a description of private implementation. The goal is to make the data contract visible enough that a product team can discuss it, test it, and revise it.

Start with a signal taxonomy

The first design decision is not the color of the score badge. It is deciding which signals belong together and which must remain separate.

The public LLMBoard AI homepage is a useful reference point because it exposes separate paths for overall capability, coding, reasoning, math, knowledge, instruction following, pricing, speed, provider reliability, and benchmark detail. That separation suggests a simple taxonomy:

capability signals describe what a model did on a defined task family;
deployment signals describe cost, latency, availability, and operating constraints;
evidence signals describe the benchmark, date, coverage, and measurement scope;
catalog metadata describes the model identity, provider, modality, and status.

If these are collapsed into one score too early, the interface becomes persuasive but difficult to audit.

Model a row as a record, not a number

A leaderboard row needs more than the fields model_name and score. A useful conceptual record might include:

stable model identifier;
provider and model family;
evaluation category and benchmark name;
score and metric unit;
evaluation date and freshness status;
price basis and currency, when price is shown;
runtime measurement scope, when speed is shown;
source or methodology reference;
confidence or comparability note.

This matters when a provider renames a model, a benchmark changes version, or a price is quoted per million tokens in one place and per request in another. The UI should not make two records look identical when the measurement contracts differ.

Make the comparison state explicit

Users should be able to answer: “What exactly am I looking at?” A compact state summary near the table can show the selected modality, task category, benchmark, date range, price basis, and sort field.

The phrase LLM Leaderboard is often treated as if it names one universal table. In product design, it is better treated as a family of views sharing a model catalog. The selected view should be part of the URL or a restorable filter state so a reader can share the same comparison with a teammate.

Design for disagreement between views

The most informative user moment is often not when one model wins every table. It is when the leader changes by task, price, or speed. Instead of hiding that disagreement, make it readable.

Useful interface patterns include:

a comparison drawer that keeps the selected models while the user changes the benchmark;
a “why this row?” panel showing the metric, date, and source;
a freshness badge that distinguishes current, aging, and unavailable data;
a separate deployment view so price and latency do not masquerade as capability;
a clear empty state when models cannot be compared under the same conditions.

Test the failure states first

The happy path is a sorted table. The product quality appears in the awkward cases:

a benchmark has no score for a model;
two records use different versions of the same benchmark;
the provider changes a model ID;
an official price is missing or has a different unit;
a runtime number was measured under a different context length;
a user opens a shared link after the dataset has changed.

For each case, write the expected user-visible behavior before writing UI copy. “Not available” is different from zero. “Not comparable” is different from a low rank. “Last updated” is not the same as “verified today.”

A small review contract

Before shipping a new ranking view, ask four questions:

Can a reader identify the task and metric without opening documentation?
Can a reviewer find the measurement date and source?
Can a model be removed or renamed without changing historical meaning?
Can the team explain what the score does not measure?

If the answer to any question is no, the interface needs more context, not a brighter badge.

One final engineering habit helps: keep the raw measurement and the editorial presentation separate. A card may show a rounded score for scanning, while the detail view preserves the original unit, source, and timestamp. That makes a redesign less likely to rewrite the meaning of an old result.

Closing thought

An LLM leaderboard is a data product. Its credibility comes from the boundaries around each number: what was measured, when, under which conditions, and how the result should be used. Design those boundaries as carefully as the ranking itself, and the page can remain useful even as models and benchmarks keep moving.

A Ranking Page Is a Decision Interface, Not a Database

Zhe — Fri, 04 Sep 2026 02:40:51 +0000

A Ranking Page Is a Decision Interface, Not a Database

An AI-tool directory can be implemented as a collection of cards. A useful one behaves more like a decision interface.

That distinction changes the data model, the UI states, and the tests. A card that says “best” without an audience, task, date, or limitation is not a recommendation; it is an unscoped label. The engineering problem is to help a reader move from a broad query to a defensible shortlist without hiding uncertainty behind a score.

This is an interface-level design memo. It uses public page behavior and common directory requirements as a starting point; it does not claim access to any private codebase or internal ranking pipeline.

Define the unit of comparison

The first mistake is treating a tool as the only entity. A directory actually compares a tool in a context:

type ToolCandidate = {
  id: string;
  name: string;
  category: string;
  bestFor: string;
  workflow: string;
  strengths: string[];
  limitations: string[];
  pricingSignal?: string;
  lastChecked?: string;
};

bestFor and workflow are not decorative copy. They prevent a broad platform from being compared as if it were a narrow utility. limitationskeeps the page useful after the first click. lastCheckedgives the publisher a reason to revisit a volatile claim.

Separate ranking from filtering

Readers arrive with different intents. One wants an image workflow; another wants a research assistant; a third wants a tool that fits a small budget. A single global order creates false precision.

Use two layers:

Filtering: reduce the catalog by category, audience, task, access, or integration.
Ranking: order the remaining candidates using an explained editorial method.

This lets the interface say, “Here are strong options for your job,” rather than implying that number four is universally worse than number one.

The public category pages on Best10.ai illustrate the editorial pattern: products are grouped into practical categories and discussed through workflow fit, intended audience, capability notes, pricing signals, and limitations. Those fields give a frontend more meaningful states than a score badge alone.

Make the comparison contract explicit

The page should answer four questions before the reader opens a vendor site:

What job is this candidate meant to support?
Who is likely to benefit from that fit?
What should be checked before committing?
When was the volatile information last reviewed?

That contract can be represented as a view model:

type ComparisonRow = {
  candidate: ToolCandidate;
  matchReasons: string[];
  checkBeforeChoosing: string[];
  confidence: "editorial" | "user-reported" | "unknown";
};

The confidence field is intentionally modest. It distinguishes a publisher’s editorial synthesis from a verified external fact or an unknown that needs checking. Do not turn it into a percentage unless there is a reproducible method behind the number.

Use search intent as an input state

The phrase best AI tools is not one intent. A search box, category route, or article should preserve the qualifier that made the query useful: for students, for coding, for presentations, for free access, or for a particular workflow.

If a user removes the qualifier, show a prompt to add one instead of silently presenting an arbitrary universal ranking. A good empty state can ask:

What are you trying to finish, and what constraint matters most?

Possible choices include output type, experience level, budget, collaboration, privacy, and export needs. These inputs do not have to become a complex recommender. Even a static category link is better than pretending the system knows the user’s priority.

Test the states users actually encounter

Completed cards are the easy screenshot. The harder states are the ones that protect trust:

a category has too few current entries;
a pricing signal is missing or stale;
a vendor link returns an error;
a tool changes category after an update;
a limitation is longer than the headline benefit;
two candidates share the same name;
a user filters to a group with no result;
an editorial note has an unknown confidence level.

The UI should fail locally. A broken vendor link should not make the whole comparison page unusable. A missing price should read “check vendor pricing,” not a guessed zero. A stale review should be queued for review rather than quietly presented as current.

Keep promotional pressure out of the schema

A directory becomes harder to trust when sponsored placement and editorial order are indistinguishable. If commercial relationships exist, represent them explicitly in data and display. Do not let payment silently mutate the meaning of “best.”

Likewise, avoid a conversion event that requires the reader to accept a ranking before seeing the caveat. The page can offer a vendor link, but the decision should remain inspectable.

A small QA checklist

For each category page, verify:

Every ranking has a stated audience or job.
Each card contains at least one limitation or a clear unknown.
Volatile claims have a review date or a recheck instruction.
Filters preserve the user’s context when the URL changes.
Empty, stale, and broken-link states are readable on mobile.
Screen readers receive the candidate name before its score or badge.
A score never claims external verification unless a separate verification process exists.

The engineering goal is not to expose every internal editorial decision. It is to expose enough context that a reader can make the next decision responsibly.

Why this model ages better

Tool catalogs change. A context-rich record can survive a feature rename because the underlying question—what job, for whom, with what trade-off—remains stable. A score-only record becomes misleading as soon as the market shifts.

Build the page as a map of decisions, not a warehouse of names. The result will be more useful to readers and easier for the content team to maintain.

Designing an AI YouTube Thumbnail Workflow That Keeps Its Context

Zhe — Wed, 02 Sep 2026 09:56:31 +0000

A video-thumbnail interface can look like one upload button and one prompt field. The product behavior behind those controls is a sequence of contracts: an image is accepted, a concept is interpreted, a style is selected, candidates are generated, and a creator decides whether the result represents the video.

This memo is based on a public interface and general engineering patterns. It does not describe a private API, model, or production implementation.

Separate the source from the brief

An uploaded frame is evidence. A prompt is intent. A style is a visual constraint. Keep them separate so the user can correct one without losing the others.

type Source =
  | { kind: "image"; fileName: string; mime: string; bytes: number }
  | { kind: "youtubeLink"; url: string }
  | { kind: "concept"; text: string };

type ThumbnailBrief = {
  audience: "gaming" | "podcast" | "tutorial" | "vlog" | "other";
  subject: string;
  action: string;
  proof: string;
  style?: string;
  emotion?: "calm" | "curious" | "shocked" | "hype";
  shortText?: string;
  aspect: "16:9" | "9:16";
  mustAvoid: string[];
};

The public AI YouTube Thumbnail Maker page visibly supports an image upload or YouTube-link start, a written prompt, style selection, emotional cues, multiple variations, and 16:9 or 9:16 layouts. It lists PNG, JPG, JPEG, and WebP uploads up to 4 MB. These are useful observed inputs; they do not reveal the internal generation pipeline.

Validate inputs without erasing intent

A file validator should return a row-level error for unsupported format or size. It should not clear the subject, action, or text that a creator has already written.

type InputState =
  | { value: "empty" }
  | { value: "validating"; source: Source; brief: Partial<ThumbnailBrief> }
  | { value: "invalid"; source?: Source; brief: Partial<ThumbnailBrief>; reason: string }
  | { value: "ready"; source: Source; brief: ThumbnailBrief };

The distinction between source and brief also helps with YouTube links. A link may provide context for a video, while the creator’s brief specifies which moment to emphasize. Treating the URL itself as a complete creative instruction invites generic results.

Preserve provenance through every transformation

Store the source kind, upload name, prompt revision, style choice, emotion choice, aspect ratio, and candidate identifier. This is not a hidden model log; it is a user-readable change history. A creator should be able to answer “which frame led to this cover?” without opening an old browser tab.

When a candidate uses a generated face treatment, label it as an edit. When an image is upscaled, keep the original available for comparison. When a background is replaced, record that the new setting is creative direction rather than recorded evidence. These distinctions are especially helpful when an editor hands the asset to a client or another team.

The contract can also include a review deadline and an approval owner. That prevents an unreviewed candidate from being mistaken for the version ready to publish, even if its file name says final.

Keep batch work observable

Batch input changes the user’s expectations. If ten URLs are pasted, the interface should show ten rows, not one spinner followed by a mixed folder. Each row can expose the normalized video identity, the quality attempted, the preview state, and the next action. A partial result is useful when it is labeled; a silent omission is not.

Cancellation deserves a specific contract too. When a user starts a second request, the first request must not overwrite the current brief or candidate list. Attach a request identifier to every result and discard responses that are no longer current. This is a small implementation detail with a large effect on trust.

Finally, keep user-facing language precise. “Source unavailable,” “lower-resolution source found,” and “preview ready” each describe a different state. Avoid collapsing them into “success” merely to make the dashboard look cleaner.

Observability also applies to the creative brief itself. Show the normalized subject, event, and proof next to every candidate so a reviewer can see whether a variation changed the story or only the styling. If the prompt is revised, increment its version and keep the earlier candidate linked to the earlier text. That makes a disagreement concrete: the team can point to a prompt revision, a crop change, or an approval decision instead of arguing from memory.

For a production queue, emit structured events such as sourceAccepted, briefUpdated, candidateReady, candidateRejected, and exportCompleted. These events can feed a small activity panel without exposing model internals. They also make support conversations easier because a creator can report where the workflow stopped. A recoverable error should offer the next action—replace the file, edit the link, retry the candidate, or return to review—rather than a generic red banner.

Make variations comparable

“Generate more” is not a useful experiment unless the system records what changed.

type VariationSet = {
  axis: "crop" | "subjectScale" | "style" | "emotion" | "textTreatment";
  fixed: (keyof ThumbnailBrief)[];
  candidateIds: string[];
};

If the axis is emotion, keep the source, subject, and text stable. If the axis is aspect, compare 16:9 and 9:16 while preserving the focal subject and safe area. Candidate review then produces information instead of an unstructured preference.

Model review and export separately

A candidate can be visible without being approved. It can be approved without being downloaded. Use states that make the distinction explicit.

type ReviewState =
  | { value: "generating"; requestId: string }
  | { value: "reviewing"; candidates: string[]; selected?: string }
  | { value: "needsRevision"; reasons: string[] }
  | { value: "exporting"; candidateId: string }
  | { value: "exported"; candidateId: string; fileName: string };

The review screen should ask whether the subject appears in the video, whether the text adds information, whether the generated expression is clearly a design treatment, and whether the image is usable for the intended platform. UI safe zones are useful layout guidance, not proof that every platform crops content identically.

Test recovery paths

Illustrative tests should cover invalid files, cancelled requests, stale responses, empty prompts, and a candidate that fails the content check.

test("invalid image preserves the prepared brief", async ({ page }) => {
  await page.goto("/ai-youtube-thumbnail-maker");
  await page.getByLabel("Subject").fill("speaker holding the prototype");
  await page.getByLabel("Source image").setInputFiles("fixtures/too-large.png");
  await expect(page.getByRole("alert")).toBeVisible();
  await expect(page.getByLabel("Subject")).toHaveValue("speaker holding the prototype");
});

The labels are illustrative contracts, not verified selectors from the public page. Also test keyboard-only review, aspect-ratio switching, one candidate rejected while others remain, and export retry.

When a creator moves from a video brief into original design work, Thumbs.ai is the broader workspace context. The system should carry the permitted source and explicit brief while making generated edits distinguishable from source evidence.

The core engineering lesson is modest: a thumbnail pipeline becomes easier to trust when every creative choice has a visible state, a recoverable error, and a review question.

Designing a Recoverable GTA 5 Thumbnail Brief Instead of a Mega-Prompt

Zhe — Thu, 27 Aug 2026 01:59:12 +0000

Designing a Recoverable GTA 5 Thumbnail Brief Instead of a Mega-Prompt

“Make a cinematic GTA 5 police-chase thumbnail with my custom car” sounds like a useful request. It is a poor application contract. It mixes video type, source evidence, featured subject, location, mood, text, and constraints into one blob. If the result contains the wrong vehicle or invents an event, the UI has no precise way to preserve what was right and repair what was wrong.

This is a public-UI design exercise, not a description of any private API or implementation. The point is to turn a creative request into state that can be validated, resumed, compared, and reviewed.

Separate source evidence from the communication brief

The raw screenshot and the intended story answer different questions. Model both.

type Source =
  | { kind: "template"; templateId: string }
  | { kind: "gameplayImage"; file: File; capturedAt?: string }
  | { kind: "descriptionOnly" };

type Brief = {
  format: "roleplay" | "chase" | "race" | "carMeet" | "heist" | "guide" | "funny";
  subject: "character" | "vehicle" | "object";
  action: string;
  location?: string;
  proof: string;
  shortText?: string;
  mustPreserve: string[];
  mustAvoid: string[];
};

Source answers “what can this composition draw from?” Brief answers “what must the viewer understand?” The split lets a creator replace a blurry frame without losing the statement that the featured object is a black Sultan RS, the action is a bridge escape, and the event is fictional gameplay.

Make template switching explicit

The public GTA 5 thumbnail page offers scene directions for RP, live streams, casino heists, bank robberies, car meets, funny moments, story mode, police chases, racing, parkour, trolling, and 1v1 videos. It also visibly invites an uploaded image or concept and lists image-format limits.

Rather than treating these as decorative choices, a UI can give each template a contract.

type Template = {
  id: string;
  supports: Brief["format"][];
  requiredSlots: ("subject" | "pressure" | "proof")[];
  optionalSlots: ("text" | "route" | "opponent")[];
  safeTextAreas: { x: number; y: number; width: number; height: number }[];
};

Switching from chase to carMeet should preserve the source image and featured vehicle, but warn that a route constraint may no longer have meaning. Silent field loss is the kind of failure that makes creator tools feel unpredictable.

Generation has more than two states

isLoading is too small for an upload-and-review workflow. Model recovery deliberately.

type EditorState =
  | { value: "choosingSource" }
  | { value: "editingBrief"; source: Source }
  | { value: "validatingUpload"; brief: Brief }
  | { value: "generating"; requestId: string; brief: Brief }
  | { value: "reviewing"; candidateIds: string[]; brief: Brief }
  | { value: "recoverableError"; resumeAt: "source" | "brief" | "review"; message: string }
  | { value: "exportReady"; candidateId: string };

The visible page states that PNG, JPG, JPEG, and WebP uploads are accepted up to 4 MB. A rejected upload should return the user to source selection while retaining the written brief. A cancelled request must invalidate its requestId, so a late response cannot replace a newer set of candidates.

Review semantic accuracy before visual preference

File validation is deterministic. Whether the image truthfully packages the video requires a human confirmation step. Use structured review questions:

Is the character, car, or featured object actually in the footage?
Does the implied event match the episode, rather than a more dramatic hypothetical?
Does the map or location help identify the scene?
Is the short text a useful hook rather than a duplicate of the title?
Can the subject and action be named at a small preview size?

The answers are not a claim detector. They form a release checklist and create useful revision reasons.

type RejectionReason =
  | "wrong_vehicle"
  | "unclear_action"
  | "text_unreadable"
  | "misleading_event"
  | "identity_lost";

type CandidateSet = {
  variation: "crop" | "subjectScale" | "textTreatment" | "focalPoint";
  constantFields: (keyof Brief)[];
  candidateIds: string[];
};

Candidate sets should vary one dimension at a time. “Try again” becomes less useful than “keep the car, change the crop, and remove text.”

Test the boundaries, not only the happy path

test("invalid upload preserves a prepared brief", async ({ page }) => {
  await page.goto("/gaming-thumbnail");
  await page.getByLabel("Action").fill("escape the bridge roadblock");
  await page.getByLabel("Featured vehicle").fill("black Sultan RS");
  await page.getByLabel("Source image").setInputFiles("fixtures/too-large.png");
  await expect(page.getByRole("alert")).toBeVisible();
  await expect(page.getByLabel("Action")).toHaveValue("escape the bridge roadblock");
});

Also test stale requests, template switches, narrow review cards, keyboard flow, useful image alternatives, and duplicate export attempts. Do not make an assurance about clicks, reach, or performance part of the success condition.

Persist decisions without turning them into hidden prompts

Creative tools often save only the final image. That makes a future revision needlessly opaque. Save a small, inspectable record alongside the candidate: the selected source ID, template ID, normalized brief, variation axis, rejection reasons, and export timestamp. The record should contain user-visible constraints, not a secret model transcript that a creator cannot review.

type DecisionRecord = {
  sourceId?: string;
  templateId?: string;
  brief: Brief;
  selectedCandidateId: string;
  rejected: { candidateId: string; reasons: RejectionReason[] }[];
  chosenBecause: string;
};

This makes “reuse the last car-meet look” a legitimate product action. The UI can offer the previous text treatment and color system while asking the user to choose a new subject and proof detail. It can also prevent accidental reuse of an old screenshot by surfacing its capture time and source label.

Permission checks belong in this record as well. A boolean cannot establish ownership, but an explicit acknowledgement—“I may use this source image”—keeps the decision visible at the moment of export. The same review surface can remind a user that a fictional gameplay image should not be framed as real-world evidence.

Versioning matters when a creator returns after publishing. Exports should receive a new version rather than mutate an approved candidate. That makes it possible to compare a later crop or corrected text treatment with the original decision and to roll back without reconstructing the whole brief from scratch.

Keep the version label visible in the review grid, export filename, and decision record so collaboration never depends on memory alone.

Thumbs.ai is the wider creation context when a user leaves a game-specific template family. The important product behavior is continuity: preserve their permitted source and the brief, while removing only GTA-specific assumptions.

The design goal is not a longer prompt. It is a creator-controlled sequence of choices that survives errors, makes candidates comparable, and keeps the visual promise tied to the actual video.

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

Zhe — Tue, 25 Aug 2026 10:17:06 +0000

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[];
};

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:

Choose the structural reference.
Add the user-owned subject.
Describe the actual video premise.
Generate candidates.
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 };

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";

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.

Designing a Multi-Model Answer Grid Without Hiding Uncertainty

Zhe — Mon, 24 Aug 2026 09:59:53 +0000

A multi-model interface sounds simple: send one prompt, render several answers, and let the user compare them. The difficult part is not the columns. It is representing independent, asynchronous work without implying that agreement equals correctness.

This article sketches an interface contract for that problem. It is an illustrative design exercise based on public behavior, not a description of any private implementation.

Model each panel independently

If three providers receive a prompt, they will not finish together. One may stream immediately, one may pause, and one may fail. A single global loading boolean cannot represent those outcomes.

Start with a per-panel state:

type PanelStatus =
  | "queued"
  | "streaming"
  | "complete"
  | "error"
  | "cancelled";

type AnswerPanel = {
  panelId: string;
  modelLabel: string;
  status: PanelStatus;
  text: string;
  errorMessage?: string;
  startedAt?: number;
  completedAt?: number;
};

The collection can now contain two complete answers and one error without pretending that the entire request failed. The UI can preserve readable results while offering a retry only on the failed panel.

Keep prompt identity outside the panels

Comparison is meaningful only when the displayed answers belong to the same prompt version. Store the prompt as an immutable turn record and associate every panel with that turn.

type ComparisonTurn = {
  turnId: string;
  prompt: string;
  createdAt: number;
  panels: AnswerPanel[];
};

If the user edits the prompt, create a new turn. Do not silently replace the text above old responses. A tiny “edited” badge is not enough when the main purpose is comparison.

Design the grid for partial progress

The grid should answer four questions at a glance:

Which model is represented by this panel?
Is it still working?
Is the visible text complete?
What action is available next?

Skeleton loaders are poor once real tokens exist. Render the available text, retain a visible streaming indicator, and announce status changes to assistive technology without reading every token aloud. When a response completes, move focus only if the user initiated an action that requires it.

On narrow screens, columns become stacked cards. Preserve the shared prompt above them and keep model labels sticky or repeated. “Answer 1” and “Answer 2” are insufficient after cards move vertically.

Avoid a false consensus feature

It is tempting to count matching phrases or display “3/3 models agree.” That indicator can overstate what the system knows. Similar wording is not independent fact checking, and different wording is not necessarily substantive disagreement.

A safer comparison layer helps users inspect rather than declares a verdict. Possible features include:

manual highlighting of claims;
a user-created verification checklist;
per-answer copy controls that retain the model label;
a prompt for “What assumption differs across these answers?”;
a clear reminder to verify consequential claims with primary sources.

The public multi-model chat at Wikis AI demonstrates the core interaction: a shared prompt goes to selected models, responses stream independently in separate panels, and the reader can continue with a useful model. This public behavior is enough to motivate the state model above; it does not expose the service's internal architecture.

Separate discovery from focused follow-up

A broad question often needs orientation before conversation. A topic guide can provide the vocabulary, common distinctions, and paths for follow-up.

The public AI Wiki is presented as a collection of structured guides with source-answer comparison and follow-up options across AI topics. From a product-design perspective, that suggests two entry modes:

browse mode: select a topic and inspect organized perspectives;
question mode: send a specific prompt and compare live responses. Keep those modes connected but distinct. A guide is not merely a frozen chat, and a chat is not automatically a maintained reference page.

Make failure local and recoverable

Provider errors, timeouts, and cancellations should not erase successful answers. Give each panel its own recovery action and preserve the original turn.

function retryPanel(turn: ComparisonTurn, panelId: string) {
  return {
    ...turn,
    panels: turn.panels.map((panel) =>
      panel.panelId === panelId
        ? { ...panel, status: "queued", text: "", errorMessage: undefined }
        : panel
    ),
  };
}

In production, retry semantics also need an idempotency strategy, cancellation support, and protection against duplicated billing or duplicated events. Those responsibilities belong in the real service boundary, not in a copy-pasted client helper.

Test transitions, not screenshots alone

A visual snapshot of three completed panels misses the risky states. Test the timeline:

all panels queued;
one streaming while another completes;
one fails after emitting partial text;
user cancels one panel;
retry affects only its target;
prompt editing creates a new turn;
mobile stacking preserves labels and reading order;
keyboard navigation reaches every panel action;
status announcements are concise.

Also test the product language. “Compared” is accurate. “Verified” is not, unless a separate verification process actually occurred.

The best multi-model grid does not choose a winner by decoration. It keeps provenance, progress, failure, and uncertainty visible enough that a person can make the next decision deliberately.

Designing a Domain Lookup UI Around Evidence, Not a Green Badge

Zhe — Mon, 24 Aug 2026 06:17:12 +0000

A domain checker looks like a tiny frontend problem: one input, one button, one result. The public interface is simple because the uncertainty has been compressed, not because it has disappeared.

This article does not inspect private source code or architecture. It uses the visible behavior of a public lookup page to build a reusable design checklist for any asynchronous search UI.

Model the result as evidence with provenance

“Available” should not be a boolean floating without context. A useful result model records what answered, what it answered about, and how confident the interface may be.

At minimum, distinguish states such as idle, loading, available, registered, for-sale, needs-confirmation, and error. Preserve a source label for registry RDAP, public registration data, pricing source, or registrar checkout. If one extension fails, do not collapse the entire batch into a generic error.

The public Check Domain page describes registry-backed RDAP checks for supported extensions and separates availability, record, and cost information. That visible separation is a strong UI lesson: different evidence types deserve different components and different copy.

type LookupState =
  | { kind: "idle" }
  | { kind: "loading"; requestedAt: string }
  | { kind: "result"; status: "available" | "registered" | "for-sale" | "confirm"; source: string }
  | { kind: "error"; retryable: boolean; message: string };

This type is an illustrative design proposal, not a claim about the site’s implementation.

Render a batch as progressive, independent rows

A user may submit one label but request many extensions. Those lookups will not necessarily resolve at the same time. The page should keep completed rows stable while pending rows continue to load. Sorting must also be deliberate: dynamically moving results can make users click the wrong item.

For each row, expose:

the full candidate domain;
current lookup state;
evidence source or a plain-language explanation;
an action appropriate to that state;
a last-checked time when freshness matters.

Avoid using color as the only signal. “Available” and “registered” need visible text, and errors should explain whether retrying is reasonable. Keyboard focus must remain predictable when new rows arrive.

Input handling deserves its own contract. Decide whether the field accepts a bare label, a complete domain, uppercase characters, trailing dots, or internationalized names. Normalize for lookup without silently changing what the user typed, and show the normalized candidate before any external purchase action. An explicit submit action is easier to reason about when one search fans out across many registries.

Keep price data separate from registration state

An available domain is not necessarily the cheapest option. A discounted first year and a higher renewal are two values with different meanings. Put them in separately labeled fields rather than combining them into one ambiguous “from” price.

When building a domain name search, the product contract should specify currency, price freshness, promotional conditions, and what happens when a registrar has no comparable quote. A missing renewal price should render as unknown, not zero.

The final purchase happens outside the lookup interface. A clear boundary message—availability and price must be confirmed at registrar checkout—prevents the product from implying a reservation it cannot provide.

Test uncertainty, not only happy paths

The most valuable tests are rarely “typing example returns a green row.” Cover partial and changing states:

One extension resolves while several remain pending.
A registry times out and a retry later succeeds.
A result changes between lookup and checkout.
Registration price exists but renewal price is missing.
A registered domain returns redacted public data.
A complete domain is entered instead of a bare label.
Screen-reader output announces state changes without flooding the user.

Illustrative Playwright pseudocode could assert stable semantics rather than guessed production selectors:

test("keeps partial results understandable", async ({ page }) => {
  // Selectors and response fixtures must be adapted to the real application.
  await page.getByRole("textbox", { name: /domain/i }).fill("northstar");
  await page.getByRole("button", { name: /search/i }).click();
  await expect(page.getByText(/checking/i)).toBeVisible();
  await expect(page.getByText(/confirm at registrar checkout/i)).toBeVisible();
});

Make the boundary part of the product

Good uncertainty copy is not legal debris below the fold. It is a functional part of the result. Explain that registry data is time-sensitive, public records may be redacted, pricing can change, and a domain check is not trademark clearance.

The frontend’s job is not to make a complicated system look certain. It is to make each source, state, and next action understandable enough that a user can decide what to verify next.

That principle also improves observability. Track source-level failures without retaining unnecessary search history. Measure timeouts and unsupported extensions separately from negative results, because reliability work depends on knowing whether the registry, pricing source, network, or interface contract failed.

Designing a Meme Template Picker That Preserves Context

Zhe — Fri, 21 Aug 2026 10:33:49 +0000

A meme template picker has a difficult information-architecture problem: users recognize some formats by sight, others by name, and many only within a cultural context. A grid of images may look efficient while hiding meaning, age, source, and intended use.

This article is based on public interface text. It is not a source-code, private-API, or production-architecture review.

Treat a template as metadata plus slots

The public YouTube meme thumbnail page presents reaction formats, split comparisons, gaming memes, Shorts-oriented layouts, face inputs, text, emojis, and stylized effects. A frontend model should represent more than an image preview.

A template may need:

a name and accessible description;
supported aspect ratios;
face, screenshot, headline, or comparison slots;
a cultural-context note;
source or rights information when available;
compatibility with faceless or face-led workflows.

Search and filtering should use those properties rather than forcing users to understand every visual reference in advance.

Keep input types separate

A selfie upload, a gameplay screenshot, and a short headline have different validation and privacy implications. The interface should name what each asset will be used for, show upload progress, and preserve the brief when one input fails.

Face-related actions deserve clear consent and review states. The product should not imply that a face swap is accurate, endorsed, or safe simply because generation completed.

Model selection as a reversible decision

Thumbs.ai publicly describes creation, recreation, face-expression, style, and template tools. When a user changes templates, the UI needs a contract for compatible inputs. Does the uploaded face remain? Is the text remapped? Does a vertical layout crop the reference differently?

Useful states include browsing, editingBrief, uploading, generating, reviewing, recoverableError, and exporting. Preserve the chosen template, assets, and text across recoverable failures. If switching layouts will discard work, explain that before the transition.

Test interpretation, not only rendering

Automation can verify template selection, required fields, ratios, error recovery, and file export. It cannot decide whether a meme is understood by the audience or whether its context is appropriate.

Questions for human review include:

Does the visual reference support the video’s actual setup?
Is the punchline dependent on an outdated or harmful context?
Does the face or character still resemble the intended subject?
Are text, screenshots, and labels accurate?
Are source and usage rights sufficiently understood?

Avoid outcome language in the interface

Terms such as “viral” or “high CTR” describe hoped-for outcomes, not deterministic UI states. A successful export does not prove that a thumbnail will perform. Product copy, success messages, and analytics should keep that boundary clear.

Compact implementation checklist

Store template meaning and slots as structured metadata.
Make previews accessible without relying on image recognition.
Separate face, screenshot, text, and effect validation.
Preserve compatible inputs across template changes.
Support partial generation failures and retries.
Show aspect ratio and crop before export.
Keep cultural, legal, and editorial review outside binary automation.

The goal is not merely to help users find a familiar image. It is to help them understand what will be preserved, changed, and communicated when that image becomes part of their own video context.

Designing an AI UGC Ad Workflow: Five Interface Contracts to Make Explicit

Zhe — Wed, 19 Aug 2026 06:37:46 +0000

AI video tools are often described as if the interface has one job: collect a prompt and return a video. Creator-style advertising exposes why that model is too small. The user is actually coordinating a format, product evidence, presenter, script, voice, delivery, aspect ratio, and review decision.

This article is a black-box analysis of a public product page. It does not describe private source code, architecture, model behavior, or production metrics. The goal is to extract reusable interface contracts that a frontend or product team can test.

Contract 1: Format Selection Must Change the Required Inputs

A Talking Review, Product-in-Hand demonstration, Unboxing POV, and App Showcase are not cosmetic presets. Each implies different required evidence.

For example, an App Showcase needs readable screen content, while Product-in-Hand needs a product image or asset that can be placed inside the performance. If the interface presents every format as the same form with a new thumbnail, users will discover missing requirements late.

A useful UI should make three things visible when a format changes:

what assets are required;
what the default scene structure will emphasize;
what limitations or unsupported combinations apply.

The state transition should be explicit enough that a user can predict what the next screen will ask for.

Contract 2: Product Evidence Must Be Paired With Script Claims

The script editor and asset picker should not behave like unrelated panels. If a line promises “easy unboxing,” the workflow needs a place to connect that claim to packaging imagery or a demonstration beat.

The point is to make the contract discussable: a spoken benefit may need a visible counterpart, and the UI should help users notice when that counterpart is missing.

Contract 3: Presenter, Voice, and Delivery Are Separate Decisions

It is tempting to collapse “creator” into one selector. In practice, the presenter’s appearance, voice source, emotional direction, and gesture choices answer different questions.

Nextify.ai publicly positions itself as an AI creative production platform that works with product assets, scripts, avatar video, UGC creatives, and other marketing outputs. That broader context is useful because it frames the presenter as one component of a creative workflow, not the entire product.

For interface design, separate controls reduce accidental coupling. Changing the presenter should not silently reset the script. Changing the voice source should reveal any new validation requirements. Changing emotion or delivery should preserve a clear baseline so the user can compare versions.

Contract 4: Output Framing Needs an Early Preview

Aspect ratio is often placed at the end of a generator. That is too late for vertical social video. A 9:16 composition affects subject scale, caption width, product placement, and safe areas from the first scene.

A good workflow should expose the intended frame before generation and provide at least a lightweight composition preview. If preview fidelity is limited, label it as a guide rather than implying pixel-perfect correspondence.

The public ugc ads page describes a three-step flow: choose a creator-style setup, select or create a presenter and add the script or supported audio, then set an output such as 9:16 and generate. That sequence provides a useful starting model, but an implementation still needs to preserve state and explain dependencies across steps.

Contract 5: Review Is a Product State, Not an Afterthought

Generation completion should not equal campaign readiness. The interface needs a review state where the user can inspect:

whether the spoken line matches the visible product moment;
whether captions are readable;
whether the first seconds establish the intended hook;
whether product and presenter remain inside the safe frame;
whether the ad implies an unsupported testimonial or result.

That final check is especially important for creator-style formats. A generated presenter should not be framed as an independent customer who personally used the product unless the evidence supports that claim.

A Small Test Matrix

Before shipping a workflow like this, test transitions rather than only screens:

Change format after adding assets. Verify which inputs persist and which are invalidated.
Change presenter after editing delivery controls. Verify that the script remains intact and reset behavior is explained.
Switch from landscape to vertical. Verify captions, product placement, and preview safe areas.
Remove a product asset linked to a demonstration beat. Verify that the missing evidence is surfaced before generation.
Return from review to edit. Verify that the system preserves the selected concept instead of creating an accidental duplicate.

Closing Principle

The most useful AI creative interfaces do not hide complexity by pretending it does not exist. They organize complexity into decisions the user can understand, reverse, and review.

For UGC-style advertising, the core design problem is state coherence: keeping format, evidence, script, presenter, delivery, and frame aligned as the idea changes. Make those contracts explicit, and both the interface and the resulting brief become easier to trust.