Templates lower the barrier but fail to cover personal needs

What it is

Vendor-preset scene templates ("movie night", "good morning", "away security") solve the blank-page problem: a starting point instead of an empty form. Templates genuinely lower the creation barrier — but homes are not homogeneous, and a template encodes a normalized household: dual-income, nine-to-five, living-room-centric. The farther a home sits from that prototype, the more a template turns from "starting point" into "thing to be fixed" — and templates resist fixing: read-only references, missing devices, locked parameters all push users away.

The result is a two-segment failure: homes near the prototype use templates but never personalize them (make do), and homes far from the prototype give up entirely (back to the blank page, or out of automation altogether).

Why it happens

The value and the cost of templates share one mechanism: a template is a prior over the configuration space. The benefit is deciding the structure for the user — which device classes participate, roughly what parameters; the cost is that the prior carries prototype-household assumptions. The personalization gap equals the home's deviation from the prototype.

Why is the gap so hard to bridge? Three links.

Editing someone else's decomposition can be harder than building your own. When the template's structure doesn't match the user's own categories (organized by rooms, thought in activities), revising the structure costs more mentally than rebuilding — cognitively, "translate and correct an alien plan" weighs more than "express my intent". This is the mechanism by which templates add burden for some users.

Read-only templates refund the cost untouched. Where templates cannot be edited, the only path is manually recreating a personal copy from the template — none of the item-by-item burden is saved, with an answer key attached.

Coverage gaps are silent. When a template applies to a home, available devices take effect and missing ones are skipped — without declaring what was missing. The user never learns that "good morning" was supposed to open the curtains; the home simply never had smart curtains, so the experience feels incomplete with nothing to attribute it to, and the conclusion drawn is "smart homes are just like this".

Studying it

• Template-ecosystem usage data: Ur et al.'s 2014 IFTTT survey showed public recipes heavily concentrated in a few popular templates, with most users' rules adopted wholesale from existing recipes rather than self-built — templates are de facto the mainstream creation path, and the needs they fail to cover are the mainstream's unmet needs.
• Randomized authoring comparisons: template-start versus blank-start — completion, satisfaction, and crucially subsequent modification rate. Modification rate is the key indicator: template-created scenes that go long unmodified are either a perfect fit (rare) or abandoned; scenes that keep being fine-tuned are the living ones.
• Longitudinal tracking: survival curves of template scenes in deployed homes — how many get rewritten, deleted, or bypassed (no longer triggered, no longer used).

One methodological caution: "usage rate" is the most misread template metric — adopting once counts as use, but adoption is not satisfaction. Usage rates without modification and survival data overestimate template fit.

Where it stops holding

• Where the target environment is itself standardized, templates approach perfection. Hotel rooms, show flats, standardized offices — uniform layouts and device inventories put the template's prior in high agreement with reality. Template failure scales strictly with environmental deviation from the prototype, and homes are precisely the least standardized environments — which is why smart-home templates struggle while hotel templates work.
• Brand coverage caps template quality. The more cross-brand devices a home has, the smaller the matchable fraction; single-brand whole-home setups get the best template experience — partly vendor lock-in, which evaluations should separate from template merit.
• Light users may want exactly "good enough". For households that just want some ambient automation, an imperfect template suffices; personalization demand concentrates in invested users. Assess the two populations separately.

Applying it

• Templates must be editable forks: importing creates the user's own scene, freely modifiable — never a read-only reference.
• On application, report coverage against the user's actual inventory: "this template uses a device you don't have: humidifier — skip or substitute", turning silent gaps into explicit choices.
• Pre-localize from onboarding answers: schedule, timezone, and orientation asked at setup flow directly into template parameters ("good morning" defaults to the user's wake time, not 7:00).
• Layer the template library by household prototype (families with children, night-shift workers, single-room renters), not by device taxonomy.
• How to check: two-week modification rate of template-created scenes (modification happening = editability works); deletion rate and the silent death of never-again-triggered scenes (= prototype mismatch).

Related

• Same group: Z4.06.1 Building a scene means specifying every device state by hand · Z4.06.2 Setting trigger conditions is hard for non-technical users · Z4.06.4 Scenes still need real-world validation after creation
• Nearby: Z5.04 Ways of expressing orchestration · Z5.05 Scenes and modes
• Search terms: scene templates · recipe sharing · personalization gap · trigger-action programming