Most software is built in an office with fast Wi-Fi, on a new laptop, by someone with a full battery.
Then it is used on a three-year-old phone, in a matatu, on a data bundle that is about to run out. The button spins. The form submits and nothing happens. The person tries twice, gives up and goes back to doing it by hand.
The software was not broken. It was built for a place its users do not live in.
Offline is normal
It is tempting to treat a lost connection as an error, something to apologise for with a sad-face screen. For a great many people it is simply part of the day: a building with thick walls, a stretch of road between towns, a storeroom at the back of the shop.
When we built Matata, a tool for reporting damage after floods, earthquakes and other crises, this stopped being a matter of convenience. The moment someone most needs to send a report is often the moment the network is at its worst. So a report is saved on the phone first and sent when the signal returns, without the person having to think about it.
That one decision shaped everything else about the design.
What designing for a weak signal looks like
- Save first, send later. Nothing a person types should be lost because the network dropped.
- Keep pages light. Every extra megabyte is paid for by the user, in money and in waiting.
- Ask for less. A form with five fields gets completed. A form with twenty gets abandoned.
- Say what is happening. "Saved, will send when you are back online" is reassuring. A spinner is not.
- Work in the browser where you can, so nobody has to find storage space for another download.
Everybody benefits
Something built to work on a weak signal is fast on a strong one. Something that asks only for what it needs is easier for everyone to use. Designing for the hardest conditions does not hold a product back. It is what makes it feel good everywhere else.
It is about cost as much as signal
Even where the network is good, data is not free. Many people buy it in small bundles and keep track of what each app uses.
A page that loads several megabytes of pictures and animation is spending the visitor's money before it has told them anything. They notice. So do search engines: slow pages tend to rank lower, which means fewer people find you in the first place.
This is one reason we are careful about what goes into a business website. A page that loads quickly and says what it needs to is worth more than an impressive one that half its visitors give up on.
Payments are part of this too
The same thinking applies to how people pay. A customer on a weak connection should not have to load a heavy checkout page and type in card details.
A payment prompt sent straight to their phone, where they only enter their M-Pesa PIN, works on almost any signal. We explained how that works in our guide to M-Pesa integration.
You can read more about how Matata handles poor connectivity in the Matata case study.
Test it where it will be used, not where it was built.
Before you approve the next piece of software for your business, try it the way your customers or staff will. Switch to mobile data. Walk to the back of the building. Use the oldest phone in the office.
If it still works, it is ready.
