Building education platforms for low-connectivity regions

Design for the device your learners actually have

Educational software is usually built on fast laptops connected to office broadband, then used on shared, low-cost Android phones with limited data plans and patchy mobile coverage. Many students also share one device within a family, use it in short bursts, and switch off mobile data to save money.

Those conditions should shape the product from the first design, not be patched in afterwards. Every heavy image, large script bundle or auto-playing video costs a learner both time and money before they have learned anything.

Set a page-weight budget

A budget turns a vague intention to be fast into a rule the team can check. Decide on a maximum total transfer size for key pages, and treat going over it as a bug.

Techniques that usually give the biggest savings:

• Serve images in modern formats such as WebP or AVIF, resized to the size they are actually displayed at.
• Lazy-load images and media below the fold so they only download when needed.
• Avoid shipping a large JavaScript framework for pages that are mostly text and a few form inputs; server-rendered HTML is often faster and more robust.
• Use system fonts, or limit custom web fonts to one family and a couple of weights.
• Enable compression and long cache lifetimes for static files so repeat visits cost almost nothing.

Make text and core actions work first

A lesson that cannot be read until a video has buffered is not a lesson on a 2G connection. Put the essential content, meaning the explanation, the question and the answer box, in the initial HTML, and treat illustrations, animations and video as enhancements that load afterwards.

Practical checks: can a learner read the explanation and submit an answer with images disabled? Does the page still make sense if a script fails to load? If the answer is no, the most important path depends on the least reliable resources.

Never lose a learner's work

Nothing discourages a student faster than finishing ten questions and losing them because the connection dropped at the moment of submission. Learning products should be tolerant of interrupted networks:

• Save answers locally in the browser as the learner works, and send them to the server when a connection is available.
• Make submissions safe to retry, so that sending the same answer twice does not double-count it.
• Show clear, calm status messages such as 'saved on this device, will sync when online' instead of generic errors.
• Consider a service worker to cache lesson pages a learner has already opened, so revisiting them works offline.

Keep learning loops simple

Slow networks magnify every unnecessary step. A loop of read, attempt, get feedback, and continue should take as few page loads as possible. Fewer screens also help learners who are new to using phones for study, and teachers who need to explain the product quickly in a classroom.

Progress indicators should follow the same rule: a few clear signals tied to what the learner needs to do next, rather than charts that are expensive to load and hard to interpret on a small screen.

Test under realistic conditions

Browser developer tools can throttle network speed and CPU to simulate slower devices. Use them routinely, not only before launch, and test key pages with a cold cache as a first-time visitor would see them.

Better still, keep an inexpensive Android phone in the team and use the product on a mobile data connection regularly. Problems that are invisible on office Wi-Fi become obvious within minutes. This matches the approach behind our own products, including EasyTough: if it is not usable in the conditions learners actually face, it does not matter how good it looks in a demo.