Templates lower the barrier but cap expressiveness
Aliases: wizard-based creation · recipes · rule templates
What it is
The mainstream product answer to the conditional-rule barrier is the template (or recipe): a prebuilt rule skeleton such as "turn on such-and-such light at sunset", where the user fills in a few blanks — which light, what time. Templates turn "writing a rule" into "filling a form", and the barrier collapses. They simultaneously set a ceiling on expressiveness: the automations users can build are confined to shapes the template author anticipated.
This is a deliberate trade: accessibility widened in exchange for a narrowed expressive range. The problem is that the terms of the trade are written nowhere, so users do not know what they have been confined to.
Why it happens
Templates lower the barrier by transferring design decisions. Boolean structure, the event/state distinction, quantifiers over trigger conditions, debounce and active hours — the template author settles these in advance, and the user operates only at the parameter level (which light, what time). The difficulties do not vanish; they move from the user's side to the author's.
The capped expressiveness is the same coin's other face: template space is a projection of the author's imagination. The parts of real user intent that fall outside the template shape — "set the AC three degrees below outdoor temperature but never above twenty-six", "don't notify me when someone else is home" — have nowhere to go: users abandon the want, or assemble an approximate template and live with its drift.
A slower consequence follows: templates shape wants. Users "pick" from a list rather than "express" a need. Automations absent from the list never enter the user's imagination of the system, and long-term use converges expectations of "what this system can do" onto the boundary of the template library — a limit on expression eventually becomes a limit on imagination.
Studying it
End-user programming research yields a robust comparative finding: wizard- and template-based construction achieves markedly higher correctness than free construction, but expresses markedly fewer intent categories; in field studies and surveys of trigger-action programming, automations that users want but the chosen platform's templates cannot cover are a steady source of abandonment and dissatisfaction.
Standard methods: have the same users express a standardised set of intents through templates and through free construction, comparing accuracy, completion time, and the share of "cannot express"; then follow real households for months with diaries or interviews, watching whether the surviving distribution of rule types converges.
One methodological caution: lab studies underestimate "cannot express" — participants receive intents chosen by the experimenter, typically ones the templates happen to fit. The long tail of real wants only surfaces in open-ended elicitation ("what else would you like your home to do by itself?").
Where it stops holding
- Templates are the right tool for high-frequency common needs. Lights on and off, schedules, leaving home — these dominate everyday automation and cost the template nothing. The loss concentrates in the tail; evaluate how much tail is cut, not the mean correctness.
- A hybrid of "templates + custom" is not free. Keeping both paths stacks two mental models on the user: when to look for a template and when to open the editor is itself a new judgement burden.
- The ceiling eases as the library grows, but never lifts. Adding templates runs into retrieval cost — not finding the one you want among a thousand differs little, experientially, from it not existing.
Applying it
- Make templates a starting point, not a destination: every template can be "unpacked" into a fully editable rule, so users start from a near miss and bend it to their shape, instead of choosing between fill-in-the-blanks and programming.
- Organise the library by life tasks (waking, leaving, caregiving, saving energy), not by device type — users arrive with a task, not a device model.
- Put an explicit exit at the end of the list: "Didn't find it? Start from a blank rule." A dead end teaches "this is all the system can do".
- How to check: track the unpack and re-edit rate within seven days of template creation (are templates used as starting points?); track the share of users who browse the library and leave without creating anything (is the ceiling intercepting wants?).