The scope of degraded-mode capabilities must be communicated in advance

What it is

When a device or system enters a degraded mode — the reduced feature set that survives losing the cloud or the network — users need to know, before it happens or at the moment it does, which functions still work and which do not. This is the communication side of graceful degradation: which functions the architecture keeps locally is a design decision; whether users know that list is a separate matter, and it independently decides how the degradation feels.

This card is about expectation management, not architecture. How functions are engineered to work locally, and whether degraded behaviour stays consistent across incidents, belong to the losing-the-network group; here only one thing is claimed: the scope must be stated in advance.

Why it happens

The damage comes from an expectation gap. The user's model of the system is built on full mode — remote viewing works, automations fire, alerts go out. When degradation hits, every action inside the gap between expectation and actual capability fails. The more dangerous form is a false sense of security: the user believes the camera is still recording and alerts still pushing, while the degraded device offers nothing but a local blinking LED. Security decisions made on assumed capabilities are worse than plain unavailability.

Advance disclosure works because it converts the gap from "exposed at failure time" to "discounted in advance": users can arrange substitutes — a spare key, a mechanical timer, simply being watchful. Explaining afterwards can only limit damage; it cannot buy back the window of action that was missed. Degradation windows also correlate with external events (the storm that takes out the network is exactly when security matters most), moments at which users have no attention to spare for learning what the system can still do — which multiplies the value of having said it earlier.

Where it stops holding

• "In advance" does not mean "in the manual". Nobody digs out documentation for one outage; install-and-forget is the norm. Effective disclosure is lightweight, situational, and passively visible: a standing note on the device detail page, a one-time checklist at installation — both beat a long document.
• The degraded scope evolves with firmware. Static documents inevitably rot; a capability list generated dynamically from the installed firmware version is more reliable than print.
• Partial degradation resists enumeration. When one class of cloud endpoints is down, "works / doesn't" is not a clean split; an honest "unknown" beats a list pretending to be complete.

Applying it

• At installation completion, show a one-time list of "what still works offline", phrased from the user's side ("with the network down, the key still opens the door, the local siren still sounds, no notifications will be pushed") — no technical vocabulary.
• Keep a standing degraded-capability note on each device's detail page, versioned with firmware.
• The notification at the moment of degradation carries two columns: "not available right now" and "still working" — the second matters more, because it answers the user's most urgent question.
• For safety-critical devices (locks, smoke, security), print the degraded behaviour on the device or next to it — not in the app, which may itself be among what is unavailable.
• How to check: ask a random sample of users "what can your lock / camera still do when the network is down"; the hit rate is the true effect of the disclosure. Accept the hit rate — not "a document exists" — as the criterion.

Related

• Same group: Z4.09.1 A disconnected device must be flagged, not silently left showing its last state · Z4.09.2 Faults must be attributed across device, network, and cloud · Z4.09.4 After recovery, state must be confirmed, not assumed restored
• Nearby: Z4.03 Losing the network and degrading · Z4.10.3 The directness of physical switches makes them the reliable fallback in failures
• Search terms: graceful degradation · degraded mode · expectation management · false sense of security