L2.15.2ask only on outcome-changing ambiguitydesignresearch

A follow-up is worth asking only when the ambiguity would lead to clearly different outcomes

Aliases: ask only if paths fork · harmless ambiguity · value of clarifying information

What it is

“Make it blue” on a button that only has a fill still paints the same blue button under either reading; asking “fill or stroke” is a waste. The same line on a poster can mean brand colour, ground, or accent — three readings, three posters — and then an ask is worth it. The bar for a follow-up is whether outcomes fork, not whether the sentence is linguistically vague.

Many systems ask because “I am not sure.” Model uncertainty and outcome fork are not the same. Uncertain, but every reading leads to the same act: the ask only adds a turn.

Why it happens

The value of a clarification is: the cost of the act differing across readings, times the chance of taking the wrong road, minus the cost of one question. When the act-gap is near zero, value is negative. Linguistic ambiguity (pronouns, ellipsis, polysemy) is in almost every sentence; asking at every site, the dialogue cannot move. People interrupt only when two roads lead to different worlds.

Engineering often uses confidence as the bar. Confidence measures the model’s feel for its own distribution, not the act-gap. Low confidence, same act, still produces a useless ask; high confidence, sharply different acts (“delete” the file or the folder), gets skipped. The bar is wired to the wrong sensor.

Studying it

For each instruction, build the set of readings and, for each, the act or artefact that would be executed. Compute an observable distance between acts (same API call or not, pixel diff, whether users judge them different). Allow a follow-up only if distance clears a threshold. Independent variables: bar type (model confidence / act distance / always ask). Dependent variables: useless-ask rate (asked, but the two artefacts are indistinguishable), harmful-skip rate (did not ask, but the artefact is judged different), total turns.

“Judged different by a user” must be coded by someone who did not design the system. Designers will see an internal fork in two calls that look the same on the surface; users will not.

Where it stops holding

Safety and compliance treat some ambiguities as forks by policy (minors, medical dose, whether this goes outbound), even when artefacts look close; ask anyway. In exploratory making, people sometimes want the fork itself; the follow-up can become “want two versions side by side,” which is no longer clarifying, it is displaying the fork. When the reading set cannot be enumerated (open domain), act distance cannot be estimated; fall back to a more conservative ask, and admit it cannot be estimated — that is not the model being modest.

Applying it

  • Before asking, dry-run “what would I do” on each candidate reading: same tool, same parameters, do not ask; different tool or parameters, ask, and name the dimension that differs (“blue the ground or the type”).
  • Do not let model confidence alone decide whether to ask. Confidence can rank candidates; it cannot replace the act-gap.
  • Harmless ambiguity can run, with half a sentence beside the result naming the reading that was taken, so a later correction is cheap — do not halt for it.
  • Check: collect twenty vague instructions, hand-label “would a user see these two readings as different outcomes.” The system should speak only on the ones labelled different. Speech on the “same” ones is a useless ask; silence on the “different” ones, show the artefact to a third person — if they judge it different, that was a harmful skip.

Related

  • Same group: L2.15.1 Assuming one reading and running with it is faster, and it also enlarges the cost of being wrong · L2.15.3 Too many follow-ups turn the exchange into a questionnaire and cancel the efficiency natural language was for · L2.15.4 Leading with a result and stating the assumption is a third path between asking and running · L2.15.5 Weigh the cost of clarifying against the cost of undo; if undo is cheap, do not ask
  • Nearby: L2.12 Iterative Edits and Local Regeneration · L3.07 Multi-option Generation and Side-by-side Comparison · L5.08 Counterfactual Explanations
  • Search terms: outcome-changing ambiguity · value of clarifying information · harmless ambiguity

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/L2.15.2