The next several hundred million Indians coming online are not the audience most apps were designed for. Many live in Tier 2 and Tier 3 cities and towns, read and type in Hindi, Tamil, Bengali or Marathi more comfortably than English, share a phone with family, use mid-range Android devices and move in and out of coverage all day. The design patterns that work for urban early adopters break for them — quietly, and at scale.
Start with research, not assumptions
Most product teams sit in metro offices. Before designing, spend time with real users in the towns you are targeting. Watch them use your app, and a competitor's, on their own phones and their own networks. Note which language they choose when given the option, where they hesitate, and who they turn to for help. A handful of sessions per user segment usually surfaces the most serious problems.
The four patterns that consistently fail
- Heavy English-only copy. Even users who read English find tasks involving money, identity or compliance harder in a second language. Make Indian-language options a default path, not a buried setting, and write them natively rather than machine-translating the English.
- Long onboarding flows. Every extra screen, field and OTP retry costs users, and on a patchy connection each step is another chance to fail. Ask for the minimum needed to get started and collect the rest later.
- Voice-only or text-only interfaces. Many users prefer to speak their input but want visual confirmation of what was understood. Single-modality interfaces lose them.
- Aggressive permission requests. Asking for camera, location, contacts and notifications upfront invites an uninstall. Ask for each permission at the moment it is needed, with a one-line reason.
Patterns that consistently work
- Local-language voice input. Indic speech recognition — from the government's Bhashini platform or providers such as Sarvam — lets users speak instead of type, which cuts effort and onboarding time. Always show the transcribed text so users can correct it.
- WhatsApp-first workflows. WhatsApp is part of daily life for a very large share of Indian smartphone users. Use it, through the official Business Platform and with opt-in, for OTPs, confirmations, reminders and support, so users stay informed without keeping your app open.
- Offline-first architecture. Connections drop constantly. Cache aggressively, queue writes, sync in the background, and tell users plainly what has and has not been saved. The app should feel the same in a Tier 3 town as in Bangalore.
Design for shared devices and modest hardware
- Support quick account switching, and do not assume one phone means one person.
- Keep the app small. Storage is often full, and large downloads get postponed.
- Test on a mid-range Android phone with a throttled network, not only on the design team's flagships.
- Put sensitive screens such as balances or health records behind a PIN or biometric check.
Imagery, iconography and tone
Stock photography of laptop-and-coffee scenes does not land in Bharat. Use imagery that reflects your users' own settings and contexts. Iconography should be unambiguous: pair icons with labels, and avoid clever metaphors that assume specific cultural references. Keep copy warm and direct; formal, bureaucratic language raises anxiety on anything involving money or documents.
Accessibility is non-negotiable
India's Rights of Persons with Disabilities Act, 2016 sets accessibility obligations, including for information and communication technology, and government and regulated clients increasingly ask for evidence of compliance. Use WCAG 2.2 as the working standard and follow platform guidance on top of it: touch targets of at least 44×44 pt on iOS and 48×48 dp on Android, strong colour contrast, screen-reader labels on every control, and text that scales without breaking layouts. Designing accessibly almost always improves the experience for everyone — particularly older users on mid-range devices.
A worked example
Say a lender is launching a loan-application app for small shopkeepers. A Bharat-first version might open with a language picker offering Hindi, English and one regional language; verify the phone number with a single OTP that can also arrive on WhatsApp; let the user speak their shop name and address, then confirm it on screen; save progress after every step so a dropped connection loses nothing; and request camera access only when the user reaches the document-upload step. None of this is exotic. It is a series of small decisions, each of which removes a reason to give up.
How to measure whether it works
- Onboarding completion rate, broken down by language, city tier and device.
- Time to first successful action.
- Retention at day 7 and day 30 for each segment.
- Support contacts per thousand users, and their most common reasons.
If one segment lags, go back to the field research for that segment before changing anything else.
FAQ
Which languages should we launch with?
The ones your target region actually uses — usually Hindi or the dominant regional language, plus English — informed by your own user data where you have it. Adding languages later is far easier if every string is externalised from day one.
Is a lightweight web app better than a native app here?
It is worth testing. A fast, installable web app avoids download friction; a native app handles offline work and device features better. Many products end up needing both.
How we approach this at Velura Labs
Our product design & UX service builds in Bharat-first patterns by default — Indian-language support, offline-first flows and WhatsApp integration where it makes sense. Pair it with mobile app development for the build, or read our multilingual RAG playbook for the AI side. Talk to us if you are launching a product into Tier 2 and Tier 3 India and want it to retain users.
Whether you are in California, Texas or Washington in the US, France or Italy in Europe, the UAE or Saudi Arabia in the Gulf, or here in India, Velura Labs delivers this end to end. Talk to us about your context.