Offline-First UX: Network States, Queued Work, and Sync
A lost connection should not make a product look broken or leave someone wondering whether their work was saved. Offline-first UX treats connection changes, stale information, queued actions, and synchronization as normal states to design—not exceptional messages to add after the application is built.
The right behavior depends on what the product does. A field note can often be saved locally and synced later. A live inventory count or financial quote may need to show when its data was last refreshed. A payment request may need to stop and clearly explain that it was not submitted.
Decide what the user can do without a connection
Start by mapping important tasks and classifying their offline behavior:
- Available offline: the user can read a cached item or draft a change locally.
- Queued for later: the product can preserve an action and retry when connectivity returns.
- Read-only with stale data: the task is possible, but information may no longer be current.
- Unavailable until online: the action depends on a server or a real-time update and cannot be safely queued.
Be explicit about which category applies. Do not promise that “everything will sync” unless the product can preserve and reconcile every relevant action.
Make network state visible at the point of need
Use an unobtrusive but clear connection indicator, and show more context beside the action or content affected. For example, “Offline — your draft is saved on this device” is more useful than a generic red banner that only says “Connection error.”
For cached data, indicate its age when freshness matters: “Last updated 10:42 AM.” Users can then distinguish “I have no results” from “I am looking at an older snapshot.” When a background refresh completes, communicate the update without abruptly replacing content the person is reading.
Do not rely only on a browser network-status signal to decide whether a server request succeeded. A device can appear connected while a particular service is unreachable. The interface should reflect the actual result of the operation.
Explain queued work and synchronization
If a change is saved locally, say so. If it is waiting to sync, use a separate status such as “Saved on this device — waiting to sync.” When synchronization succeeds, confirm the transition. These labels help users understand the difference between a local draft and a change that is available across devices.
Show what will happen when the connection returns, and avoid sending the same non-idempotent action twice. If a submission result is unknown, check the server state before inviting a retry that could create a duplicate.
Conflicts need a recovery path. Preserve the user's version, identify what changed elsewhere, and let them compare or choose when automatic merging is unsafe. Silent last-write-wins behavior can erase work without giving the user a chance to respond.
Keep critical actions honest
Some actions should not be queued, especially when timing, authorization, or current server state changes their meaning. For a transfer or a reservation, do not show “Complete” merely because the user tapped while offline. Say the action was not submitted and tell them when it is safe to try again.
Web Push Notification UX: Permission, Timing, and Preferences
Test transitions, not only airplane mode
Test a weak or intermittent connection, a request that times out after reaching the server, reconnection during editing, a sync conflict, and a device restart with locally saved work. Confirm that status messages, retry controls, and assistive-technology announcements describe the same state as the actual data.
Google's offline UX guidance recommends telling users both the application's state and what they can still do. For related loading and failure patterns, see the empty-state and error UX guide.