The Design Default Problem
Most UX patterns are designed assuming reliable, fast internet. Skeleton screens, real-time updates, lazy-loading images — these are patterns that solve problems for users in environments where a 4G connection is the baseline.
Designing for Nigeria — or any market where connectivity is intermittent and expensive — requires challenging every default assumption.
Key Patterns
Offline-First Architecture
The core mental model shift: assume the user is offline. Build for offline as the default state, and treat connectivity as an enhancement.
This means local storage (IndexedDB for web, SQLite for native) is the source of truth for the UI. The server is the source of truth for data, but the UI never waits for the server to function.
Explicit Sync Status
Users in low-connectivity environments need to know the state of their data. Is this saved locally? Has it been sent to the server? Did the server confirm receipt?
Use explicit, honest sync indicators. Not a spinner (which implies in-progress), but a status label: "Saved locally — will sync when connected."
Progressive Image Loading
Images are the largest bandwidth consumers in most applications. Techniques: serve WebP, use responsive image sizes, blur-up loading (tiny placeholder → full resolution), and lazy loading for off-screen images.
For very low bandwidth: provide a "lite mode" toggle that disables images entirely.
Chunked Data Loading
Instead of loading an entire dataset on page load, paginate aggressively. Load 20 records, not 200. Prefetch the next page in the background when the user is connected.
Meaningful Error States
"No internet connection" is not a helpful error message. "You're offline. Your last 3 actions have been saved and will sync when you reconnect." is useful.
Design error states that tell the user what happened, what has been preserved, and what to do next.
Bandwidth-Aware Media
Detect connection quality (Network Information API) and serve appropriate content. A user on 2G gets compressed images and deferred video autoplay. A user on WiFi gets full-resolution assets.
What This Means for Government Apps
Government applications — field inspection apps, rural healthcare records, agricultural data collection — are often used in exactly the environments where connectivity is worst.
Every government mobile application we build is offline-capable by default. The offline capability is not a feature. It is a baseline requirement.
