Usability testing with Indian mobile users
Plan usability testing across India’s city tiers, languages, devices and networks. Test UPI, OTP and PIN-code flows safely before development.
Usability testing in India should recruit beyond English-speaking metro users, then test realistic mobile tasks such as UPI payment, OTP verification and PIN-code entry on participants’ own devices and networks. Moderate in the participant’s preferred language, record observable behaviour rather than assumptions, and collect consent and personal data with the DPDP Act, 2023 in mind.
Key takeaways
- •Recruit across city tiers, language groups, Android device capabilities and network conditions instead of treating India as one user segment.
- •Use tasks that match Indian mobile behaviour: UPI payments, OTP receipt and entry, delivery PIN-code lookup, and recovery from failed or delayed states.
- •Run moderated sessions in a participant’s preferred language; translate the research guide without forcing English-language comprehension.
- •Keep participant data minimal, explain the purpose of recording, and handle consent and retention carefully in light of the DPDP Act, 2023.
- •Create alternative task flows in floow.design and put them in front of Indian users before development.

What's on this page
- •Define the Indian audience before writing the test script
- •Build realistic tasks for Indian mobile journeys
- •Moderate in the participant’s language
- •Handle consent and participant data carefully
- •Interpret patterns, then turn them into screen decisions
Watch: Usability Testing 101
Video by NNgroup, embedded from YouTube.
Define the Indian audience before writing the test script
Start by splitting the audience on factors that can change mobile behaviour: city tier, preferred language, device class, confidence with digital payments, and typical connectivity. Recruiting only English-speaking users from Bengaluru, Delhi or Mumbai will miss people who navigate primarily in Hindi, Tamil, Telugu, Marathi, Bengali, Malayalam, Kannada or another regional language.
Make a recruitment matrix rather than a single generic screener. Include users from metros, tier 2 cities and, where the product serves them, tier 3 towns or rural areas. Ask which language they prefer for a conversation, which language they use for apps, whether they share a device, and whether they usually rely on mobile data, Wi-Fi, or both. These are screening variables, not proxies for competence.
Set quotas only for distinctions that affect the product decision. A grocery delivery app may need location and delivery-address coverage; a finance app may need payment familiarity and language coverage. In the screener, avoid asking for bank details, UPI PINs, Aadhaar numbers, or full addresses. Recruit enough variation to expose different task failures, then document exactly who was represented in the ui ux case study.
Build realistic tasks for Indian mobile journeys
A useful usability test asks participants to complete an outcome, not to judge a screen. For an Indian consumer app, write scenarios around actions they already recognise: find service availability using a delivery PIN-code, confirm a mobile number through an OTP, choose a payment option, and complete or recover from a UPI payment.
Do not ask anyone to expose credentials. Use a sandbox, test account, mock payment success state, or a moderator-controlled prototype. Participants must never say their OTP aloud, disclose a UPI PIN, or share a bank balance. If a flow reaches a real payment boundary, stop there and ask what they expect to happen next. The National Payments Corporation of India describes UPI as an instant payment system; its familiar payment states make confirmation, pending, failure and retry screens especially important to test (NPCI).
Include adverse conditions deliberately: a late OTP, an expired OTP, a UPI payment marked pending, a lost connection during submission, and an unclear PIN-code result. Observe whether people understand the status, know what to do next, and can recover without contacting support.
Moderate in the participant’s language
Use a moderator who can conduct the session in the participant’s preferred language, or pair a language-capable moderator with a note-taker. A translated script is not enough if the moderator cannot follow colloquial answers, hesitation, or a participant’s own terms for payment and account actions.
Keep the prototype language and the session language separate where necessary. A participant may use an English-language app while preferring Hindi or Tamil in conversation. Ask what they think each label means, rather than assuming English UI copy is understood because it is common in urban apps. Where the product will offer regional-language UI, show that version to the relevant participants and compare comprehension of critical wording such as payment status, consent, retry and address instructions.
Use neutral prompts: “What would you do now?” and “What do you expect after tapping that?” Avoid translating the answer into a suggested action. Record the original wording for confusing labels; translation can erase the precise term that reveals the problem. For remote sessions, have a fallback if screen sharing or video fails: a phone call, participant screenshots with identifiers masked, or a rescheduled session. This is one of the user research methods that benefits from planned redundancy, not improvised rescue.
Handle consent and participant data carefully
Before recording, explain what the study is for, what will be captured, who will see it, how long it will be retained, and how a participant can stop. Obtain informed consent in a language the participant understands. If you record screen, voice or video, name each of those explicitly rather than hiding them under a broad checkbox.
The Digital Personal Data Protection Act, 2023 provides the Indian context for personal-data handling. Design research operations around clear notice, a defined purpose, data minimisation and controlled access; have your legal or privacy owner assess the organisation’s specific obligations and implementation. The Act is available through the Government of India’s legal publication resources (India Code).
Collect only what the research decision needs. Replace names with participant IDs in notes, remove phone numbers and addresses from screenshots, restrict raw recordings to the research team, and set a deletion date. Never request a UPI PIN, OTP, full card detail, Aadhaar number, or banking login during usability testing. If a participant reveals sensitive information accidentally, pause the recording where possible and redact it from the research record.
Interpret patterns, then turn them into screen decisions
After each session, separate observation from interpretation. “Three participants tapped UPI before reading the delivery fee” is an observation. “The payment hierarchy is unclear” is an interpretation to validate against the recordings. Tag findings by task, city tier, language, device/network condition and severity, but do not claim that every difference is caused by geography or language from a small qualitative sample.
Prioritise issues that block completion, create payment uncertainty, expose privacy risk, or cause users to repeat actions. For UPI, a participant who retries while a transaction is pending may create a serious support problem even if the visual issue looks minor. For OTP flows, distinguish failure to receive the code from uncertainty about where or when to enter it. For PIN-code tasks, identify whether the problem is number entry, availability messaging or address validation.
Convert each finding into a testable design change: clearer pending-payment guidance, an OTP resend timer with explanation, regional-language wording, or a better PIN-code error state. Create alternative task flows in floow.design and put them in front of Indian users before development. Re-test the changed flow with users matching the affected segment, not only with the original internal team.
Practical recruitment dimensions for Indian mobile usability studies
| Dimension | Include in the sample | Why it changes the test |
|---|---|---|
| Location | Metro, tier 2 city, and relevant tier 3 town or rural area | Service availability, addresses, connectivity and local habits can differ. |
| Language | Participants’ preferred conversation language and app language | Comprehension of labels, consent and payment states may differ. |
| Device and network | Participants’ own Android device range and typical mobile-data or Wi-Fi conditions | Screen size, performance and interrupted connectivity affect task completion. |
| Task familiarity | UPI use, OTP flows and PIN-code-based delivery or service lookup | Familiarity changes expectations and reveals recovery needs. |
Common mistakes
Recruiting only English-speaking professionals from major metros.
Set a recruitment matrix across relevant city tiers and language groups, then report the sample limits honestly.
Treating UPI completion as a generic checkout task.
Test pending, failure, retry and confirmation states without collecting OTPs, UPI PINs or real banking information.
Using English moderation because the prototype is in English.
Conduct the session in the participant’s preferred language and test whether the UI wording itself is understood.
Saving recordings indefinitely with identifiable participant details.
Use explicit informed consent, minimise collection, restrict access, redact identifiers and define a retention period in line with privacy review.
Frequently asked questions
How do I run usability testing in India?
Run usability testing in India by recruiting across relevant city tiers, language groups, device types and network conditions, not only English-speaking metro users. Give participants realistic tasks such as a UPI payment, OTP verification and PIN-code lookup. Moderate in their preferred language, use their own devices where possible, and obtain informed consent before collecting recordings or personal data.
How many users should I test with?
For qualitative usability testing in India, begin with a small round per meaningful audience segment, then test again after fixing the highest-risk issues. The right number depends on whether city tier, language, device capability or payment familiarity changes the flow. Do not combine all Indian users into one sample merely to reach a larger total; segment coverage matters more than a single headline count.
Should usability tests be conducted in regional languages?
Usability tests should be conducted in regional languages whenever the target audience prefers them or the product will support them. Participants may use English UI labels yet explain their reasoning more accurately in Hindi, Tamil, Telugu, Marathi, Bengali or another preferred language. Use a moderator who understands that language and test critical UI copy, consent wording and payment-status messages directly.
How should I test UPI and OTP flows safely?
Test UPI and OTP flows with prototypes, sandbox accounts or moderator-controlled states so participants never disclose a UPI PIN, OTP, bank balance or login. Include realistic states such as delayed OTP delivery, expired OTP, pending payment, failure and retry. Observe whether users understand the status and recovery action, then remove any accidental personal information from research recordings and notes.
Where this leaves you
Indian mobile usability testing works when the sample reflects the users who will actually complete the task: different city tiers, language preferences, devices and connection conditions. Treat UPI, OTP and PIN-code journeys as high-consequence flows, protect participant data, and validate alternative floow.design task flows with Indian users before engineering begins.
Design the screens first
Describe the app in plain language and floow.design draws the iOS and Android screens for you, ready to refine and hand off.
Sources
Design your mobile app with AI.
Generate pixel-perfect iOS and Android screens in seconds, then export to Figma or code.