UI explore

Throwaway artifacts that answer a design or logic question before committing production. One skill, three shapes.

Sources (attribution)

• HTML A/B: Anthropic The unreasonable effectiveness of HTML; local design-picker patterns (?design=, floating switchers).
• In-app / logic prototypes: throwaway prototype branch pattern (UI variants + terminal state machines) — original synthesis; templates in-repo.
• Full pack credits: ATTRIBUTION.md.

Pick a shape

1. Logic / state / API feel → references/logic-branch.md
2. Look & layout
   • Prefer HTML A/B for small product deltas and review without a full app boot
   • Prefer in-app variants when judgment needs real chrome/data density
     → references/ui-branch.md + HTML rules below

If ambiguous and user is unreachable: product page → UI; backend module → logic. State the assumption at the top of the artifact.

Rules for every shape

1. Throwaway and marked as such (banner, path name ui-explore, title).
2. One command to run (project runner or python3 -m http.server).
3. No production polish (no full test suite, no gold-plating).
4. Surface state after every action / variant switch.
5. Delete or absorb when the question is answered; capture the verdict.
6. Live data when the surface already has a backend. Bind to the real API or a recorded snapshot of it so density is honest. Empty fixtures hide the product. Do not rewrite production chrome to explore — product-design principle 9. If web / mobile-web / native share the surface, the variant must be judgable on all of them (or say which surface is out of scope).

Shape 1 — Standalone HTML A/B (product deltas)

Inspired by The unreasonable effectiveness of HTML.

Hard rules

1. Match blast radius. Small ask → Design A = current, Design B = current + only that delta.
2. HTML first, production second.
3. One switcher surface (floating picker / keys / ?design=).
4. Serve + verify the URL; give the user the link.
5. Record the pick (one line: which design, what to implement).

Workflow

1. Frame one sentence question.
2. Mode: A/B before–after (default) or multi-variant (max 5).
3. Build one HTML file — scaffold templates/ab-compare.html; patterns references/patterns.md; anti-patterns references/anti-patterns.md.
4. Serve (./design/serve.sh or python3 -m http.server 8765).
5. Verify switcher; user picks.
6. Implement via mockup-implement only after sign-off.

Paths: design/<topic>-ab.html when the repo has design/.

Shape 2 — In-app UI variants

Full process: references/ui-branch.md.

• Prefer embedding variants on an existing route with ?variant= (real header/data).
• Floating bottom bar; 3 variants default, max 5.
• Mark route/file as prototype; delete or fold after decision.

Shape 3 — Logic terminal prototype

Full process: references/logic-branch.md.

• Pure logic module + throwaway TUI.
• One command; print full state after each action.
• Lift validated logic into production; delete the TUI.

Done criteria

• User can run one command / open one URL
• They can switch variants or drive cases without re-prompting
• Verdict captured (which option / what we learned)
• Production path named or explicit reject + delete plan

Hand off