Building a scene means specifying every device state by hand

What it is

A scene packages the target states of multiple devices into one operation — "leaving home" is the union of lights off, thermostat down, doors locked, sockets off. The problem is on the creation side: mainstream apps make users specify this set device by device, state by state — select each lamp, set each dim level. A scene's value grows with device count, and so does its creation burden, and the burden hits the ceiling first.

The obvious shortcut, "capture the now", mostly doesn't exist: after adjusting the room to the desired state, users cannot say "save it like this". Instead they must redo, against a checklist in the app, the very settings they just made by hand.

Why it happens

Why does the burden sit in the enumeration? Look at the cost structure: a scene is stored as an explicit state table — one target value per device. Creation cost scales with device count and is pure manual labour: the user must reconstruct from memory a vector like "lights 30% for movie time, curtains closed, AC at 24°C", with no pathway importing reality into the configuration.

"Capture the now" is technically non-trivial for real reasons: scenes execute absolute targets, not relative adjustments, and current state is noisy — a device reading offline yields stale values, and "the curtains exactly as now" may not be the target the user wants. Capture requires every device online with trustworthy state, a premise that often fails in real homes, so vendors skip the feature and hand the enumeration labour to the user intact.

One more layer, a mental-model mismatch: users think in episodes (the activity "watching a movie"), systems store device vectors (N setpoints). The translation from episode to vector gets no assistance whatsoever — which is why "configuring item by item" feels exhausting: not the number of taps, but the translation each tap is preceded by.

Studying it

The trigger-action programming literature carries the empirical weight here:

• Ur and colleagues' 2014 large-scale survey of IFTTT users found that real users' rules are far simpler than the platform allows — overwhelmingly single-trigger, single-action, involving one or two devices or services. The complexity people actually use sits far below what the system can express; "can configure a lot" and "will configure a lot" are different claims.
• Earlier context-programming prototypes — Dey et al.'s iCAP (CHI 2006) — explored reducing specification cost through demonstration and capture, marking the "build rules from examples" route.
• The standard burden measure is the authoring-task study: give non-technical users a real device inventory, ask them to build a specified scene, and score completion, time, and semantic mismatch, with think-aloud transcripts showing where the translation happens.

One methodological caution: lab authoring tasks hand participants a scene description written by the researcher, skipping the step where users conceive the scene at all — in real homes the expensive part is often thinking of what to build, not building it. Pair the task with home interviews asking "which scenes do you have, and where did they come from" to cover that segment.

Where it stops holding

• Exceptions exist and are growing. Some platforms already offer "save current state as scene"; voice assistants support demonstrative creation (set the room, then "remember this as movie mode"). The strength of "must enumerate" varies by platform — verify the target product's actual capabilities before judging.
• Real households run few scenes. Field studies find most homes use single-digit numbers of active scenes; burden claims should not be extrapolated to power users, who enjoy fine-grained control precisely.
• Mixed-brand homes make enumeration worse. Building half a scene in each vendor's app doubles the fragmentation; cross-brand orchestration barriers are a separate topic — count here only their amplifying effect on creation burden.

Applying it

• Provide a "capture the now" entry: one tap saves all controllable devices' current states as a scene draft, with offline devices flagged "not captured — fill in manually". This demotes the technical prerequisite from "feature absent" to "a few items pending".
• Derive the device checklist for scene creation from room/activity templates, instead of making users browse the whole-home inventory.
• Demonstration-first creation: adjust the room, then name and save — aligned with the mental direction (experience first, configuration second).
• How to check: count the manual operations (taps + inputs) to create an N-device scene, compared against the capture-the-now path; first-week scene-creation completion among new users is the direct behavioural indicator.

Related

• Same group: Z4.06.2 Setting trigger conditions is hard for non-technical users · Z4.06.3 Templates lower the barrier but fail to cover personal needs · Z4.06.4 Scenes still need real-world validation after creation
• Nearby: Z5.05 Scenes and modes · Z5.04 Ways of expressing orchestration
• Search terms: scene creation · trigger-action programming · smart home configuration