Prototype Variants

Exploring Several Directions At Once

Take one described piece of UI — a toast, the pricing card, a hold-to-delete button — build several genuinely different answers to it, and put them behind a picker the user can flip through live. The entire value is divergence. Three tints of the same idea waste the picker: the user learns nothing by flipping between them, and you have spent a build to discover something a sentence would have told you. Default to 3 variants, each one a direction you could defend shipping on its own. Then present them and stop — the choice belongs to the user, and pre-picking a favourite converts an exploration back into a recommendation.

This never fires on its own. Its explicit-only sibling is pick-library: that one answers "which dependency", this one answers "which direction", and neither is a fallback for the other. It also does not review existing UI (ui-review), plan fixes for it (motion-audit), or hunt for places motion is missing (motion-opportunities) — those all converge on one answer, and this skill exists to refuse to.

Before designing anything, read the ground the variants must stand on. Framework, styling system (Tailwind, CSS modules, vanilla), motion library if one is installed, and the token set — colors, radii, spacing, fonts, easing and duration variables. Every variant is written in that system, using those tokens, so all of them look like they could ship tomorrow; a variant that invents its own scale is not a bolder direction, it is an unusable one. Sharing tokens is not convergence — divergence happens on layout, density, personality, motion, and interaction model, not on hex values. Read the product's personality too, because it bounds how far the boldest variant may go, and read where the piece renders: against what background, beside what neighbours, at what size. If there is no project at all, take the standalone branch and pick a restrained default — neutral greys, one accent, system font stack.

Quick Reference

Load references/picker.md at the moment you start building the harness, before writing any picker markup, and copy it verbatim. It is the only file here, and the only thing in this skill that is not a judgment call.

The Procedure

1 — Scope. One thing per run. If the brief spans a screen ("the dashboard"), narrow it: pick the single highest-leverage piece, say which and why, and offer the rest as follow-up runs. Restate the brief in one sentence — what the thing is, where it lives, what it must do.

2 — Name the axes before writing code. List the set: a name and a divergence axis for each. Names describe the direction — "Quiet", "Editorial", "Playful", "Dense" — never "Option A/B/C", which is a tell that no axis was chosen. If two proposed directions would differ only in accent colour or copy, they are one direction; replace one with a real alternative. Gate: every variant has a name and a stated axis, and no two occupy the same position on an axis.

3 — Build the harness. In a project with a dev server, an isolated route (/prototypes/<slug> or the framework's equivalent), one file per variant plus a small harness file, with nothing importing from it into production. With no project, a single self-contained HTML file the user can open directly.

4 — Verify. Flip through every variant yourself before showing anyone: each renders, each interaction responds, the console is clean. Screenshot each one if browser tooling is available.

5 — Present and stop. The comparison table below, then where the picker is running and which keys flip it.

6 — Promote on selection. Integrate the chosen variant following the project's existing file layout, naming, and token usage, then delete the prototype surface. If the user wants another round instead, keep the harness and re-run step 2, diverging around the direction they gravitated to.

Core Principles

1. Never touch production code during exploration. Everything lives on the isolated prototype surface until a winner exists; a half-integrated variant is a merge conflict with a design review attached. Exception: reading production code — tokens, existing components, utilities — is required, and variants should import shared primitives rather than fork them.

2. Every variant diverges on a named axis you can state in a phrase. If you cannot say "this one trades memorability for calm" before building, the variant has no thesis and will land as a tint. Exception: a riff round, where the whole set diverges around one already-chosen direction and the axes are deliberately narrower.

3. Default 3; ceiling 5. Three is enough to triangulate a space; past five the comparison dilutes and the user stops reading the table. Exception: the user names a count — honour it up to 5, and say why you are capping if they ask for more.

4. Every variant fully works. Real interactions, real motion, product-shaped copy with plausible names and numbers. A dead button teaches nothing about the direction it was standing in. Exception: none — lorem ipsum, placeholder handlers, and "imagine this part" all invalidate the comparison they appear in.

5. The craft bar holds inside every variant. Entrances ease-out, never ease-in; enter from scale(0.95) (0.97 when small) with opacity: 0, never scale(0); product motion under 300ms; transform and opacity only; correct transform-origin; prefers-reduced-motion handled. A sloppy variant does not widen the exploration, it just loses on execution. Exception: a variant whose stated axis is motion may sit at the far end of the range — it may not leave it.

6. The picker is chrome, not a contestant. Copy references/picker.md verbatim; it stays identical across every project so it never reads as part of the design being judged. Exception: exactly one — set data-position="top" when a variant occupies the bottom-centre of the screen (a toast stack, a bottom sheet, a dock). Nothing else about it moves.

7. Switching variants is instant; only the picker's own highlight animates. Flipping is a 100+/session action and by the frequency gate it gets no animation at all. The highlight slides 250ms cubic-bezier(0.23, 1, 0.32, 1) as feedback on the picker itself. Exception: switching re-mounts the variant so its own entrance animation re-runs — that is the variant's motion, not the swap's.

8. Judge at full size, one at a time, in context. A toast needs a page behind it, a card needs siblings, a button needs a form. Side-by-side thumbnails distort spacing and scale, and no one has ever picked correctly at postage-stamp size. Exception: a screenshot grid in the summary message is fine as an index — the live harness stays one-up.

9. Clean up after the choice. Delete the prototype surface when a winner is promoted. Exception: the user asks to keep it (keep <variant>, leave the picker).

Output Format

One row per variant, one honest line each way. Never mark a favourite in the table; if asked which you would choose, answer from the product's personality and the feature's frequency of use, not aesthetics. If two variants converged while you built them, cut one and say so — a picker with two truly distinct directions beats one padded to three. Close with the URL or file path and the keys: 1–N and ←/→ to switch, R to replay, ?v=<n> to share one directly.

Checklist

• The run was explicitly requested — this skill never self-invokes
• Scope is one component, restated in one sentence
• Every variant has a name and a stated axis; no two share an axis position
• Variant count is 3 by default, never above 5
• All variants use the project's tokens and stack
• references/picker.md was copied verbatim; only data-position was changed, if anything
• Variant swap is instant; entrances re-run on switch
• Every variant renders and responds, console clean, checked personally
• Comparison table names each cost honestly and picks no winner
• Prototype surface deleted on promotion, or kept because the user asked