Proactivity levels should be user-settable

What it is

No single proactivity level suits everyone: sensitivity to consequences, tolerance for interruption, and prior trust in the system all vary by person. User-settable proactivity moves the position on the spectrum from a product decision to a user control — the same auto-lock feature can be fully automatic for one person, a reminder for another, manual for a third.

"Settable" does not mean "dumped on the user". Defaults are still set by designers according to consequence and confidence; the setting's job is to absorb the residual — the individual differences no default can cover. The mirror failure, defaulting everything to manual and making users upgrade themselves, hands the design responsibility back and is equally negligent.

Why it happens

Three layers of mechanism.

First, trust builds gradually. Users try new systems at low levels and promote them as they verify performance (calibrated trust: trust should match actual capability, not be maximised). Without a ladder of levels, users face only "trust fully" or "switch off" — trust formation is forced into extremes, and most people switch off.

Second, the power of disposition itself. Being able to adjust is valuable independent of where one adjusts to: users who know "I can turn this off at any moment" are the ones willing to run it at a high level. Perceived control precedes trust rather than following from it — consistent with automation research showing that reliance on controllable systems is more stable.

Third, consequences are private. The magnitude of the same action differs across users: auto-lighting is nothing for someone living alone, and a disturbance to a light-sleeping relative for someone who is not. Consequence magnitude enters the cost calculation, and only the user knows theirs — which is why the level is not something a product can compute correctly on its own.

Studying it

• Automation trust research (Lee and See's synthesis on trust calibration) supplies the theoretical frame for individually adjusted trust: appropriately calibrated trust requires handles on system behaviour, not good intentions.
• Interviews and surveys of smart-assistant and home-automation users repeatedly find a wide distribution of automation preferences, correlated with perceived consequences and prior experience — especially of being burned; preferences also diverge within a single household.
• Preference-migration studies track how settings evolve with usage tenure (conservative at onboarding → promotion in steady use → regression after a failure), testing whether the gradual-trust path actually occurs.

One methodological caution: stated level preferences and actual settings disagree — a robust finding. Users report wanting conservative behaviour yet sit at the defaults for months. Level research should lean on behavioural data from real settings panels, with self-report as a supplement.

Where it stops holding

• Too many settings is the anti-pattern. One five-stop slider per feature across dozens of features is dozens of decisions, and users just stay at defaults — the value of settablity comes from scarcity, not coverage. A few global modes ("ask more / normal / autonomous") plus independent adjustment for a handful of high-stakes features usually beats per-feature openness.
• Some levels must stay closed. For actions touching safety or third parties (unlocking for a visitor, sending on one's behalf), the product must cap the maximum level; user settings operate only below the cap.
• Defaults still dominate outcomes. Most users never open settings; settablity improves the tails of the distribution. A wrong default cannot be rescued by adjustability.

Applying it

• Offer about three levels per proactive feature (suggest / execute-with-undo / fully automatic), with defaults set conservatively by consequence magnitude.
• Put the adjustment entry where the consequences of a misfire appear: on the "that light shouldn't have come on" notice, offer "just remind me next time" — collecting the setting at the moment of strongest motivation beats burying it in a settings tree.
• Make changes bidirectionally visible: after a downgrade the behaviour should demonstrably change; the system may ask about an unused level but must never silently revert.
• How to check: track the level distribution and migration paths — share left at default, share promoted from low levels, share downgraded within 48 hours of a misfire. A high third number means the default systematically mismatches users' sense of consequence; fix the default rather than waiting for users to rescue themselves.

Related

• Same group: Z3.01.1 From notification through suggestion to automatic execution is a continuum · Z3.01.2 Automation levels must match inference confidence
• Nearby: Z3.03 Failures of intent inference · Z3.04 Implicit and explicit paths coexist
• Search terms: user-settable automation · trust in automation · calibration of trust · personalization