How to design useful technology for low connectivity

Every African phone user knows the "signal dance." Hold the phone up. Walk to the window. Stand on a chair. Turn slightly left. Watch the little bars appear and disappear. Wait for the page to load… wait… wait… "No internet connection."

Now imagine you're trying to check your child's exam results, pay a bill, get health information or send money to your mother — and the app you need was designed for someone in a city with fast Wi-Fi and unlimited data.

That's the reality for millions of people. Much of the world's technology is designed for perfect conditions. Much of Africa lives in imperfect ones.

How can designers and developers build technology that's actually useful for people with slow, expensive or unreliable internet?

The connectivity reality

• ITU estimates that only around 36–38% of people in Africa use the internet.
• The GSMA's research highlights a big "usage gap": many people live in areas covered by mobile broadband but still don't use it — because of the cost of devices and data, lack of digital skills, or lack of relevant content.
• The Alliance for Affordable Internet (A4AI) sets an affordability target of 1GB of mobile data costing no more than 2% of average monthly income. In many African countries, data still costs more than that.
• Electricity is also a challenge. The IEA estimates that hundreds of millions of people in Sub-Saharan Africa lack access to electricity — which means charging phones is itself a daily task.

About 36–38% of people in Africa use the internet. (ITU, Facts and Figures 2024–2025) Designing only for fast, always-on internet leaves most of the continent out.

Lesson 1: Design for the phone people actually have

Many users in Africa have entry-level Android smartphones with limited storage and memory — or basic "feature phones." Design choices should reflect that:

• Keep app size small. Users often delete apps to free storage.
• Make it work on older Android versions.
• Avoid heavy animations that slow cheap phones.
• Test on real low-cost devices, not just the latest iPhone.

Facebook Lite, launched in 2015, was designed for slow networks and basic Android phones. Its small size helped it become hugely popular in emerging markets. Other companies followed with "Lite" versions of their apps.

Joke break: A developer proudly launched a 300MB app for farmers. One farmer said, "To install your app, I would have to delete my photos, my music, my WhatsApp and possibly my wife's contact." The developer made a 15MB version.

Lesson 2: Offline-first, not offline-never

"Offline-first" means an app works without internet and syncs when a connection is available. This is essential where connections come and go.

Examples of offline-first thinking:

• Save forms locally and send them later.
• Download content (lessons, maps, health guides) once, use it many times.
• Show saved information even when offline.
• Queue messages and payments to send when connected.

Kolibri, an open-source learning platform developed by Learning Equality, lets schools use educational content without internet, by sharing it over a local network from one device. It has been used in many countries, including in Africa.

Lesson 3: Don't forget USSD and SMS

Not everyone needs an app. USSD (those codes like *123#) and SMS work on any mobile phone, without internet.

M-Pesa, launched in Kenya in 2007, became famous partly because it worked on basic phones using simple menus. Today, many mobile money services, farmer information systems, health reminders and banking services across Africa still use USSD and SMS.

When to use USSD/SMS:

• Your users have basic phones.
• The service is simple (check balance, send money, get prices, receive reminders).
• You need very wide reach.

Limitations: short text, limited menus, session timeouts, and costs for operators. But reach beats beauty.

Lesson 4: Every kilobyte costs money

For many users, data isn't just slow — it's expensive. Every image, video and auto-play feature costs them money.

Design tips:

• Compress images and use modern formats.
• Don't auto-play videos.
• Let users choose "data saver" mode.
• Show file sizes before download ("This video is 12MB").
• Cache content so users don't download it twice.
• Use text where text is enough.

Google's research on mobile web performance found that more than half of mobile visits are abandoned if a page takes longer than three seconds to load. On a slow connection, a heavy page may never load at all.

"Simplicity is the ultimate sophistication." — often attributed to Leonardo da Vinci

Lesson 5: Design for shared phones

In many families, one phone is shared by several people. Design should consider:

• Multiple user profiles or easy logout.
• Privacy (hide sensitive information behind a PIN).
• Not assuming "one phone = one person."

This matters especially for women and young people, who may use a relative's phone. GSMA's Mobile Gender Gap reports show women in low- and middle-income countries are less likely than men to own a mobile phone or use mobile internet.

Lesson 6: Local language and voice

Text-heavy apps in English or French exclude people who read less comfortably in those languages. Solutions:

• Offer local language options.
• Use icons and images.
• Use voice: audio messages, voice menus (IVR), and read-aloud features.
• Test wording with real users.

Voice notes on WhatsApp are hugely popular across Africa partly because they don't require typing or reading. Designers can learn from this behaviour. See The role of local languages in health communication.

Lesson 7: Handle errors kindly

When connections fail, apps often show confusing error messages or lose everything the user typed. Good design:

• Saves progress automatically.
• Explains clearly: "No connection. Your form is saved and will be sent when you're back online."
• Retries automatically.
• Never punishes users for bad network.

Lesson 8: Test in real conditions

Designers in offices with fast Wi-Fi often don't experience what users do. Solutions:

• Test on low-cost phones.
• Use network throttling tools to simulate 2G/3G.
• Go to the field: test in villages, markets and on moving buses.
• Watch real users, not just ask them. See How to test a tech idea with the people who need it.

Real examples that work

• M-Pesa (Kenya): mobile money on basic phones via USSD and SMS.
• Ushahidi (Kenya, 2008): a crisis-mapping platform that accepted reports by SMS, web and email, created during post-election violence and later used worldwide.
• Kolibri (Learning Equality): offline learning platform.
• Farmer information services in several countries send weather and price updates by SMS.
• Offline maps apps (like Google Maps offline areas or OpenStreetMap-based apps): download once, navigate without data.

These examples share one trait: they started from users' real conditions, not from the designer's ideal world.

What about AI and big technologies?

New technologies like AI often require powerful servers and fast internet. That can widen the digital divide. But there are approaches that help:

• Smaller AI models that run on phones.
• Services that work through SMS or voice.
• Local language AI (projects like Masakhane and Lelapa AI work on African languages).

We explore this in How AI Is Changing Africa: Promise, Risks and the People Building It.

An illustrative redesign: the school results app

Imagine a ministry launches an app so parents can check exam results. Version 1 is a 90MB app with a login, a big animated banner and a results page that loads photos of every school. On results day, the servers crash, parents in rural areas can't download it, and many give up.

Version 2 (illustrative redesign):

• A USSD code: dial, enter the candidate number, receive the result by SMS.
• A light web page (under 100KB) that works on any browser.
• An optional app for extra features, under 10MB.
• Results cached so repeat checks don't use extra data.
• Messages in French and major local languages.

Same information. Far more people served. That's the power of designing for real conditions first.

Power matters as much as data

Connectivity isn't only about signal. It's also about battery. When electricity is unreliable, people ration their phone battery carefully.

Design tips for low-power conditions:

• Avoid constant background activity (location tracking, auto-sync every minute).
• Offer a dark mode, which can save battery on some screens.
• Let users control notifications.
• Make key tasks quick so users don't keep the screen on for long.

A user who has to choose between charging their phone and cooking dinner will delete a battery-hungry app without hesitation.

Design principles in one sentence each

• Small: keep apps and pages light.
• Offline: work without internet, sync later.
• Simple: fewer steps, clearer words.
• Cheap: respect users' data costs.
• Inclusive: shared phones, local languages, voice.
• Kind: save work, explain errors.
• Real: test in real conditions with real people.

Why this is good business

Designing for low connectivity isn't charity. It's how you reach the majority of the African market. Businesses that design for the real conditions of users reach more customers, keep them longer and build trust. See Digital tools that help small businesses stay organised.

It also makes technology better for everyone. Fast, light, simple apps are good even in cities with great Wi-Fi.

Design for the signal dance

The next time you design an app, website or service, imagine a user doing the signal dance — phone raised, waiting. Design for them. If it works for them, it will work for almost everyone.

Keep reading: From a classroom robot to a local solution, Why repair skills matter for Africa's tech future, and our Technology & Innovation section.

Questions

What is offline-first design?

An approach where apps work without internet by storing data locally and syncing when a connection becomes available.

Why is USSD still important in Africa?

USSD works on any mobile phone without internet, so services like mobile money can reach people with basic phones.

How can I make my website faster for African users?

Compress images, avoid auto-play video, reduce page size, cache content and test on slow networks and low-cost phones.