Users need adjustable sensitivity

What it is

The optimal operating point of a detection function differs across households — layout, pets, routines, and tolerance all reshape the real costs of false alarms and misses — so no factory default can fit everyone. Detection functions therefore need end-user adjustment: the ability to move the sensitivity to one's own working point while in use. Without that entry, users facing an ill-fitting default have two options — endure, or disable — and most choose the latter.

The thing adjusted need not be a numeric threshold: "too sensitive / too sluggish" binary feedback, scenario presets, and per-rule toggles are all forms of adjustment entry. What matters is leverage: the user's action genuinely shifts the system's behaviour distribution.

Why it happens

Why adjustment must exist: environmental differences change the signal distribution itself. A household with a cat and one without differ by an order of magnitude in false-alarm rate at the same PIR threshold; a night-shift household's "late night" has nothing to do with the default. These are not noise but systematic differences between distributions — a single default migrating across households lands like a random operating point.

Adjustment also carries a cognitive function: the loop of adjust, observe for a week, adjust again is the only route by which users give the abstraction "sensitivity" a grounded, embodied experience — they come to understand the system through their own household's history of false alarms. This builds mental models more effectively than any documentation; users who never adjust remain stuck at surface attribution ("it just beeps sometimes").

And when no adjustment exists, user behaviour is not resignation but physical resistance: taping over the camera, unplugging the sensor, cutting power — a costlier mode of failure, and one the system's makers never see the reason for.

Studying it

• End-user programming: Ur and colleagues' 2014 study of trigger-action programming found that non-technical users widely create and understand simple condition rules but systematically err on edge cases (multi-condition combinations, negation) — the form of the adjustment entry directly determines usability, and simple binary adjustment sits far closer to user capability than a parameter panel.
• Granularity preferences: the smart home privacy and control survey of Zeng, Mare and Roesner (2017) found users clearly want fine-grained control over device behaviour and data, while actual usage concentrates on a few high-frequency settings — the gap between "wanted" and "used" is itself a design constraint.
• Comparing adjustment forms: slider versus preset versus natural-language feedback, with adjustment accuracy and downstream satisfaction as outcomes — a recurring design in the interaction literature (safe to state generally).

Methodological caution: adjustment usage is a low-baseline event (most users never open settings); evaluate an adjustment design by the subsequent retention and complaint changes among those who did adjust, not by population-wide usage rates.

Where it stops holding

• Adjustment does not replace a good default. Most users never adjust; the default remains the dominant operating point. "It's adjustable" exempts no one from "the default must be right".
• Fine granularity is a burden. A parameter matrix of sensor × time-slot × rule is used by no one; effective adjustment is coarse-grained and high-leverage (global sensitivity, per-function toggles).
• Adjustment shifts responsibility. After a user loosens the setting, perceived responsibility for a miss changes — the product must state consequences honestly at the moment of adjustment ("at this level, mild activity will no longer be detected"), or adjustment becomes a responsibility trap.

Applying it

• Give frequently-complained functions a binary quick adjustment ("too sensitive / too sluggish"), not a parameter panel; stepped feedback, immediate effect.
• After each adjustment, show the consequence forecast: "at this setting, expect about X alerts per week" — an expected behaviour change in place of an abstract sensitivity number.
• Put the entry at the site of the false alarm: "fewer alerts like this" directly on the notification, not three menus deep — users have adjustment motivation exactly when they have just been disturbed.
• How to check: track adjustment usage, post-adjustment retention, and repeat-adjustment rate. Retention rising and adjustments converging means the entry works; nobody using it, or endless re-adjusting, means the form or granularity is wrong.

Related

• Same group: Z2.03.1 The costs of the two error types are usually asymmetric · Z2.03.2 Threshold setting is a product decision
• Nearby: Z2.08 Users correcting context judgements · Z5.01 Automation rules
• Search terms: end-user tailoring · trigger-action programming · smart home customization · adjustable thresholds