Multiple options turn generation into a choice

What it is

A meeting invite is requested. One letter appears: the next move is to edit it or keep it — the task is still production. Three complete invites appear: the next move is to tap one — the task is selection. Generation as selection means issuing several independently adoptable candidates at once, rewriting the human job from “finish the material” to “decide among material already written.”

It is not a lesson in randomness. It changes which kind of decision this step is.

Why it happens

A singleton forces evaluation on an absolute scale: is this good enough. Absolute judgment has no anchor, so people keep polishing wording because “good enough” never sits still. Several complete candidates switch the scale to relative: which of these three. Relative judgment comes with a contrast set, and the decision leaves the production loop.

Candidates must each be adoptable on their own. A half outline, or one main result plus two broken backups, is still production — the chosen one still has to be finished. The conversion is complete only when each option can go straight into the next action: send, insert, export.

Studying it

Same prompt, an editable singleton versus 2–4 complete candidates plus “use this.” Record whether the first effective action is edit, pick, or discard-and-retry. Independent variables: whether candidates are independently usable, presence of a default highlight. Dependent variables: task-type judgment (self-report “I am choosing” vs “I am revising”), path length from appearance to submit, whether people still rewrite from a blank.

Code “picked then heavily rewritten” separately. Heavy rewrite means the interface offered an entrance, not a completed change of task type.

Where it stops holding

Closed answers (an arithmetic result, a violation or not, a primary key) offered as several candidates mint a false choice; they should collapse to one and be checked. When the user is already continuing a particular draft, forcing a new set interrupts production in progress. If candidates cannot stand alone (a draft with no recipient, a composition with no size), selection cannot occur and the task falls back to production. On a narrow screen a tap-to-pick can still be a choice; that is a load problem, not a task-type problem.

Applying it

• Give each option an explicit adopt action, not only “copy” or “drop into the editor and keep going.”
• Do not draw one as the result and the rest as weakened backups. A primary result pins the task back to “revise this one.”
• After adopt, keep the others. Switching still needs them.
• Check: after generation, give no prompt and watch the first click — adopt, edit, or regenerate. If most people first edit the default-highlighted one, the task never became a choice.

Related

• Same group: L3.01.2 Option count beyond comparison capacity is wasted · L3.01.3 Options need discriminable differences
• Nearby: L3.07 Multi-option Generation and Side-by-side Comparison · L1.01 Mismatch Between Stochastic Output and Deterministic UI · L3.12 Editing and Taking Over Generated Content
• Search terms: generation as selection · candidate set · choice architecture