Misjudged availability makes users repeatedly try an unusable channel

What it is

When detection calls an unusable channel available, users keep speaking, tapping, gazing, or waiting for feedback that cannot arrive. The cost exceeds the first failure: people repeat, raise their voice, press harder, or blame themselves, so recovery takes far longer than after an explicit unavailable notice.

Why it happens

False-available is more dangerous than false-unavailable because it produces no direct error signal. Input may be received at low confidence; output may be emitted but masked. Without a confirmation loop, the system treats the task as complete. Seeing no interface change, users retry by convention; retries can then change state again—duplicate commands merge, a second action fires, or attempts run out. A valid judgment loop needs three kinds of evidence: channel health, signal quality above threshold, and an outcome confirmable by user or system.

Studying it

Create boundary-quality conditions: set noise near the recognition threshold, mask speakers, weaken haptics, or restrict viewing angle, then observe divergence between judged and actual availability. Variables include threshold, retry count, feedback visibility, and coaching. Outcomes include retries, time to abandonment, duplicate execution, wrong actions, and attributions. Think-aloud or replay interviews capture “I thought I did not say it clearly.” Compare conservative and optimistic thresholds to see how the direction of error shifts.

Where it stops holding

Over-conservative thresholds report usable channels as dead, causing unnecessary switching and capability loss. Brief low-quality periods—head turn, movement, transient noise—warrant buffering rather than immediate failure. Confirmation loops also face privacy limits: full transcription or screen recording cannot be retained merely to verify delivery. For irreversible commands, retries need re-entry protection; for low-risk feedback, a short wait with visible state may fit the interaction rhythm better than instant judgment.

Applying it

• For input, show “received but uncertain” at low confidence; for output, use receipts or perceptibility checks to confirm delivery.
• Add state and an upper bound to retries; after the bound, move to an alternative channel or clarification rather than the same path.
• Distinguish transient quality dips from persistent failure with buffering and consecutive-failure counts.
• Verification: near real thresholds, measure retries, duplicate execution, and time to abandonment; if false-available persists, fix the confirmation loop rather than only the wording.

Related

• Within the group: D5.10.1 The system must detect at runtime whether the environment supports the default modality · D5.10.2 Detection failure should actively offer alternatives rather than fail silently
• Adjacent: D5.08.2 Silent guessing causes harder-to-notice errors than explicit fallback · D5.09.3 The switch entry point should be reachable at any time, not only on particular screens
• Search terms: false availability · retry loop · confirmation feedback