Same Same But Different

same-same-but-different

Ten versions of the same thing, each one genuinely a different idea — not one idea wearing ten outfits.

That last clause is the whole skill. The natural failure, every time, is to build one design and then re-colour it N times; the person asking gets a gallery where every picture is the same picture, and they cannot tell you why it is wrong. This skill exists to prevent that.

The one law

Vary ONE axis. Freeze everything else — including the content.

A variant set is only readable if exactly one thing differs. Ten layouts in ten different colour schemes teach nothing, because no two can be compared. Ten layouts in the identical skin teach everything.

The three axes (visual work)

Non-visual work has the same three, renamed: structure (order and grouping of the parts), voice (register, vocabulary, rhythm), scale (length, density, level of detail).

Most people asking for "different versions" mean BONES and get shown SKIN. When the ask is ambiguous, default to BONES — it is the rarer, harder, and more useful answer.

Run it in five steps

1 — Write the inventory, out loud

Before generating anything, list every element that must appear in every variant. Show the list to the user in your reply. Example for a screen:

title · one-paragraph summary · three stats · six timed steps · one video · four files · a 28-item directory · search · a progress meter · five links · notes · previous / complete / next

The inventory is the contract. A variant that quietly drops the notes field or invents a new stat is not a variant — it is a different product, and it poisons the comparison. Content stays byte-identical across the set.

2 — Name the axis, once

State which axis you are varying and that the others are frozen. One sentence, in the reply, before the work:

"Ten layouts. Same content, same skin, same 18px frame — only the architecture changes."

If genuinely ambiguous and the user is available, ask exactly one question (bones / skin / both-in-sequence). Never ask more than one; never ask if the answer is inferable. If they are away, pick BONES, say so, and proceed.

3 — Choose N distinct positions

Pick the N positions before building anything, and write a one-line description of each. Then apply the discrimination test:

If one sentence describes two of your variants, one of them is wasted. Delete it and pick something further away.

For BONES, the fastest way to real distance is to name a familiar shape — a form the reader already has in their head — and build that:

• Single column — no rail at all; secondary tools become a strip on top or a dock at the bottom
• Sidebar navigator — navigation becomes a full-height rail (often dark), content gets the rest
• Media-first / player — one asset owns the top of the screen edge to edge; everything else is a row of columns beneath it
• Index-first — the thing that was a small widget (calendar, list, map, table of contents) becomes half the screen; the "main" content shares
• Bento — no columns at all; tiles on a grid, each sized by importance
• Board / kanban — parallel columns you scan across, one per category
• Metrics dashboard — numbers first, title demoted to a page header
• Timeline / stepper — one spine; every step carries its own material, and the "materials" section stops existing
• Three-pane (mail client) — icons, a scrollable list, the detail, and a side panel for one secondary job
• Focus mode — one thing at a time fills the screen, everything else collapses into a dock
• Split screen — two equal halves that stay in sync
• Overlay / modal-first — the page is a background, the work happens in a sheet
• Wizard — one question per screen with a progress rail
• Canvas / spatial — pannable surface, objects placed rather than stacked

For SKIN, the dimensions worth crossing: display face vs text face vs label/number face · weight and case of micro-labels · palette ground (paper / white / cool grey / dark / brand colour) · accent count (one, two, or a family) · border radius (0 → 16) · how surfaces are defined (fill, hairline, heavy border, shadow, nothing) · density. A kit is only a kit if it decides all of them; half-specified skins look like accidents.

For FRAME: inset from the window edge · corner radius of the whole surface · shadow depth · overall scale up/down a few percent · type scale up/down one notch · proportion between the panes · full-bleed vs capped width.

4 — Build cheaply, then verify

One generator, shared atoms, per-variant deltas. Write the content atoms once (in a small builder script, a template, or a component file) and have each variant import them and override only its own rules. Never hand-copy the whole thing N times — the copies drift and the comparison dies. For web work a ~200 line Python or Node script that writes N standalone HTML files is right; every file stays independently openable, and rebuilding all N after a fix takes seconds.

Do NOT spawn one agent per variant. N full-model subagents for N pictures is the classic waste — building them from one script is faster, cheaper, and keeps the content identical, which is the entire point.

Then look at them. Screenshot every variant at one fixed viewport (1440×900 is a good default for desktop work), assemble the shots into 2-up contact sheets, and review the sheets. You are looking for breakage, not taste: unreadable contrast, wrapped buttons, collapsed columns, an element that vanished. Fix and re-shoot before delivering. A broken variant does not just fail on its own — it makes the user distrust the whole set.

Python + Playwright is the low-friction path when it is available:

from playwright.sync_api import sync_playwright
with sync_playwright() as p:
    b = p.chromium.launch()
    pg = b.new_page(viewport={"width": 1440, "height": 900})
    for f in files:                      # local .html paths
        pg.goto(f.as_uri()); pg.wait_for_timeout(1000)
        pg.screenshot(path=f"shots/{f.stem}.png")
    b.close()

A browser automation MCP does the same job if you have one; so does any headless-Chrome CLI. If nothing can screenshot, say so and deliver the files plus a contact page — never claim you verified something you did not see.

5 — Deliver numbered, with one line each

• Number every variant, continuing from any earlier round. Numbers are how the conversation happens afterwards: "76 but with 81's rail". Never renumber.
• Give each variant a short name and exactly one line saying what changed. If you need a paragraph, the variant is not distinct enough.
• Build a gallery page — a plain HTML file with each screenshot, its number, its name, its line, and a link to the live file. Cheap, scannable, and it lets the user reply with numbers.
• Close by inviting the pick: "Tell me which numbers to keep, or mix them — bones from one, skin from another."

The two-number handoff

Once a set exists on more than one axis, the user's fastest possible answer is two numbers: "structure 108 with kit 86." Build the pairing immediately — it is a mechanical merge (take variant A's markup, append variant B's style block), and it is usually the moment the real design appears. Teach the user this phrasing explicitly the first time you deliver two axes.

Give the user the words

People often cannot articulate this ask — they say "different" and get skins, then feel unable to explain why it is wrong. That is a vocabulary gap, not their failure. Hand them the phrasebook, once, when the confusion shows:

• Bones: "Same content, completely different layout each time. Nothing in the same place twice. Freeze the style."
• Skin: "Same layout, different skin — fonts, colours, corners."
• Frame: "Same design, just change how much of the window it takes up."
• Fastest of all: "Show it as a mail client / a player page / a bento / a board / a dashboard / a timeline / a focus mode."
• Combining: "Structure 4 with the style of 9."

How many

Default 10. Below six the set stops feeling like a spread and starts feeling like a recommendation; above about twelve the user cannot hold them in their head. If the user names a number, use theirs. Deliver them all at once — a variant set is a comparison, and a comparison delivered in instalments is just iteration wearing a costume.

Failure modes, in order of how often they happen

1. Re-skinning instead of re-architecting. Ten files, one skeleton. Test: cover the colours — can you still tell them apart by the wireframe alone? If not, start over on BONES.
2. Drifting content. Variant 7 has an extra button, variant 3 lost the summary. Now nothing is comparable. Generate from shared atoms.
3. Two axes at once. New layout and new palette per variant — the user cannot tell which change they are reacting to.
4. Undelivered breakage. A variant with unreadable text or a wrapped button reads as carelessness across the whole set.
5. Variants that are settings, not ideas. 4px vs 6px radius is not a variant. If a change would not survive being described out loud, cut it.
6. Silent taste. Shipping a set with no notes forces the user to reverse- engineer your intent. One line each, always.
7. Burning the budget. One agent per variant, or one full rebuild per tweak. One generator; re-run it.

Recipes

Web page / app screen — inventory the blocks; ten BONES from the shape catalogue; one builder script emitting standalone HTML; screenshot at 1440×900; contact sheets; gallery page. Then optionally a second round on SKIN with the bones frozen.

Document / report — vary structure: executive-summary-first · narrative · Q&A · problem/solution pairs · timeline · one-pager + appendix · annotated table · memo · FAQ · slide-style spreads. Same words, re-arranged.

Slide deck — vary the unit: one idea per slide · build-up sequence · full- bleed image with a line · data-first · quote-driven · storyboard strip · comparison table · single-slide summary with layers.

Logo / mark — vary construction: wordmark · lettermark · pictorial · abstract mark · badge/seal · monoline · geometric · stacked lockup · horizontal lockup · negative-space. Freeze the palette so form is the variable.

Naming / copy lines — vary the mechanism, not the synonym: literal · metaphor · compound · verb phrase · borrowed word · invented word · initialism · sound-first · opposite · understatement.

Code / architecture — vary the shape: single module · layered · event- driven · pipeline · plugin registry · state machine · actor · data-first · functional core + imperative shell. Same behaviour and tests every time.

Built by @ideaLOCKIN · more at TakeonAI.com