Designing for Bharat: shipping to tier-2 and tier-3 users

We rebuilt a consumer marketplace whose analytics said 71% of sessions came from outside the top eight cities and whose design had clearly been made in one of them. Conversion outside the metros was 1.1%. Inside, 3.4%. Same product, same price, same catalogue. The gap was not demand. It was that the product was hostile to the conditions it was actually being used in.

Nine months later the non-metro number is 2.6%. This is what changed, and none of it is a redesign in the aesthetic sense.

Start by knowing the actual device

Pull your own analytics before you read anyone's blog post, including this one. Ours said:

• Median device: an Android phone in the ₹8,000–₹13,000 band, 3–4 GB RAM, launched two to three years ago
• Median viewport: 360 × 800 CSS px. Not 390. Not 430.
• Chrome, several versions behind, because updates cost data
• Free storage under 2 GB on a third of devices — which means your app gets uninstalled to make room for photos, and a 90 MB APK is a liability

The consequence people miss: on that class of device, the bottleneck is not download time, it is JavaScript parse and execute time on a weak CPU. A 300 KB JS bundle that a Pixel chews through in 200 ms takes 1.4 seconds on a Redmi from 2022 — and that second-and-a-half is spent with the main thread blocked, so taps do nothing. Users do not think "this is slow"; they think "this is broken", and they tap again, and now you have a double-submit bug too.

We set a hard budget: 150 KB of JavaScript on the critical path, enforced in CI. The build fails if you exceed it. That constraint, more than any single optimisation, is what forced the good decisions.

The network is not what the icon says

The phone shows 4G. The throughput at 8 p.m. in a district town, on a congested tower, is 300–600 kbps with 400 ms of latency and intermittent packet loss. Not "slow broadband" — unreliable, which is a different problem.

What that changes:

• Every request must be able to fail and be retried without breaking the UI. A spinner that spins forever is the single most common bug in Indian apps.
• Optimistic UI is not a nicety, it is the difference between usable and not. Add-to-cart updates the badge instantly and reconciles later.
• Never block a screen on a non-essential call. Recommendations, reviews, "recently viewed" — all of it renders after, or not at all.
• Images: AVIF with a WebP fallback, served responsively, lazily below the fold. Our product grid went from 1.8 MB to 240 KB per screen. That is not a micro-optimisation; on 400 kbps it is 36 seconds versus 5.

Test on Slow 4G with packet loss, not on "Fast 3G" in DevTools, and test on a real cheap phone. We keep four in the office. They are the most valuable hardware we own, because a bug on a Redmi 9 is invisible on a MacBook and there is no amount of empathy that substitutes for holding the device.

Language is not translation

The naive move is to run the English strings through a translation service and ship a Hindi toggle. Then you discover:

• Devanagari needs more vertical space. Your fixed-height 40px button now clips the matras. Set line-height per script, not globally, and never fix the height of a text container.
• Hindi strings run 15–30% longer than English. Every truncation you did not think about now appears.
• A very large share of users read the Latin script more comfortably than they read English, and type in Hinglish. "Kapde" in a search box must find clothing. Transliteration in search is a bigger win than a language toggle, and it is much cheaper.
• Formal register translation ("आपका आदेश प्रेषित कर दिया गया है") reads as bureaucratic and cold. Hire a human. Machine translation of transactional copy sounds like a government notice, which is exactly the wrong emotional tone for a purchase.

Our highest-ROI language change was not the Hindi UI. It was making search tolerate Hinglish and misspellings, which lifted search-to-product-view by 19%.

Trust and money

Payment is where the metro assumption is most expensive.

• UPI intent, not a card form. Deep-link straight into the user's UPI app. Every field in a card form is a place to lose someone; on mobile, a card form is a conversion cliff.
• Cash on delivery is not going away. It is a trust instrument, not a payment method. Removing it will cut your orders. The right move is not to remove it but to make prepaid more attractive — a small discount, faster delivery — and to reduce the RTO risk with address verification and an OTP confirmation on high-value COD.
• Show the total, with delivery, before the user commits to anything. Surprise charges at the last step are the top cited reason for abandonment in every session recording we have watched, and they are worse in price-sensitive segments.
• Order tracking is a trust feature. Users who cannot see where their order is will call your support line, and your support line costs you ₹40 a call.

The interface itself

Some patterns that read as clean and modern in a metro-facing product simply do not land:

• Icon-only navigation. A bare hamburger, or a row of unlabelled glyphs, tests badly. Put a text label under every icon. It costs you 12 px of vertical space and buys you comprehension.
• Low-contrast grey-on-grey. Half these sessions happen outdoors in daylight. We enforce 4.5:1 minimum, and for body text we prefer 7:1. This is an accessibility standard, but here it is a legibility-in-sunlight requirement.
• Tap targets under 48 px. Real thumbs, sometimes with a cracked screen protector.
• Gesture-only interactions with no visible affordance. If it can only be discovered by swiping, most users will not discover it.

And on forms — where we lost the most users before we fixed it:

• Phone number is the identity. Not email. Support OTP autofill (autocomplete="one-time-code" and the Android SMS Retriever API) so the user never leaves the screen.
• Autofill city and state from the PIN code. Two fewer fields, and fewer wrong addresses, which directly reduces failed deliveries.
• Include a landmark field. Outside metros, addresses are navigated by landmark, not by house number. Delivery partners have told us this repeatedly. Omitting it is a design decision that costs the client money in failed deliveries.
• Numeric keypad for numeric fields. It is one attribute and it is missing on half the sites we audit.

Reaching the user after they leave

Push notifications underperform badly in this segment, for a mundane reason: notification permission is denied or the app is force-stopped by the OEM's battery manager, so the push never arrives. Meanwhile WhatsApp is open on every one of these phones, all day, and it is the channel users actually check.

We moved order updates to WhatsApp Business API templates, kept push as a secondary channel, and stopped sending transactional email entirely for this cohort — the open rate was under 4%, because for a very large number of Indian users the email address exists to satisfy a signup form and is never opened again.

The related decision is app size. A 90 MB APK is a real barrier when the user has 800 MB free and must delete photos to install you. We split by ABI, moved to an app bundle, deferred non-essential assets to download-on-demand, and got the install size from 78 MB to 22 MB. Install completion rate — the share of users who tap install and end up with a working app — rose by a third. For a large slice of this audience, a well-built PWA is a better answer than an app at all: nothing to install, nothing to uninstall, and it works on the first visit.

What actually moved the numbers

Ranked by measured impact, across nine months:

1. The 150 KB JS budget and the image pipeline — the whole funnel lifted, because fewer people left before seeing anything
2. Hinglish-tolerant search
3. UPI intent flow replacing the card form as the default
4. Landmark field + PIN autofill (fewer failed deliveries, which is margin, not just conversion)
5. Labelled navigation

Notice that four of the five are performance and comprehension, not visual design. This is the point.

Designing for Bharat is not a style. It is the discipline of designing for the actual device, the actual network and the actual literacy of your actual users — and then verifying it on a phone you would not personally choose to own.

Updated July 2026: Cheaper devices and wider 5G have eased the network assumptions slightly — but the language, trust and UI-density lessons above are, if anything, more decisive for tier-2 and tier-3 adoption.