Building the Product

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

A starting point

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

Hand-picked from around the web, each with a note on why it earns your time.

3 resources 3 link-checked Watch Read Use

Watch

▶️ Video

✓ Link checked Free Intermediate

Why we picked it Two Google UX researchers who did fieldwork across India and other emerging markets walk through what actually trips up new internet users: low literacy, English-only interfaces, and phones that were never built for your app. It is grounded in real observation rather than opinion, which is rare for this topic. Treat it as a lens on your own users, then go watch how people in your target city actually hold and use their phone.

Designing for the Next Billion Users (Google I/O '17)

On YouTube (Google for Developers) by Astrid Weber and Nithya Sambasivan, Google ~38 min

Literacy and language are first-class design constraints: voice, icons, and visual cues often beat text for users who do not read English comfortably.
Real users share devices, run low on storage, and stretch data, so onboarding and account patterns built for a single always-connected owner will fail.
Watching people use products in their own context surfaces problems no amount of desk research will, so pair this talk with your own field visits.

Watch on YouTube youtube.com →

Read

📄 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 →

Use

🛠️ 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 →