Vernacular Onboarding — Opportunity or SUS?

There is a particular kind of product idea that is almost impossible to argue against. It sounds obviously useful, serves an underserved segment, and seems to have a reasonably straightforward implementation path. Vernacular onboarding was one of those ideas.

The premise was simple: if a significant portion of our users were more comfortable in their native language than in English, perhaps language was creating friction during onboarding. Translate the experience into regional languages, make it more accessible, and we should see better comprehension and, eventually, better conversion.

At first glance, it looked like a classic product opportunity. But the more I thought about it, the more I wondered whether we were jumping from an observation directly to a solution. We had evidence that language preferences existed. We had users who were more comfortable with vernacular content. But did we actually have evidence that language was the reason they were failing to complete onboarding?

That distinction matters. A user's preferred language and the reason they abandon a product are not necessarily the same thing.

Instead of starting with "Which languages should we support?", I started with a more uncomfortable question: "What would we need to believe for vernacular onboarding to be worth building?"

That changed the problem from a feature discussion into an opportunity assessment. If language was truly the barrier, we'd expect to see drop-offs concentrated among users who preferred regional languages, and those drop-offs would correlate with comprehension failures — not product complexity.

We started looking at the onboarding journey itself. Where were users dropping off? Were the drop-offs concentrated among users who preferred regional languages? Were users struggling to understand terminology, or were they struggling because there were simply too many things to understand at once?

The deeper we looked, the more interesting the problem became. Language could absolutely be a source of friction, but it wasn't necessarily the only — or even the primary — source. Some of the onboarding experience was difficult because the product was trying to explain too much. Some terminology was unfamiliar regardless of language. Some steps required users to understand the product's mental model before they had actually experienced its value.

Translation doesn't automatically equal comprehension.

A badly designed onboarding experience translated into five languages is still a badly designed onboarding experience. If the user doesn't understand why you're asking for something, translating the question doesn't solve the underlying problem. If there are too many decisions, presenting those decisions in a regional language doesn't reduce cognitive load.

This reframed vernacular onboarding from a localization initiative into a broader comprehension and accessibility problem. Could we simplify the flow first? Could we replace product terminology with language users naturally use? Could we progressively introduce concepts? Could examples communicate more effectively than instructions?

Rather than jumping to a translation project, we paused and focused on the onboarding flow itself. We simplified decision points, replaced jargon with natural language, introduced concepts progressively, and used examples instead of explanations where possible.

Only after these changes would we assess how much remaining friction could genuinely be attributed to language — and whether localization was still worth the investment.

A SUS — shiny unnecessary solution — isn't necessarily a bad idea. It can be a perfectly reasonable solution applied to the wrong problem. The skill is recognizing that before significant engineering and organizational effort gets committed.

The most valuable part of this project wasn't whether we eventually decided to pursue vernacular onboarding. It was the process of challenging an intuitively attractive solution and uncovering the real problem underneath. Product discovery isn't about validating ideas — it's about creating enough evidence to make a better decision.