How do I design for users in India who are on cheap Android phones and slow, patchy internet?

The short answer

Design for the phone your user actually holds, not the one on your desk. That means tiny app size, screens that survive a dropped connection, offline-first where you can, and no reliance on expensive fonts or heavy images. As a starting point, test on a budget Android device on 3G with data saver on, because that's the real experience for most of the market outside the big startup hubs.

Go deeper, your way

19 hand-picked resources, 16 link-checked. Pick how you want to dig in.

Watch a video 3 Listen to a podcast 1 Read an article 11 Use a tool 4

▶️ Video

✓ Link checked Free Intermediate

Why we picked it A grounding talk on who these users are and the constraints they live with: expensive prepaid data, shared and low cost devices, and networks that drop. It reframes the problem from a technical checklist into an understanding of real lives, which is what stops you designing for yourself by accident. A good first watch before you touch a single screen.

Building for Your Next Billion Users (Google I/O 2017)

On Google Developers on YouTube by Google 40 min

Data cost shapes behavior as much as speed does
Many devices are shared, older, and low on storage
Empathy for the constraint comes before any optimization technique

Watch on YouTube youtube.com →

▶️ Video

✓ Link checked India Free Intermediate

Why we picked it Most localization advice is written for German and Finnish, this session grounds it in India instead: the team that built Tez (now Google Pay India), Files Go, and Datally talks through designing for users who switch languages, may not read fluently, and are on shared low end devices. It is honest about what actually failed in the field, not a polished case study. Good for seeing why voice, icons, and vernacular defaults matter before English does.

Challenges and learnings of building for the next billion users (Google I/O '18)

On Google I/O (YouTube) by Google (Next Billion Users team: Nithya Sambasivan, Josh Woodward and colleagues) About 40 minutes

Designing in the user's primary language first, then adapting to English, is the opposite of how most teams build, and it changes onboarding, trust, and layout decisions.
Many users share a device and switch languages between people and sessions, so a hardcoded single language setting quietly excludes half the household.
Voice, familiar imagery, and offline friendly patterns often carry more of the interface than text does for users who are not fluent readers in any script.

Watch on YouTube youtube.com →

▶️ Video

✓ Link checked Free Intermediate

Why we picked it A talk (with writeup) on serving a genuinely different, lighter experience to low end devices and slow networks, drawing on how Facebook and others do it in practice. It pushes past image tricks into loading fewer features and lighter components when the device is weak. Watch it when you are ready to design tiers of experience rather than one page for everyone.

Adaptive loading: improving web performance on slow devices

On web.dev (Chrome Dev Summit talk writeup) by Nate Schloss and Addy Osmani 25 min talk

Adapt the whole experience, not just image quality, to the device
Weak devices can get fewer, lighter components on purpose
Detecting device and network capability is now practical in the browser

Open web.dev →

🎧 Podcast

✓ Link checked Free Beginner

Why we picked it A conversational episode with a Google advocate on low bandwidth design and data cost, good for absorbing the mindset while commuting. It connects the designer and developer sides of the problem, which is exactly where cheap phone products succeed or fail. A gentle entry point if the technical essays feel heavy.

Sam Dutton on designing for the next billion users

On Designer vs Developer (Google) by Google 30 min

Designers and engineers have to solve the constraint together
Data cost belongs in early design decisions, not late optimization
Small, considered choices compound into a usable low bandwidth product

Open developers.google.com →

✍️ Essay

✓ Link checked Free Advanced

Why we picked it Alex Russell, a Chrome engineer, puts hard numbers on what most of the world's phones can actually do, and the gap between them and the laptop on your desk is brutal. He picks a specific budget Android device and a slow network as the baseline you should build to, then shows how much JavaScript and page weight that budget really leaves you. If you only read one thing to recalibrate your sense of what is fast, read this.

The Performance Inequality Gap, 2024

From Infrequently Noted (Alex Russell) by Alex Russell Long read

A quarter of your users are on devices slower than the baseline you should target
Set an explicit byte and CPU budget per screen, then hold the line
The fastest device in the room is a terrible proxy for your real user

Open infrequently.org →

📄 Article

✓ Link checked India Free Intermediate

Why we picked it Flipkart serves exactly your users, many on 2G in smaller Indian cities, and this case study shows a fast mobile web app tripling time on site versus their old mobile experience. It is proof that a light web page can win in low bandwidth conditions where a heavy native app struggles. Useful data to counter the reflex that real products need an app.

Flipkart triples time-on-site with a Progressive Web App

From web.dev (Google)

63% of users arrived over 2G, so speed mattered most
The fast web app tripled time on site
Add to home screen gave app like access with no install

Open web.dev →

📄 Article

✓ Link checked Free Intermediate

Why we picked it A small download is the first thing a data conscious user notices, and the official guide is the practical how to: app bundles, R8 shrinking, WebP images, vector drawables, and stripping unused resources. Each technique is a real megabyte off your install size. Work through it once and your app becomes a lighter, easier yes for someone counting their data.

Reduce your app size

From Android Developers by Android Developers Reference

Publish an Android App Bundle so users download only what their device needs
Convert images to WebP and use vector drawables to cut resource weight
Run R8 and remove unused resources to shrink the code itself

Open developer.android.com →

📄 Article

✓ Link checked Free Intermediate

Why we picked it This is the developer side of the entry level phone: an OS tuned for 4GB RAM and under, with guidance on optimizing your app to run smoothly there. If a real slice of your users are on Go edition or similar low RAM devices, this tells you the hardware limits you are actually designing against. Pair it with the app size guide for a full low end checklist.

Android (Go edition) and Build for Billions

From Android Developers by Android Developers Guide hub

Know the RAM and storage floor your real users live on
Test on a low RAM device, not just an emulator on a fast machine
Optimize startup and memory so the app does not get killed in the background

Open developer.android.com →

📄 Article

✓ Link checked Free Beginner

Why we picked it Facebook made its engineers spend an hour every Tuesday on a simulated 2G connection so they would feel what most of their users feel. The lesson is simple and worth stealing: you cannot design for a slow network you never experience. Read it, then make throttled testing a habit on your own team.

Building for emerging markets: the story behind 2G Tuesdays

From Engineering at Meta by Meta Engineering Short read

You build better when you regularly use your product on a bad connection
On 2G a single page can take a minute or more to load
Make slow network testing a routine, not a one off before launch

Open engineering.fb.com →

📄 Article

✓ Link checked Free Advanced

Why we picked it Instead of shipping the same heavy page to everyone, you can detect the connection and serve lighter images or defer non essential loads on slow links. This guide shows how using the effective connection type signal, with code. It is the practical route to one product that behaves well on both a fast and a 2G phone.

Adaptive serving based on network quality

From web.dev (Google) by Google Chrome team 15 min read

Detect slow-2g, 2g, 3g, or 4g and adapt what you send
Serve low resolution media and defer big downloads on weak links
React when the connection changes rather than deciding once at load

Open web.dev →

📄 Article

✓ Link checked Free Advanced

Why we picked it A focused, code first companion on reading the user's connection (and even their data saver preference) and adjusting what you load. Osmani keeps it concrete: swap a video for an image, skip a preload, respect someone who has asked to save data. Handy when you want the exact API and a working pattern rather than the concept.

Adaptive Serving using JavaScript and the Network Information API

From AddyOsmani.com by Addy Osmani 12 min read

Respect the user's explicit data saver preference when it is set
Downgrade heavy media gracefully instead of blocking the page
Adaptive loading keeps one codebase working across network conditions

Open addyosmani.com →

📄 Article

✓ Link checked Free Beginner

Why we picked it This is Google's own field research on building for people coming online in markets like India, and it names the exact constraints you are up against: a 40 to 60 dollar phone with 512MB of RAM, a network that flips between 3G, 2G and nothing, and 250MB of prepaid data for the whole month. It is the clearest single primer on why a metro-built app breaks for a first-time user, and it stays concrete instead of preaching. Read it as a starting point for how you scope features, not as a checklist to blindly copy.

Connectivity, Culture, and Credit: Designing for the Next Billion Users

From Google Design by Google Design (Next Billion Users team) ~12 min read

Assume slow or intermittent connectivity as the default state, not the exception: design offline-first and let the app degrade gracefully when the network drops.
Data is expensive and rationed, so every megabyte you ship (heavy images, autoplay, background sync) is a real cost the user notices.
Many users are new to touchscreens and English, so patterns you take for granted (swipe, hamburger menus, English CTAs) need rethinking for people building outside the big startup hubs.

Open design.google →

✍️ Essay

✓ Link checked India Free Intermediate

Why we picked it Before you optimize a byte, you need to know who you are building for, and Pai's India1, India2, India3 framing is the clearest map of the Indian market you will find. He explains the English tax and why the vernacular, low trust, price sensitive India2 user behaves so differently from the metro user founders usually resemble. This is the market context that makes the technical advice matter.

India2, English Tax and Building for the Next Billion Users

From SajithPai.com by Sajith Pai Long read

India is several distinct markets, and India2 is not a smaller India1
Language and trust barriers can matter more than raw speed
Design in the user's own language rather than translating English later

Open sajithpai.com →

📄 Article

Free Intermediate

Why we picked it Every kilobyte of JavaScript costs far more on a cheap phone than on your machine, because the phone has to download it and then grind through parsing it on a weak CPU. Osmani shows the 2 to 5x difference in parse time between a flagship and an average phone, and gives concrete ways to ship less. This is the case for keeping your app light, backed by measurements rather than opinion.

The Cost Of JavaScript

From Addy Osmani (Dev Channel, Medium) by Addy Osmani 20 min read

Download size and CPU parse time both punish low end devices twice over
Ship less code first, then defer and split what remains
Measure on a real budget phone, not on your dev machine

Open medium.com →

📄 Article

India Free Advanced

Why we picked it A first hand engineering account of why Flipkart, an app first Indian company, rebuilt the mobile web to reach users on weak networks and low end phones. It is candid about the constraints your users live with and the tradeoffs the team made. Read it when you want the practitioner view, not the case study gloss.

Building Flipkart Lite: A Progressive Web App

From Medium (Progressive Web Apps) by Aditya Punjani

An app first Indian company chose to reinvest in the web
Low end phones and weak networks drove the decision
Real tradeoffs from a team serving your exact users

Open medium.com →

🛠️ Tool

✓ Link checked Free Beginner

Why we picked it Images are the single biggest reason landing pages crawl on a slow 4G connection, and Squoosh fixes that in your browser with nothing to install. You drag in a photo, convert it to WebP, and watch the file size drop with a live before and after comparison, often from over a megabyte down to under 100 KB. Everything runs locally on your device, so nothing gets uploaded anywhere.

Squoosh

From Google Chrome Labs by Google Chrome Labs A few minutes per image

Convert hero and product images to WebP, it is usually 25 to 35 percent smaller than JPEG at the same quality.
Use the split-screen preview to push compression until you can just start to see quality loss, then back off one notch.
Resize the image to the size it is actually displayed at, a 4000px photo shown at 800px is pure wasted bandwidth.

Open squoosh.app →

🎓 Course

✓ Link checked Free Beginner

Why we picked it A free, structured course that takes you from the basics of why pages are slow through images, fonts, JavaScript, and lazy loading. It is the systematic option if the one off essays leave gaps you want filled in order. Good for a non specialist founder or a first engineer who needs a real foundation.

Learn Performance

From web.dev (Google) by Google Chrome team Multi module course

Images, fonts, and JavaScript are the usual weight offenders
Load what the first screen needs, defer the rest
A little structured learning beats a pile of scattered tips

Open web.dev →

🛠️ Tool

✓ Link checked Free Beginner

Why we picked it You cannot fix what you never feel, and most of us build on fast laptops and office wifi. This is the official doc for simulating Slow 3G and a low-tier mobile CPU right inside the browser you already have, so you can load your own site under the conditions your users actually face. Use it as a first cheap check before you ever get your hands on a real budget phone.

Throttling (Network and CPU) in Chrome DevTools

From Chrome for Developers by Chrome DevTools team, Google Reference doc, ~10 min to try

Set the Network panel to Slow 3G to feel your real load time and spot pages that stall or ship too much on a patchy connection.
Add CPU throttling (the calibrated low-tier mobile preset in recent Chrome) to catch janky scrolling and slow interactions a cheap Android chip would hit.
This is a fast approximation, not the real thing: it is a starting point, and testing on an actual low-end device on a real network is still worth doing before you ship.

Open developer.chrome.com →

🛠️ Tool

Freemium Intermediate

Why we picked it This runs your site on real devices from real locations at set connection speeds, including Slow 3G, so you get an honest picture rather than a guess from your fast office wifi. It shows exactly which bytes and requests are hurting your load, and lets you test a repeat visit to check your caching. The closest you get to your user's experience without flying to their city.