designing for india's diversity
Most product teams in India design for Bangalore and hope it works in Bhilai. It does not. The phone is different, the language is different, the connectivity is different, and the mental model is different. If you have not tested your product on a Redmi phone over a 2G connection in a tier-3 city, you have not tested your product.
India is not one market. It is 28 states, 22 scheduled languages, six script families, 700 million internet users on a spectrum from fibre-connected Gurugram apartments to shared-phone villages in Chhattisgarh. The literacy rate in Kerala is 94%. In Andhra Pradesh, it is 66%. A product designer who treats “Indian users” as a single persona will fail in most of the country.
This is not an abstract problem. Meesho grew to 150 million users because it understood that its core user — a tier-2/3 reseller — could not type product searches in English. ShareChat built a vernacular content platform that reached 180 million monthly users by treating Hindi, Tamil, and Telugu not as translations but as distinct content cultures. Google Pay India redesigned its entire flow for users who had never used a digital payment app before — and now processes more UPI transactions than any other app.
The playbook that works in San Francisco does not transfer. Here is what actually works.
Your Figma mockup assumes a phone that does not exist
The median smartphone in India is not an iPhone 15. It is a Redmi or Realme with a 5.5-inch screen, 3-4GB of RAM, 32GB of storage (half of which is occupied by the OS and WhatsApp), running Android 11 or Android Go. The processor is a mid-range Snapdragon from three years ago.
This has direct design implications:
Screen size. A 5.5-inch screen at 720p gives you significantly less real estate than a 6.7-inch flagship at 1440p. Bottom sheets that look elegant on an iPhone become cramped. Floating action buttons compete with navigation bars. Hit targets that pass Figma review fail fat-finger tests on smaller screens.
Memory pressure. With 3GB RAM, the OS itself consumes 1.5GB. Your app gets maybe 300-400MB before the system kills background processes. Heavy animations, large image caches, and complex view hierarchies cause visible jank. Users on these devices experience your app differently — slower transitions, more blank screens, more “app not responding” dialogs.
Storage anxiety. When your phone has 4GB of free storage, every app competes for survival. Users in India routinely uninstall and reinstall apps based on what they need that week. If your app is 80MB, it will lose to the 15MB competitor. PhonePe keeps its APK under 30MB. There is a reason.
Network reality. Jio gave India cheap data, not fast data. Outside metros, the typical experience is 3-8 Mbps with frequent drops. Inside buildings in tier-2 cities, connectivity can drop to 2G speeds or vanish entirely. Your API call that takes 200ms in Bangalore takes 3 seconds in Raipur — if it completes at all.
Design review for a new feature. The PM is looking at the designer's Figma prototype on a large monitor.
Designer: “Here is the checkout flow. Three steps — cart summary, address confirmation, payment. Smooth transitions between each screen, the lottie animation plays while we confirm the order.”
PM: “What happens when this runs on a Redmi 9 over a patchy connection in Indore?”
Designer: “It should be fine. The transitions are lightweight.”
PM: “I tested the current version on a budget device last week. The cart screen takes 4 seconds to load product images. The lottie animation freezes mid-frame. And if the connection drops between step 2 and step 3, the user gets a white screen with no feedback. They do not know if their order went through.”
Designer: “We could add a loading state...”
PM: “We need more than a loading state. We need the entire flow to work offline once the user reaches the cart. Cache the product images when they browse. Store the address locally. Queue the payment confirmation and process it when the connection returns. The lottie animation needs to go — replace it with a static progress indicator that does not depend on rendering performance.”
The designer pulled up the Figma file and started stripping out animations.
The mockup was beautiful. It was also designed for a phone that 80% of the target users do not own.
Offline-first is not a feature — it is an architecture decision
Most product teams treat offline support as an edge case. In India, it is the default state for a significant chunk of your users. Not “no internet” — intermittent internet. The connection works for 30 seconds, drops for 10, comes back at half the speed, then drops again inside a lift or a concrete building.
The patterns that work:
Optimistic writes with background sync. Let the user complete their action immediately. Write to local storage. Sync when connectivity returns. JioMart does this — you can browse the catalogue, add items to cart, and even place an order while offline. The order queues and processes when the device reconnects. The user never sees a spinner.
Progressive image loading. Show a 2KB placeholder immediately. Load a compressed thumbnail (10KB). Only fetch the full image if the user taps to expand AND has a decent connection. Meesho’s product catalogue does exactly this — the initial grid loads in under a second because each thumbnail is aggressively compressed.
Local-first data with server reconciliation. Store the user’s data on device as the primary copy. Sync to server as a backup. This inverts the typical client-server model — instead of fetching from server and caching locally, you work locally and push to server. It means the app is always fast, always has data, and connectivity only affects freshness, not functionality.
Graceful degradation, not error states. When the connection drops, do not show an error. Show the last known state with a subtle indicator that data might be stale. “Prices as of 2 hours ago” is more useful than “No internet connection — try again later.”
Multi-language is not translation
The biggest mistake product teams make with Indian language support: they write the product in English, then send the strings to a translation vendor, and call it “Hindi support.”
This fails for three reasons:
UI layouts break. Hindi text is typically 20-30% longer than English. Tamil can be 40% longer. Urdu reads right-to-left. Your carefully designed card layout that fits “Add to Cart” in a button now has to fit “कार्ट में जोड़ें” — which is wider. If your layouts use fixed widths, they break. If your text truncation logic assumes English word boundaries, it breaks in Hindi where compound words can be very long.
Translation is not localisation. “Sign up” translates to Hindi as “साइन अप करें” — which is just a transliteration. A user who does not know what “sign up” means in English still does not know what “साइन अप करें” means. The actual localisation would be “खाता बनाएँ” (create account) — which is a different concept expressed in familiar Hindi vocabulary. ShareChat learned this early: their entire UI uses colloquial Hindi, not translated-from-English Hindi.
Cultural context changes meaning. Colours, icons, and metaphors carry different weight across regions. A thumbs-up icon means approval in most of India but can be offensive in parts of the Middle East and South Asia. A green checkmark universally works. A piggy bank icon for savings means nothing to someone who has never seen a piggy bank — and most users outside metro India have not. Use a locker or a safe icon instead.
The right approach:
- Design for the longest language first. If you support Hindi, Tamil, and English, design your layouts for Tamil (the longest). Everything else will fit.
- Use icons with text, not icons alone. A hamburger menu icon is meaningless to a first-time smartphone user. Pair it with a label.
- Hire native speakers as content designers, not as translators. A Hindi content designer writes UI copy in Hindi. A translator converts English UI copy to Hindi. The output is fundamentally different.
- Test with native-language users, not bilingual users. The bilingual tester will understand the transliterated English. The monolingual Hindi user will not.
Designing for low-literacy users
180 million Indian internet users cannot read well enough to use a text-heavy interface. They can recognise logos, follow visual patterns, and understand spoken instructions. They cannot parse a settings screen with 12 text options.
This is not about “simplifying.” It is about designing a parallel interaction model.
Voice-first input. Meesho added voice search in 2022 and saw search usage spike 3x among tier-3 users. These users knew what they wanted to buy but could not spell it — not even in Hindi. Speaking “red saree for wedding” is natural; typing “रेड साड़ी शादी के लिए” requires keyboard fluency that many users lack. Google Pay India added voice commands for the same reason — sending money by speaking “200 rupees to Ramesh” removed the literacy barrier from UPI payments.
Visual navigation patterns. Use product images as the primary navigation element, not category labels. A grid of dress images communicates more than a list that says “Women’s Ethnic Wear > Sarees > Silk.” Swiggy’s restaurant selection works because you see the food, not because you read the restaurant name.
Video tutorials over text help. When JioMart needed to onboard new users who had never ordered groceries online, they created 30-second video walkthroughs in regional languages. Not text tutorials. Not FAQs. Short videos showing someone placing an order on the exact same phone the user holds. Completion rates for onboarding jumped 40%.
Consistent spatial patterns. Low-literacy users rely heavily on positional memory. “The red button is at the bottom” becomes their mental model. If you move the checkout button from bottom-right to bottom-centre in a redesign, you will lose these users. A/B testing with literate users will not catch this — their spatial dependency is lower.
Data cost sensitivity is a silent product killer
Indian users on prepaid plans pay per GB. When Jio’s cheapest plan gives you 1.5GB per day, every app competes for that data budget. WhatsApp and YouTube take the lion’s share. Your app gets whatever is left.
Users in India have developed sharp instincts about data consumption. They:
- Check which apps consume the most data in settings and restrict or uninstall heavy ones
- Avoid apps that autoplay video or load high-resolution images
- Prefer lite versions (Facebook Lite, YouTube Go, Twitter Lite) not because of storage but because of data
- Turn off background data for most apps, which breaks your push notification and sync strategies
Design implications:
Compress aggressively. If your product images are 200KB each, you are burning through a user’s daily data budget just to show a catalogue page. Meesho serves product thumbnails at 8-15KB using WebP with aggressive quality reduction. The images look fine on a 5.5-inch screen. They would look terrible on a Retina display — but that is not the target device.
Make data usage transparent. Show users how much data your app has consumed. Give them controls: “Load images only on WiFi,” “Download for offline,” “Low data mode.” These controls build trust with data-conscious users.
Avoid background data usage unless the user explicitly opts in. Syncing in the background without consent is a trust violation for users who monitor every megabyte.
Right-to-left considerations for Urdu
India has 50+ million Urdu speakers. If your product serves government services, education, or communities in UP, Bihar, or Hyderabad, RTL support is not optional.
RTL is not just flipping the layout. It requires:
- Mirrored navigation. Back buttons move to the right. Progress bars fill from right to left. Horizontal scrolls reverse.
- Bidirectional text handling. Urdu sentences mixed with English words (product names, brand names) require proper bidi rendering. “آپ کا iPhone 15 آرڈر” has LTR text embedded in RTL text — and most rendering engines get this wrong without explicit direction markers.
- Number directionality. Urdu uses the same Arabic-Indic numerals as Hindi (۱۲۳), but phone numbers and prices should display in the familiar left-to-right order even within RTL text.
- Script-appropriate typography. Nastaliq script (the calligraphic Urdu script) requires more vertical space than the Naskh script used in Arabic. Line heights that work for Arabic will clip Urdu descenders.
Test RTL with actual Urdu readers. Automated layout testing catches mirroring bugs but misses reading flow issues that only a native speaker notices.
Real examples that got it right
Meesho — built its entire product for non-English-speaking resellers in tier-2/3 cities. Voice search, visual-first browsing, WhatsApp-native sharing (because their users already live in WhatsApp), image-based catalogues with minimal text, and a 15MB APK. Did not start with English and translate. Started with the tier-3 user and built the product around their constraints.
Google Pay India — redesigned the payment flow for first-time digital payment users. Large touch targets, minimal text, step-by-step guidance with illustrations, support for 8 Indian languages from launch, and a reward system (scratch cards) that created a dopamine loop around an otherwise anxiety-inducing action (sending money digitally for the first time).
ShareChat — treated each language as a separate content ecosystem, not a translated version of the same feed. The Tamil community on ShareChat creates and consumes different content than the Hindi community. The product team built recommendation engines per language, not a single model with a language filter. This is the difference between localisation and true vernacular product thinking.
JioMart — offline-first grocery ordering that works in spotty connectivity. The app pre-caches the catalogue based on your location, stores your cart locally, and processes orders when connectivity returns. Returns and replacements are handled via a WhatsApp flow because their users are more comfortable in WhatsApp than in-app.
Test yourself
Your product launched six months ago in Hindi and English. It is growing well in North India. The business team wants to expand to South India and asks you to add Tamil, Telugu, Kannada, Malayalam, Marathi, Gujarati, Bengali, and Odia — eight languages in the next quarter. Your current language support was built by sending English strings to a translation vendor.
Your engineering lead says adding eight languages is straightforward — they just need translated string files. Your designer is worried about layout breakage. The business team is pushing hard on the timeline. What do you do?
your path
This exercise requires you to experience your product the way most Indian users experience it. You will need an Android phone that costs under INR 10,000 (a Redmi, Realme, or Samsung Galaxy M-series).
If you do not have a budget device, use Chrome DevTools to simulate the constraints:
- Open your product in Chrome. Press F12 to open DevTools.
- Go to the Network tab. Select Slow 3G from the throttling dropdown.
- Go to the Performance tab. Click the gear icon and set CPU throttling to 4x slowdown.
- Resize the browser window to 360 x 640 pixels (the resolution of a typical budget Android phone).
Now attempt these tasks and record what happens:
- Load the home screen. Time it. If it takes more than 5 seconds on throttled 3G, your users are bouncing.
- Complete the primary user flow (signup, purchase, booking — whatever your core action is). Note every point where you wait, see a spinner, or encounter an error.
- Turn off your network entirely (airplane mode or disconnect WiFi). Can you still do anything useful in the app? If the answer is “no,” you have a single point of failure.
- Switch the language to Hindi or another supported Indian language. Check every screen for text overflow, truncation, and copy that reads like translated English.
- Check your app size in phone settings. If it is over 30MB, list what could be removed or lazy-loaded.
Write up your findings in a one-page document with three columns: what broke, who it affects, and proposed fix with effort estimate. Bring this to your next design review.
Career-stage considerations
0-2 years: Test every feature on a budget Android phone over a slow connection. This single habit will teach you more about India-specific product design than any course. If you are not regularly using a Redmi or Realme to test your product, you are designing for a user who does not exist.
3-5 years: India-specific UX skills — vernacular design, offline-first architecture, low-literacy interaction patterns — are rare and valuable. Most PMs at this stage are chasing generic “product sense” skills. If you build genuine expertise in designing for India’s diversity, you become the person companies bring in for Tier-2/3 expansion, regional launches, and new-to-internet user segments.
5+ years: You can build a career as the PM who understands Bharat, not just India. At the senior level, this means shaping product strategy around India’s real demographic and infrastructure constraints — not adapting a San Francisco playbook after the fact. Leaders who deeply understand India’s diverse markets are in short supply, and this expertise only becomes more valuable as more companies chase the next 500 million users.
You are designing the LEAD School app for students in Class 6-8 in Tier 2-3 cities. User research shows 73% of students use smartphones with less than 2GB RAM. The design team has proposed an interactive animated lesson experience that requires 4GB RAM minimum to run smoothly.
The call: Do you ship the animation-heavy experience for the 27% of students it works for, or redesign for the 73%?
You are designing the LEAD School app for students in Class 6-8 in Tier 2-3 cities. User research shows 73% of students use smartphones with less than 2GB RAM. The design team has proposed an interactive animated lesson experience that requires 4GB RAM minimum to run smoothly.
The call: Do you ship the animation-heavy experience for the 27% of students it works for, or redesign for the 73%?
Where to go next
- UX principles that apply across all markets: UX Principles
- Making products usable for everyone, not just the able-bodied: Accessibility
- Going deeper on regional language product design: Vernacular UX
- Getting real data from real users: User Research Methods