vernacular ux

Ninety percent of the next 500 million internet users in India will not be comfortable in English. That is not a projection — it is the current trajectory visible in every data set from IAMAI, Google’s Year in Search India, and every telco’s subscriber analysis. These users are already online. They are on YouTube, WhatsApp, and ShareChat. They are buying on Meesho and JioMart. They are consuming content on Kuku FM and Pratilipi.

And most product teams are still treating multilingual as a feature they will “add later.” A checkbox in the settings page. A Google Translate API call wrapped in a sprint.

This page is about why that approach fails and what actually works. Vernacular UX is not a translation project. It is a UX redesign.

Translation is not the problem. Comprehension is.

The first mistake every team makes: they hire a translation agency, feed in English strings, get back Hindi strings, and ship. Two weeks later the support tickets start arriving. Users are confused. Conversion drops. The team blames “low digital literacy” and moves on.

The actual problem is that literal translation breaks meaning.

Take a simple English string: “Your account balance is low. Add funds to continue.” Translate this literally to Hindi and you get a grammatically correct sentence that no one on the street would say. The phrasing is formal, Sanskritized, and sounds like a government notice. A Hindi-speaking user in Patna who manages their money through PhonePe does not think in those words. They think in a mix — partly Hindi, partly English loanwords, partly regional idiom.

This is the difference between translation and transcreation. Translation converts words. Transcreation converts meaning — it rewrites the message so that it lands the same way in the target language as the original did in English. It accounts for idiom, register, emotional tone, and the mental model of the reader.

Financial terms are the worst offenders. “Credit,” “debit,” “balance,” “interest rate” — these English words have been absorbed into everyday Indian usage. If you translate “credit” to the formal Hindi “shreyank” or “jama,” you confuse the very users you are trying to include. Many Indians who speak Hindi daily still say “credit ho gaya” and “balance check karo.” Your UI should reflect that.

Technical terms follow the same pattern. “Download,” “upload,” “login,” “OTP” — these are universally understood in their English form across Indian language speakers. Translating “OTP” to its Hindi equivalent adds cognitive load rather than removing it.

The rule: Translate sentences, not terms. Keep English loanwords that have entered common usage. Test with actual users in the target language — not with translators, not with bilingual team members, not with people in your Bangalore office.

The layout problem nobody talks about

English is a compact language. Hindi is 30-40% longer for the same meaning. Tamil and Malayalam can be 50-60% longer. Bengali sits somewhere in between. This is not trivia — it breaks your UI.

Every element in your product that was designed for English text will need to be re-evaluated:

Buttons. A “Submit” button is six characters. The Hindi equivalent — “jama karein” or a transcreated version — might be twelve to fifteen characters. If your button has a fixed width, the text overflows or truncates. If it truncates, the user sees half a word and does not know what the button does. Multiply this across every CTA in your product.

Navigation labels. A three-item horizontal nav that fits perfectly in English (“Home | Orders | Profile”) may not fit when each label is 40% longer. Hindi “Home” is “mukhya prishth” (if formally translated) or just “home” (if you are sensible). But “Orders” becomes “aadesh” or “orders” and “Profile” becomes “profile” or “vyaktigat vivaran.” The formal translations destroy your nav layout. The transliterated English words work — but then what was the point of translation?

Tables and data grids. Column headers in Indian languages are wider. Cell content wraps differently. A clean three-column table in English becomes a cramped, hard-to-scan mess in Hindi.

Error messages and tooltips. These are often designed for a single line of English text. In Hindi or Tamil, they wrap to two or three lines, breaking the visual hierarchy and sometimes overflowing their containers entirely.

Form labels. Left-aligned labels next to input fields assume the label will be a certain width. In Tamil, a field label like “mobile number” becomes “alagaesi tholarpechi elakkai” — and your form layout collapses.

The fix is not to make everything bigger. The fix is to design for text expansion from the start:

1. Use flexible containers. Never set fixed widths on text-bearing elements. Use min-width and max-width, not width.
2. Design with the longest language first. If you design your layouts in Tamil or Malayalam and then verify they work in English, you will never have an overflow problem. Nobody does this, and everybody should.
3. Test with pseudo-localization. Before you even have translations, run your product through a pseudo-localization pass — replace English strings with strings that are 40% longer. This reveals every layout breakpoint without waiting for actual translations.
4. Accept that some elements need to change per language. A horizontal nav that works in English might need to become a hamburger menu in Tamil. A two-column layout might need to become single-column. This is not a bug — it is responsive design for language.

Transliteration vs translation: the choice most teams get wrong

Here is a fact that surprises product teams building for India: a large percentage of Hindi speakers on the internet prefer to read Hindi written in Roman script (English letters) rather than in Devanagari. They type “kaise ho” not “कैसे हो.” They read WhatsApp messages in Romanized Hindi. Their keyboards are set to English.

This is not a sign of low Hindi proficiency. It is a sign that the Roman script is the default digital script for many Indians, regardless of which language they speak. It is the script they learned to type on, the script their phone keyboards default to, the script they use for messaging every day.

This creates a real product decision: when you add Hindi support, do you offer Devanagari, Romanized Hindi, or both?

Kuku FM got this right. Their audio content is in Hindi, but much of their UI — categories, navigation, search — works in both scripts. Users can search in Romanized Hindi and find results. The product does not force a script choice on the user.

Google Pay India is another example. The app supports Hindi and other Indian languages, but the UX is designed with the understanding that many “Hindi users” will still navigate with a mix of English and Hindi terms. The language toggle does not flip every string — it targets the strings that matter for comprehension while leaving universally understood English terms intact.

ShareChat went fully vernacular — their entire product experience is built language-first, with content discovery, creation tools, and social features designed for non-English users. They did not take an English product and add translations. They built a product that happens to also work in English.

Pratilipi built an entire reading platform for Indian language content. Their UX decisions — how stories are discovered, how authors are surfaced, how the reading experience is optimized — are designed for the script and reading patterns of each language.

The principle: ask your users what they actually want, not what you think they should want. If your user testing reveals that most of your Hindi audience prefers Romanized Hindi for navigation and Devanagari for long-form content, support both. Do not impose a script because it feels more “authentic.”

Voice interfaces and the code-switching problem

Voice is the most natural interface for vernacular India. But building voice interfaces for Indian users means solving problems that Alexa and Siri were never designed for.

Problem one: accent diversity. Indian English has at least a dozen distinct accent patterns — Punjabi English, South Indian English, Bengali English, Marathi English — and each has different phonetic characteristics. A voice model trained on American English misrecognizes Indian speakers constantly. A voice model trained on “Indian English” as a single category still fails because there is no single Indian accent.

Problem two: code-switching. Indian users do not speak in one language. They speak in a fluid mix. A single sentence might be: “Mera balance check karo, last three transactions dikha do.” That is Hindi structure, English financial terms, English number (“three”), Hindi verb endings. This is called code-switching, and it is the default mode of speech for most urban Indians.

Specifically:

• Hinglish (Hindi + English) — the dominant spoken register in north India
• Tanglish (Tamil + English) — common in Chennai and Tamil Nadu
• Benglish (Bengali + English) — common in Kolkata and West Bengal
• Kanglish (Kannada + English) — common in Bangalore

Every one of these is a distinct speech pattern with its own grammar rules about when English words are inserted and how they are inflected. A voice interface that expects pure Hindi or pure English will fail on the input that most users actually produce.

Problem three: noise. Voice interfaces designed for quiet American living rooms do not work in Indian environments — busy streets, shared homes, auto-rickshaws, open offices. Noise cancellation and strong speech recognition in high-noise environments are not optional features. They are prerequisites.

What works: train your voice models on actual Indian speech data that includes code-switching. Google has done significant work here with their Indian language models. If you are building voice features, use models that have been specifically trained on code-switched Indian speech, not models that treat Hindi and English as separate input languages.

The economics are not optional

This is not a nice-to-have diversity initiative. The numbers are clear.

India has roughly 900 million internet users. Of those, only about 10-12% are English-first users comfortable navigating an entirely English product. The other 88% use the internet in their own language — or tolerate English because they have no choice. When they get a choice, they choose their language.

YouTube India serves more watch-time in Hindi than in English. Google Search India processes more queries in Hindi than in English. WhatsApp’s most active market is India, and the overwhelming majority of messages are in Indian languages or Romanized Indian languages.

The companies that figured this out early — ShareChat, Pratilipi, Kuku FM, Meesho, Josh — built for vernacular users from the start, not as a retrofit. They designed their UX, content discovery, and trust signals for users who are not comfortable in English. They grew to tens of millions of users by going where the English-first products refused to go.

The companies that treat vernacular as a “phase two” feature consistently find that phase two never arrives, or when it does, the translation-bolted-on-top approach fails and they lose the market to someone who built it right.

For a PM, this means vernacular support is a strategic decision, not a localization task. It belongs in the product strategy discussion, not in the i18n backlog.

What good vernacular UX actually looks like

After studying products that got this right and working with PMs who shipped successful vernacular products across Pragmatic Leaders cohorts, here are the patterns that separate good from bad:

1. Language selection is prominent, not buried. If your language selector is three taps deep in settings, your vernacular users will never find it. Put it on the onboarding screen. Make it the first choice a user makes. Google Pay India shows language selection as the first step, before anything else.

2. The default language is inferred, not assumed. Use the device language, SIM card region, or location to suggest a language — but always let the user override. Never force a language based on detection. Detection is wrong often enough to frustrate users.

3. English is always available as a fallback. Even users who prefer Hindi or Tamil will occasionally need to switch to English — to share a screenshot with an English-speaking colleague, to read a technical error message, to use a feature that was not yet translated. The language toggle should be accessible everywhere, not just in settings.

4. Visual hierarchy survives translation. The most important information on every screen should remain the most visually prominent after translation. If your English payment confirmation has the amount in large bold text and the Hindi version buries it in a paragraph, you have a visual hierarchy failure.

5. Trust signals are localized, not just text. In English, you convey trust through clean design and security badges. In vernacular India, trust is built differently — through familiar brand associations, through seeing the RBI logo, through regional payment methods (UPI is already universal, but specific regional banks matter), through customer support in the user’s language. Translating the text without adapting the trust signals is half the job.

6. Onboarding is redesigned per language, not just translated. English-first users may read onboarding text. Vernacular-first users are more likely to watch a video or follow a visual tutorial. The onboarding for a Tamil user might need to be entirely visual with voiceover, while the English onboarding can be text-based. Same product, different onboarding — not the same onboarding in two languages.

Common mistakes PMs make with vernacular

Mistake one: Treating it as an engineering problem. Vernacular UX is a product and design problem. Engineering handles the plumbing — the i18n framework, the string management, the font rendering. But the decisions about what gets translated, what gets transliterated, how layouts adapt, and how the UX changes per language — those are PM and design decisions.

Mistake two: Testing with bilingual team members. Your Bangalore office is full of people who speak Hindi and English fluently. They are the worst possible testers for your Hindi UX because they do not experience the confusion that a monolingual Hindi user does. They will tell you the translation is “fine” because they can mentally substitute the English meaning. Test with actual target users in actual target environments.

Mistake three: Launching all languages simultaneously. Every language is a separate UX problem. Hindi and English have different text expansion characteristics than Tamil and Malayalam. The code-switching patterns are different. The cultural references are different. Launch in two or three languages, get them right, learn the patterns, then expand. Trying to do ten at once means doing ten badly.

Mistake four: Forgetting about fonts. Not every font supports every Indian script. Devanagari, Tamil, Telugu, Malayalam, Bengali, Gujarati, Kannada, Odia, Punjabi — each script has different rendering requirements, different line-height needs, different legibility thresholds at small sizes. If you pick a font stack that renders Tamil at 14px as an unreadable blob, you have a font problem, not a language problem.

Mistake five: Ignoring right-to-left considerations for Urdu. If your product serves users in Jammu and Kashmir or targets the Indian Muslim demographic, Urdu support means RTL layout support. This is a completely different UI challenge that affects every element from navigation to form fields to text alignment. Plan for it early or not at all.

Test yourself

Where to go next

• Understand the broader India product context: Designing for India
• Apply core UX principles to any market: UX Principles
• Research methods for vernacular user testing: User Research Methods
• Optimize activation for non-English users: Activation Optimization