When I changed my YouTube Shorts titles to name both games in the comparison, the view counts moved. Named-vs-named drove 162–373 views per video; unnamed variants died at 5. That data was enough to start making corresponding changes to the thumbnail design — the visual and the title need to work together or neither works well.
Here are the four rules I've now hardcoded in the thumbnail generation pipeline after running 19 game-comparison Shorts.
Rule 1: Lead with the big number, not the game title
The original thumbnail layout put the game names at the top — icons, titles, branding — and the statistical result at the bottom: "Has 5× more Steam reviews." This mimics review-site hierarchy: identify the subject first, then reveal the verdict.
For a 3-second impression on a Shorts feed, this ordering is backwards. The viewer doesn't know to care about the game until they see the result. They need a reason to stop scrolling before they'll register who the comparison involves.
PR #37 reversed the layout: the comparison number or result goes at the top in large type. Game names and icons move to the lower third. The implicit reading order is now "RESULT → explanation" rather than "subject → result."
I don't have A/B split data on this specific change yet — it shipped this week. But the title-naming data consistently showed specificity is the click trigger. The number is the most specific element on the thumbnail. It should be the first thing the viewer reads.
Rule 2: Wire the cover_image explicitly or the render breaks
The thumbnail generator takes a cover_image field from the YouTube script JSON. When I added the Hades II Short to the queue, I initially omitted the field assuming the generator would fall back to a sensible default.
It did not. It defaulted to a black frame. The ffmpeg overlay then rendered the text and game icons correctly onto a black background. The thumbnail was technically valid and looked completely wrong — indistinguishable from a placeholder.
PR #36 added two fixes: an SOP for how the background image is selected and sourced (platform-appropriate art, no UI chrome, no text overlap zones), and explicit wiring of cover_image in the Hades queue entry. The SOP was drafted in a code-review session and committed directly to the video generation runbook.
The rule: cover_image is not optional. If you're generating thumbnails programmatically, put a gate on the field before the thumbnail step runs. A missing image will silently produce a broken output, not an error.
Rule 3: Export at 16:9, not 9:16, for the preview card
YouTube Shorts play vertically at 9:16, so the obvious choice is to generate vertical thumbnails. The problem is where discovery actually happens.
Thumbnail preview cards in YouTube search results, the main feed, and embed contexts display horizontally. A 9:16 thumbnail that YouTube crops to a 16:9 preview card loses the top and bottom — which is exactly where I'd placed the game title and the result number. The center crop shows only the background art.
My current export is 1280×720 (16:9). YouTube scales it for the Shorts player by adding sidebars. The data in the preview card — where the viewer decides whether to click — is preserved in full.
This rule depends on where your Shorts discovery is actually happening. If most of your traffic comes from within the Shorts vertical feed (the swipe-up interface), 9:16 makes sense and my rule doesn't apply. At my follower count, feed cards are the dominant discovery surface, so the horizontal export wins.
Rule 4: Hardcode the layout constants, don't prompt for them
The pre-PR thumbnail generator had a prompt that described the desired layout: "put the number at the top in large type, game names below." The results were roughly correct but inconsistent across runs — font sizes drifted, number positions shifted, text occasionally clipped by an icon.
Prompting treats the layout as a creative decision the model makes fresh each time. For automation, that's the wrong model. I want identical layout across every thumbnail in a series, with only the game names and numbers changing.
After PR #37, the constraints are constants in the Python generation script, not prose in a prompt:
NUMBER_FONT_SIZE = 96
NUMBER_POSITION = (CENTER_X, TOP_MARGIN)
GAME_NAME_FONT_SIZE = 36
GAME_NAME_POSITION = (CENTER_X, LOWER_THIRD)
These aren't configurable parameters. They're invariants. The model doesn't pick them. The only inputs the generator accepts are game names, the comparison number, and the cover_image path.
The same logic applied earlier on the directive side: once a decision is settled, move it from a prose instruction into code. A prose instruction can be skimmed past or interpreted loosely. A constant cannot.
Part of an ongoing 6-month experiment running three AI-curated directory sites. The technical claims here are real; this article was AI-assisted.
Top comments (0)