Users must be able to adjust existing automations

What it is

Established automations must be adjustable: tweak a condition, shift a threshold, swap an action — not configured once for life, with change meaning demolition and rebuild. This places the user in the position of the automation's author: the stance of the end-user programming tradition — users are not merely consumers of automation but its maintainers, and authors need editing rights.

It differs from creatability. Products invest heavily on the creation side (wizards, templates, one-tap scenes) while leaving the editing side strikingly barren: to change a rule you must first find it (buried several menus deep), understand it (the original configuration long forgotten), and touch it (no partial modification — delete and recreate). Creation is a one-time event; adjustment is a lifelong accompanying labour — and the investment mismatch between the two sides is pervasive.

Why it happens

Why is the initial configuration necessarily incomplete? Three sources compound:

Configuration runs on imagined use. The rule set at installation comes from the user's imagination of life ("auto-off the lights after 10 p.m."); real use exposes the imagination's biases (10 p.m. is too early on weekends). Misconfiguration is not user error but the normal gap between imagination and reality — adjustment is not an exception path but the mandatory one.

Needs surface with use. Many adjustments are unthought-of at installation (the cat trips the motion sensor; summer and winter want different thresholds); they only become visible after the system has run for a while. Adjustability decides whether these surfaced needs have an outlet at all.

Wizard flows freeze parameters. One-shot wizards lock parameters into the context of installation day and usually offer no way back — when the user wants to change something, the wizard is gone and no equivalent editing surface exists.

Together: an unadjustable automation necessarily drifts away from its user's needs; only the drift rate differs.

Studying it

• The end-user programming tradition: from spreadsheets to smart homes, the field's core concern carries over — can non-professional users express and modify logic safely? In the smart-home context, research on trigger-action programming systematically examines users' correctness in creating and modifying rules, common error types, and the ceiling of expressiveness.
• Modification-task experiments: give participants an existing rule and a modification goal ("make it skip weekends"), measuring completion rate, time, and error types. This paradigm is closer to long-term-use workload than creating from scratch, and exposes editing-side gaps creation wizards cannot paper over.
• Configuration-evolution analysis over deployments: gather months of usage logs and tabulate how often rules are modified, the distribution of modification types (threshold tweaks more common than action swaps?), and post-modification survival — data showing that configurations are living things.

One methodological caution: experiment modification goals are given; in real life users must first realise that dissatisfaction can be solved by modifying — a metacognitive step the lab cannot measure. And in logs, "never modified" spans both satisfaction and surrender; interviews must separate them.

Where it stops holding

• Editing capability has a learning cost. The editing interface is itself an interface: the more expressive, the steeper the learning. For users who only want presets, editing rights are worth nearly nothing. Supply adjustability in layers: light tweaks (time, threshold) at zero threshold; complex rewrites (conditional logic) can remain for the few.
• Not every parameter should be open. Parameters tied to safety and device protection (power ceilings, anti-false-trigger lockouts) are legitimately read-only; the objects of open editing are behaviour logic, not the entire internal state.
• Adjustable is not infinitely fine-grained. Granularity taken too far (per-sensor sensitivity, every debounce parameter exposed) turns maintenance into professional work; good defaults with a few tunable parameters beats fully tunable everything for maintainability.

Applying it

• Make a rule's condition, time window, and action each independently editable, with no segment change requiring delete-and-recreate; demolition should be the fallback after editing fails, not the only path.
• Offer save-as-difference: an adjusted rule can be saved as a new version without overwriting the old, with one-click rollback — cutting the psychological cost of "touching it".
• Keep the editing entry reachable where results appear: one step from "this rule didn't fire last night" into editing that rule, rather than a trek through settings.
• How to check: give three-month-old households three real modification tasks (shift a time, add an exception, swap an action) and score unassisted completion and time; then pull the in-app ratio of delete-and-recreate to partial modification — a high recreate share means the editing path does not really exist.

Related

• Same group: Z7.03.2 The cost of modification decides whether the system stays in use · Z7.03.3 When modification is impossible, users switch the whole thing off
• Nearby: Z5.04 Ways of expressing orchestration · Z3.06 Editing and taking over automation
• Search terms: end-user programming · trigger-action programming · rule editing · customisation