Describe what is still available
A hypothetical event guide might keep previously viewed information available while offline. That can be helpful, but an old schedule should not appear indistinguishable from a recently updated one. Show the time or state of the information when it affects a decision.
Offline behavior needs an intentional boundary. Some content may be readable while changes or sensitive actions require a connection. Explain that boundary where it becomes relevant.
Separate a local change from a saved change
Text visible in an editor may exist only on the device. A “Saved” label can be misleading if the change has not reached the intended destination. An interface should distinguish unsaved, saved locally, waiting to send, and received states when those differences matter.
The language does not need to expose technical details. It needs to help a person decide whether it is safe to close the screen or whether another step is required.
Treat retrying as a real action
Repeatedly pressing a button can create duplicate requests if the system cannot tell that the first one succeeded. An early exploration should consider what the user sees during the wait, whether retrying is appropriate, and how a duplicate would be recognized.
Likewise, two devices may hold different edits when they reconnect. A plan for that situation should say whether one version wins or whether a person needs to compare them.
Test the awkward moments
A demonstration can be examined with a connection interrupted at different points in a task. Observe what remains visible, what can be recovered, and whether the status language still makes sense. Use invented data and a safe test setup.
These examples outline questions worth exploring. They do not describe a production system, resilience test, or completed company project.