Layered status display is the precondition for diagnosis

What it is

For users to attribute a fault to the device, network, or rule layer, each layer needs an independent, simultaneously viewable status. That is layered status display: put the three layers into one view, not three apps and three menus. It is not "show more information" — the information already exists — but organise existing information by layer so that elimination can run.

Without it, the preceding knowledge is unusable: users may know faults can sit in any layer and even hold observation points for each, but scattered entry points turn "eliminate layer by layer" into a memory relay across apps — most give up halfway. Layered display cuts the cognitive cost from "remember and compare" to "look".

Why it happens

Layer attribution is a mental operation of sequential elimination: check the device layer first; if healthy, the network; if healthy, the rules. This operation imposes two requirements on the interface, both mandatory:

Each layer needs an independent status expression. Independence is the logical basis of elimination — if two layers share one vague red dot reading "device abnormal", elimination cannot proceed; one can only say "broken", not "which layer". Device-level presence and responsiveness, network-level connectivity and latency, rule-level last trigger and matched condition: each needs a readable value.

The three layers must coexist on one screen. Elimination is a cross-layer comparison, and working memory holds only two or three compared items at a time. With status scattered across entry points, users must switch between apps while holding earlier states in memory — precisely the load pattern under which working memory collapses. One screen is not an aesthetic preference; it moves the comparison cost from memory to perception.

A secondary gain: cross-layer faults become inferable. A device going offline frequently and a rule firing at high rates are each unremarkable in isolation (both within normal range); overlaid on one timeline, the causal chain "the rule drained the battery" becomes visible — something no single-layer view can ever show.

Studying it

• Usability evaluations of layered views: under fault injection, give participants the same faults with two interfaces (layered single screen vs. scattered entry points), measuring correct-layer localisation rate, time, switch counts, and subjective load (NASA-TLX-style instruments). Think-aloud protocols additionally capture whether elimination really proceeds layer by layer.
• Field studies of status pages: research on operations dashboards in systems administration indicates that the value of a status display lies not in information volume but in anomaly scannability — the normal-aggregated, anomaly-expanded organisation significantly speeds detection; the domestic setting tightens that constraint a further notch (users are non-professionals with lower tolerance).
• Log studies: after deployment, collect when users actually open the health view (at faults vs. on patrol), calibrating the timing design of "collapsed by default, expanded on anomaly".

One methodological caution: in lab injections, participants know "there is definitely a fault" and scan with full attention; in real homes, users must first suspect a problem before looking at a status page — how strong a symptom must be to trigger suspicion is a precondition the lab cannot measure, and needs in-the-wild data.

Where it stops holding

• Collapsed by default, expanded on fault. An always-open health panel is background noise that trains users to ignore it; the correct form is silent — occupying no attention while everything is normal, expanding to the layer when any layer goes abnormal or the user asks.
• Layers must hang under the user's question, not the other way round. The user's mental entry point is "what's wrong with the living-room light", not "the rule layer". Organise from device or scene downward into layers; making layers the top-level menu is an operations-centred misplacement.
• The three-layer cut flexes with the ecosystem. Add cloud-executed rules or voice entry points and the cloud layer needs separate presentation — "everything local is fine but the cloud is down" is a real and common fault shape the three-layer view cannot hold.

Applying it

• Fix every device detail page at three sections: device status (online, battery, signal), link status (gateway connectivity, recent offline record), participating rules (each rule's last trigger time and matched condition) — completing the three-layer presentation from the user's question (this device).
• Provide a cross-layer timeline: offline events, rule firings, and manual actions overlaid on one axis, so "high-frequency firing first, device offline afterwards" reads as a causal story.
• Alert per layer with distinct vocabulary ("device offline" ≠ "cannot reach gateway" ≠ "rule did not fire"); never cover all layers with a single "abnormal".
• How to check: inject one fault per layer, measure time from opening the view to correctly naming the layer, plus error rate; then use eye-tracking or click data from normal periods to confirm the default view steals no attention. Both measures together decide whether the layered display works.

Related

• Same group: Z7.02.1 A fault may sit in the device, network, or rule layer · Z7.02.2 Users lack the tools to localise faults
• Nearby: Z7.01 Making system behaviour explainable · Z4.02 State desynchronisation
• Search terms: layered status display · health dashboard · fault localization · situation awareness