The edit entry point belongs where the outcome appears

What it is

Users don't decide to edit automation rules while browsing the settings page — they decide when an automated behaviour happens in front of them: the light switches itself off again, the wrong reminder fires again, the curtain opens at the wrong moment. The edit entry point must be reachable where the outcome is presented: the screen that shows the behaviour is the screen that can change it.

When entry and outcome are separated (outcome in the living room, editor three menus deep in an app), the moment of strongest motivation has nowhere to go — by the time the settings page opens, which behaviour it was, in what context, and why it was annoying have all faded.

Why it happens

Editing motivation is perishable. The judgement "that behaviour is wrong" and the will to fix it peak at the moment the outcome occurs and decay to zero within hours. Every layer of entry distance — navigation depth, device switching, hunting down the device card — shaves the conversion from motivation to action. Where the entry sits decides whether the user's editing impulse gets caught or ground away.

Position is pedagogy. An edit entry at the point of outcome is also a teaching touchpoint for rule transparency: "the light went off → tap → ah, a rule kills it at 23:00 → nudge it to midnight while I'm here". Users learn rules in a real situation with a real grievance — far more durably than by calmly browsing a rule list in the settings page. Separating the entry forfeits this free daily lesson.

The reverse effect is learned helplessness. A system whose outcomes are visible but whose entry is unreachable trains users to stop reacting — they reported, they searched, they didn't find, and eventually they stop even forming the complaint. Support traffic disappears on the surface; underneath, the system has entered the psychological state of "nobody can do anything about it", which is typically the last step before abandonment.

Where it stops holding

• Prominent does not mean persistent. The entry can be a lightweight action attached to the outcome — tap the notification, long-press the device card, a spoken phrase — with no standing button required. A permanently visible "edit" affordance is itself environmental noise, contradicting ambient computing's disappearance principle; present when needed, absent otherwise, is the correct form.
• Ephemeral outcomes need a retrospective path. Some actions flash past (a chime, a transient toast); there is nothing to tap at the moment — at minimum, the outcome's history view must lead back to the edit entry: every log line of a trigger should jump to that rule.
• A discoverable entry is not open permission. In shared spaces guests see the entry too; visible to all, permitted per role is the right split — hiding the entry to enforce permissions fails twice: legitimate users can't edit, and the system reads as a black box to everyone else.

Applying it

• Whenever an automation fires and produces a visible outcome, the outcome's interactive form carries the edit entry: notifications with "adjust rule", device status pages with "this state was set by which rule → edit".
• Trigger history as edit entry: every logged trigger jumps straight to that rule's editor.
• Deep-link to the specific rule, not to the settings home — making users find it again from the top is hiding the entry one more time.
• How to check: a reachability audit — for every automated behaviour, measure the steps from "seeing the outcome" to "being able to edit that rule"; every place over three steps is a loss point to be eliminated.

Related

• Same group: Z3.06.1 Users must be able to stop an automation action while it runs · Z3.06.2 After a takeover the system must not silently resume its previous behaviour · Z3.06.4 Takeovers should be recorded to improve future judgements
• Nearby: Z3.05.3 Predictability comes from transparent rules, not from memorised exceptions · Z5.03 Tracing causes
• Search terms: situated editing · edit in place · trigger notification · deep link