Brainstorm Prototypes

Brainstorm and prototypes

The user has unknown knowns: criteria they can't verbalize but will recognize on sight. Finding those during prototyping is cheap; finding them mid-implementation is expensive, because small spec changes can mean drastically different code. Give them things to react to.

Steps

• Establish scope first: what is being decided (layout? approach? data model? tone?) and what is explicitly out of scope. One decision per round.
• Produce 3-5 variations that are wildly different, not shades of the same idea. If two variations would get the same reaction, replace one.
• Make them cheap and disposable:
• Visual/UX → a single self-contained HTML file with fake data, no backend, no state.
• Approaches → a one-screen sketch of each: the idea, what it optimizes for, its sharpest tradeoff.
• Ranked lists → order from cheapest to most ambitious so the user can draw their line.
• Label each variation with the belief it bets on ("this one assumes density beats whitespace"), so the user's reaction reveals the underlying criterion, not just a preference.
• Collect reactions, then verbalize what was learned: "you consistently rejected X, which suggests the real requirement is Y." That sentence is the deliverable — it becomes part of the spec.

Guardrails

• Nothing produced here is production code. Say so, and don't wire prototypes into the real app.
• Do not converge early to the variation you'd pick. The point is spanning the space.
• If the user reacts to none of them, that's signal too: the decision space was framed wrong. Reframe and rerun rather than generating more of the same.