Your app needs to work on bad internet.

Design · 5 min read

During our first video call, the client's internet dropped three times. He was on a mine site in Western Australia. The connection would hold for five minutes, cut out, come back, cut out again. He apologised every time. But the thing is, he wasn't the problem. His internet was. And this was the person we were building the app for.

He needed the app for study and professional development. Modules, quizzes, progress tracking. If the app required a constant internet connection to function, it would be useless to him on site. He'd have to wait until he was back home, on his week off, to use it. That's not an app. That's a website with extra steps.

And he's not a special case. This is a real constraint for a significant portion of Australian users.

Australia has a connectivity problem

We build apps in cities with fast broadband and 5G. But the people using those apps aren't always in cities. They're on construction sites in the outer suburbs where the signal drops behind the concrete. They're in regional towns where the NBN is patchy at best. They're in hospital basements doing shift handovers. They're in rural clinics where a video call is a luxury.

Google's design research found that nearly a third of the world's internet users deal with unreliable connections. In Australia, that number is concentrated in the places where trades, mining, agriculture, and healthcare actually happen. The people doing the hardest work in the most remote locations are the ones with the worst internet. If your app assumes a perfect connection, it will fail the people who need it most.

This isn't a niche concern you can address in version two. It's a core design decision that affects every screen, every interaction, and every piece of data your app handles.

Designing for the dropout

The worst thing an app can do when the internet drops is lose the user's work. They've been filling out a form for ten minutes, the signal goes, and everything disappears. That's not just frustrating. It's the moment they delete the app and go back to paper.

Good offline design means caching data locally so users can keep working. It means saving form progress automatically, even before the submit button is pressed. It means showing users clearly which features work offline and which need a connection. No silent failures. No spinning loading screens that never resolve. Just honest communication about what's happening.

For the education app, we designed it so that modules could be downloaded in advance. When the client was on Wi-Fi at home, he'd download the next set of study materials. On site, he could work through them without any connection at all. His progress would sync automatically the next time he had a signal. He never lost work. He never waited for a loading screen.

Questions to ask before you build

Where will your users actually use this app? Not where you hope they'll use it, but where they'll really be. On a train through a tunnel? In a warehouse with concrete walls? In a paddock with one bar of signal? If the answer is anywhere other than a desk with fibre broadband, you need to think about connectivity.

Ask your developer what happens when the connection drops mid-action. What happens to unsaved data? What does the user see? Does the app retry automatically or does it just fail? These are questions that should have answers before development starts, not after the first complaint rolls in from a user in Kalgoorlie.

You don't need to build a fully offline app. But you need to design for graceful degradation. That means the app gets worse gradually, not catastrophically. Some features need a connection. That's fine. Just don't make the entire app useless the moment the signal drops.

Sources
Designing for Connectivity (Google Design) - Nearly one third of internet users worldwide deal with unreliable connections. Apps should design for offline-first or graceful degradation.

Related blog posts:

Designing for the person who can't read your app →

The default matters more than the option →

Your app should know more than your user →