Designing for Bharat: What Rural UX Research Taught Me About Assumptions

I grew up in India. I've been designing for Indian users for six years. I had an opinion about what 'mobile-first' means for the Indian market. Then I spent three weeks conducting UX research in rural Pune for the MedSecure healthcare project, and I had to rebuild most of those opinions from scratch.

What follows are the specific findings that changed how I think about inclusive design — not the feel-good summary version, but the specific moments where my assumptions were wrong.

Assumption 1: Literacy Is Binary

I designed MedSecure's initial navigation with labeled icons — an icon plus a text label underneath. Standard mobile UX practice. WCAG recommends it. NNGroup recommends it. It's correct.

In our Pune pilot sessions, three of our eight participants had functional literacy levels that made short English labels readable but slow. 'Records' required a beat of processing. 'Consent' required explanation from the health worker facilitating the session.

More surprising: two participants with low English literacy navigated confidently using icon-only once they had learned the icons in the first session. They had developed a spatial memory of the app — 'the shield is where I control who sees my information' — that was faster and more reliable than reading the label each time.

Literacy isn't binary. It's a spectrum, and different users on that spectrum develop different compensating strategies. Good inclusive design doesn't force everyone onto the literacy-dependent path.

The fix was a progressive disclosure of labels: icon-only in the bottom nav by default, with the label revealed on first use and on long press. Users who need the label get it. Users who prefer icon-only aren't slowed down by text they don't need.

Assumption 2: The Primary User Is an Individual

Almost every UX framework I was trained in assumes a single user interacting with an interface for their own purposes. Health apps in particular tend to assume individual agency: 'the patient controls their own health data.'

In the families I spoke with in rural Pune, health decisions — and the records associated with those decisions — were family decisions. A 45-year-old man with diabetes showed me his phone during the research session. His wife had set up the app for him. His son managed the consent requests on his behalf. He knew roughly what the app did but wasn't the primary operator.

This pattern appeared in 5 of 8 sessions. MedSecure's 'Care Circle' feature — which allows trusted family members to have view or approval access to a patient's records — was not originally in scope. I added it after the first week of field research. It became the most used feature in the pilot.

Assumption 3: Connectivity Is the Main Technical Barrier

I went into the research thinking connectivity would be the dominant technical constraint. Rural India has real connectivity gaps, and I had designed an offline-first data sync model for MedSecure specifically to address this.

Connectivity was a factor. It wasn't the primary one. Storage was.

Six of the eight participants in our pilot were using budget Android devices with 16–32GB total storage, of which 8–14GB was available. Several had already uninstalled apps to free space. One participant showed me a notification that he had to delete photos to proceed with an app update.

• MedSecure's APK needed to stay under 8MB installed. We achieved 6.4MB by deferring all non-critical assets.
• Medical records (PDFs, images) had to offer a 'save to cloud only' option — many users explicitly did not want records taking phone storage.
• Onboarding had to load instantly with no dependency on a large asset download. We stripped all illustration assets from the initial onboarding flow.

Assumption 4: Trust Is About Security

I came in thinking the main trust barrier for a medical records app would be security — users worried about their data being stolen or misused. I planned a prominent 'your data is encrypted' explainer in onboarding.

The actual trust barrier was institutional, not technical. Several participants asked versions of the same question: 'If I link my ABHA card to this, will the government know? Will the insurance company know? Will my employer know?'

They weren't worried about hackers. They were worried about a system they had learned to distrust through experience — employers who raised insurance premiums after accessing health records, clinics that shared records without consent for billing purposes, bureaucratic processes that moved health information without patients understanding where it went.

The design response to this is different from a security-focused response. It's not 'your data is encrypted.' It's 'you control exactly who sees what, and you can revoke access at any time.' The UI needs to make that control visible, auditable, and reversible — not just promised in a privacy policy.

What Changed in My Practice

I now build a 'context assumptions' document at the start of every project: what device, connectivity, literacy level, and social context am I assuming my primary user has? When I'm wrong — and field research usually shows me I'm wrong about at least one — I have a clear record of what changed and why.

If you design digital products for Indian users and have never done research outside of Tier-1 cities, you are designing for an abstraction. The abstraction is useful. It is not the same as the user.