A correction control must appear with the inference result, not buried in settings

What it is

“Not this” must appear on the piece of UI where the inference is being perceived: next to the wrong do-not-disturb strip, the wrong affect chip, the wrong auto scene. Putting it on a sensors page in settings is offering court after the person has left the scene. Where the correction control sits is discovery cost, not whether a feature list contains the item.

Why it happens

The discovery window for an implicit error is short: the light is already on, the track already skipped, attention already back on the primary task. Correction is an objection bound to that result and has to fit in the window. Settings IA is grouped by feature, not indexed by “that thing just now,” and people often do not know the search term (EDA versus a scene engine). A same-screen control turns objection into one tap; deep settings turn it into information foraging. Depth also filters users: only those willing to interrupt the primary task to hunt a menu can correct, which biases toward people least interrupted.

Studying it

Place correction beside the result versus three levels down in settings; measure time-to-find, completion, abandonment. Factors: control copy (“not stress” versus “feedback”), confirm required or not. Outcomes: fraction restored within two minutes. In the lab an experimenter can hint “it’s in settings”; the field cannot, so ecological validity depends on forbidding that hint. Heatmaps should show how many open settings and still miss the matching item.

Where it stops holding

A system-wide switch unrelated to a single inference can live in settings; it is not this correction. Accessibility users may be unable to hit a small control beside the result and need an equivalent voice or hardware key, still bound in time to the result (saying “wrong” when it just happened). Too-dense on-screen controls become new mis-taps; persistence should match consequence: high-consequence earns a standing button.

Applying it

• Put an objection control next to every user-perceptible inference result, default one tap, no detour through settings.
• Settings may hold an overview and history, but must not be the only entry.
• Label the control against the conclusion (“not in a meeting”), not against the sensor name.
• Verify with no mention of settings: can unbriefed users correct from the current screen? Having to enter settings is a placement fail.

Related

• Same group: C9.13.1 Users should be able to see which signals the system currently used to draw which inference · C9.13.3 A correction should carry to later similar inferences, or users will keep fixing the same error · C9.13.4 Implicit inferences that cannot offer a correction path should not change user-perceptible UI behavior
• Adjacent: C9.05 Implicit Interaction · C7.13 Voice Editing and Spoken Correction
• Search: co-located correction · inline undo · settings burial