Why MoMo’s UX Needs a Rethink for Non-Vietnamese Users 

In Vietnam, using cards and cash is generally a reliable way to make payments while travelling. However, the nearest ATM was quite a distance from where I was staying, and not all shops accepted cards. One payment method that popped up consistently, both on e-commerce websites and in local stores, was MoMo. Curious and eager to make my life a little easier, I decided it was time to give it a try - despite the fact that I don’t speak or read Vietnamese. 

Downloading the Momo app was a breeze. You can grab it directly from the Google Play Store here. Having dealt with clunky banking apps in other countries, I wasn’t expecting the smoothest ride when it came to linking my card, but I wanted to see how Momo stacked up in terms of user-friendliness. 

As soon as I opened the app, the first thing that caught my eye was the colorful pink and white interface. However, there was a catch: everything was in Vietnamese. Fortunately, I quickly noticed the option to switch to English right on the first page. Without wasting a second, I immediately clicked on the English option. 

When I selected English, only the placeholder text for the phone number and the button text changed. The rest of the app’s text remained in Vietnamese. The promotional banners remained in Vietnamese, which was expected since they are image files. It wasn’t a huge deal, but it did create some minor confusion and made navigation a bit clunky. The banner issue is something I’ve encountered in other apps, like Grab and Foodpanda, and it’s always a bit of a letdown. The inconsistency can disrupt the overall user experience.

I never realized how crucial internalization can be for an app until I traveled to Thailand last year. For apps that operate solely in one language, the decision-making is simple. But when an app supports multiple languages, it faces design decisions that can significantly impact the user experience.

Take the default language, for example. What should an app display the first time a user installs and opens it? Should it default to the local language? That works well if the primary audience is local. Or maybe English should be the default? This approach is viable if the app targets a global audience regardless of location.

A more refined option could be setting the app’s default language based on the user’s location. But here's the catch—this doesn’t work well for travelers. For instance, I don’t know Vietnamese, yet I’m trying to use an app in Vietnam. Defaulting to Vietnamese based on my location doesn’t solve my problem. And it's not just travelers; even Vietnamese nationals who don't speak the language could face this issue. Teams need to spend time carefully deciding how to handle the default language setting. Of course, the simplest solution is to let users select their preferred language right from the start.

But that brings up another problem: how to display the language names. If the default language is English and users need to choose their preferred language, displaying the language names only in English characters can be a barrier. Imagine a user who doesn’t know English—they might not even recognize their language in the list of options.

This isn't a hypothetical scenario. I once encountered an app where the default language was Vietnamese. During onboarding, it offered the option to change the language, but "English" was listed as "Tiếng Anh" (the Vietnamese term for English). Now, if a user doesn’t know Vietnamese and is looking for English, how would they figure that out?

The solution? Write each language name in its own script. This approach ensures that users can easily identify their preferred language without additional guesswork. It’s a small detail that can make a big difference in ensuring a smooth and accessible onboarding experience.

Back to my experience—after entering my phone number, I was prompted to verify it with an OTP (One-Time Password) sent via phone call. The instructions on the screen were in English this time, so it seemed straightforward enough. Easy, right? Not quite. 

The next screen was a confusing mixture of Vietnamese and English. It was clear enough that I needed to enter the OTP that had been sent—or, in this case, spoken—to me. And then came the real nightmare in terms of UX.

At this point, I started to guess why this partial translation issue might be happening. But I decided to put that thought on hold and focus on completing the onboarding process first.

I received the call with the OTP within a few seconds, which felt like a smooth experience—at first. But then came the twist. The call was entirely in Vietnamese, and the password itself was spoken in a language I couldn’t understand.

Imagine trying to decipher a string of numbers you couldn’t read or comprehend—it felt like solving a riddle without knowing the rules.

To their credit, Momo seems to have handled the error path well. Below the OTP input area, a helpful message appeared: "Haven't received OTP? Try another way." So, I decided to give it a shot and explore the alternatives.

Here’s what the other options were.

The same translation problem kept repeating across various screens. It was time to troubleshoot.

I exited the app, removed it from the recent apps to completely kill the processes, and reopened it. And voila—the first screen was now entirely in English! Though the banners were still in Vietnamese, the partial translation issue on other screens was fixed too.

It turns out the app needed a full restart to load all the texts in a different language. A better approach might have been to avoid trying to translate everything immediately when a user selects a new language and instead prompt them to restart the app for the changes to take effect.

But here’s some food for thought: what should the language of that prompt be?

Let’s evaluate our other options to get the OTP.

The first option was: "I haven't received SMS OTP. Call me." Oddly enough, there hadn’t been an option to get the OTP via SMS in the first place, so the text didn’t hold much value. It was grayed out, indicating a waiting period before I could request another OTP—which is fair enough.

The second option read: "I want to change my phone number." But since my issue was with the call, getting the OTP via a different number wouldn’t solve the problem.

The third option was: "Call Customer Service." Let’s just say, I wasn’t desperate enough to go down that road.

If you wait till the timeout, the app eventually prompts you to get a call again—one of the options we’ve already encountered. But from a UX and accessibility perspective, this feels limiting.

Shouldn’t there be more than one way to receive an OTP? How would a user with hearing difficulties navigate this process when the only option is a phone call?

A better solution would be letting users receive the OTP via Zalo, a popular messaging app in Vietnam. Many other apps in the country already use Zalo as an alternative to send OTPs, and it would make the process far more inclusive and user-friendly. Of course, plain old SMS would work too!

I could have tried translating the phone call using Google Translate, but by that point, I was already exhausted, and my allocated time for experimenting with tools had run out.

In my view, if Momo isn’t intended for foreigners, they could consider restricting the app’s download on the Google Play Store based on country, as it is listed on their official website. I was able to download Momo despite my Google Play country not being set to Vietnam.

So, would I recommend Momo to travelers, especially those who don’t speak Vietnamese? Unfortunately, not in its current form. While the app might be a lifesaver for locals, it presents a tough challenge for foreigners. Unless you’re comfortable navigating an app in Vietnamese or have someone with you who can assist, the usability of Momo is quite limited.

In short, Momo’s potential as a payment platform is huge, but until the app addresses some of its language accessibility issues, I’d say it’s more suited for locals than for tourists.