A well-known messaging app recently launched in a new international market and ran into some problems they couldn’t quite pinpoint. A subset of users was reporting something impossible: upside-down photos. The developers checked and rechecked to confirm that it was not a coding error.
What they didn’t know was that a certain data network in the new market caused the upside-down photos, because of the way the data was formatted and transmitted. There was no way to find this out without having people in the country test the app, an expensive endeavor for a company with no local office.
Working in international markets is tough, but globalization is a reality you cannot afford to ignore. For many organizations, the decision to internationalize falls into one of two categories: defensive or offensive growth. Defensive growth comes from the desire to learn more about why your product is not growing enough in an existing area. Offensive growth is all about setting a company strategy to own or control a market. These approaches will influence the decisions you make, dictate the challenges you face, and ultimately determine whether a market is worth entering or not.
If the market is worth enough to you, then you should focus on putting the required effort and work into that market. Learn the cultural context you might not be aware of. For example, certain countries dislike using drop-down menus; their presence can significantly impact sign-up rates. And in some countries, people do not have last names. If your product requires using last names, how will that impact your sign-up rates? You can only answer these questions, and more, by gathering local insights. Make sure you have a plan to get these insights and incorporate them into your product from the get-go.
Infrastructure
Infrastructure is an incredibly complicated subject when it comes to internationalizing your product. You must consider infrastructure from two angles: your company’s ability to support or execute in that country and the actual physical infrastructure limitations. Can your company build a product that sufficiently supports a different language or accepts different inputs?
Support infrastructure includes the ability to work directly with users. Much like you interviewed users and potential customers when you built your initial application, you must do this for each location. Knowledge of the local market from the people who live there will provide invaluable information. You can—and should—use this information to develop the features that local people want. Can you set up that kind of infrastructure for your company?
When you think about a country’s physical infrastructure, you should also consider the most common devices and networks in use. In Myanmar, for example, it’s important to know that one of two font packages could be installed on a phone. Because Myanmar was cut off from the greater internet for a long time, it developed its own approach to font rendering (Zawgyi) that is incompatible with the rest of the world (Unicode). If the device was imported from China—a common occurrence—Burmese residents might need to have their font pack loaded by a third party, which could affect the UI. You will only discover small nuances like this if you’re in in the actual country on real devices with real users. Emulation won’t cut it.
Finding Local Insights
I am accustomed to getting around London and most other international cities the same way everyone else does these days: Uber. But when I visited Indonesia to do some testing with a major social-media app, I couldn’t use my Uber app. Every ride I tried to book got canceled, or else the app crashed. When I struck up a conversation with a local businessman, I learned that Uber was illegal in Indonesia at the time, but Go-Jek, a motorcycle taxi service, was not. Everyone in Indonesia gets around on mopeds and motorcycles, so a car service like Uber just isn’t going to work all that well. I had never heard of Go-Jek, but this little company was entrenched enough to prevent Uber from unseating it.
A crucial thing to understand about internationalization is the local context of your app. Cultural norms and the ways that the local competitors have established themselves will dictate your ability to penetrate the local market. Local competitors are difficult to challenge. But you can study and analyze them to understand how to build an app the local market wants and make better decisions about growth.
Facebook is a good example of adapting a product to work for the accessibility levels of the end user. Facebook created Facebook Lite, a version that consumes less data, for use in 2G and 3G environments. Unfortunately, not everyone has the luxury of being able to build two separate code bases. But everyone can consider how the quality of 2G/3G/4G, devices and power availability will affect usability and the user experience.
Translation Isn’t Enough
For many product teams, launching internationally is merely a matter of conducting a quick translation job. Unfortunately, this leaves a trail of destruction and devastation. Well, perhaps it isn’t that bad, but growth numbers are often weak and the launch is widely considered a dud. There are many reasons why translation isn’t enough, but they boil down to language context barriers and UI/UX concerns.
For example, a well-known food-delivery service asked for help with its app in a specific market. Growth in that market was especially weak, even though they had spent a lot of money getting their translation just right. Unfortunately, no one noticed that “driver” had been incorrectly translated from English to “chauffeur.” And users in this market were not interested in what they perceived as an expensive food-delivery service that used chauffeurs.
There are other examples where long strings have broken the UI in a product because the original design called for a certain number of characters. The word “start” in German (Anfang) has a character count of six, which either could be a small fix or break the UI. But, when we look at the Spanish equivalent (comienzo), we find that there are eight characters, which could severely break the UI. Be prepared: You may have to redesign your UI or design an entirely different UI to ensure that it is responsive for the markets you enter.
Internationalizing and Localizing
Nothing beats getting on a plane and interviewing people in the local market. Asking questions and understanding their needs is paramount for companies looking at growth. Unfortunately, this gets expensive fast.
An alternative is to do the same thing with local friends and family in the desired location. There are some pitfalls with this because, typically, friends and family are not testers. They may miss key insights and advice. You don’t know what you don’t know, but when you use friends and family who aren’t accustomed to testing, they don’t know what they know because their common knowledge isn’t an insight for them. What they consider normal, say not having a surname, may never surface.
The advantage of using trained local testers is that they understand local use cases. Not only can they help you identify localized bugs on local devices, they may uncover subtle UX/UI suggestions from local people as well. You can either engage a testing team on your own, or work with a company like Global App Testing, to locate crowdsourced testers. Whichever option you choose, make sure that the teams you engage have experience doing this kind of work.
When to Say No
There is no point in doing localization and internationalization work unless there is a strategic benefit. Ask yourself, “Is this market worth enough to me?” If it’s not, don’t do it. f you’re not willing to put in the time and effort it takes to learn about a local market, why would you expect people in that market to put the time and effort into your product? To get into the local environment, you need to send real people there. You can do that with your internal teams (expensive) or leverage friends and family there (unreliable), but neither option is ideal.
Launching internationally requires having an ability to build from the local perspective, go beyond translation and understand the limitations you might face. If you do your research, you can gain the insight you need to build a compelling experience for your newfound users.
##Callout##
Author
-
Ronald Cummings-John is the author of the definitive book on testing, QAOps Testing in a DevOps World: Continuous Testing Strategies When Frequent Software Delivery Matters (www.qaops.com). His passion for QA has sent him around the world working with the top QA and product teams from companies such as Facebook, Microsoft, King.com, Spotify, Dropbox and many more. Ronald is the co-founder of Global App Testing (www.globalapptesting.com), who are one of the fastest growing technology companies in the UK and run Testathon (www.testathon.co), a hackathon for testers. Connect with Ronald on LinkedIn: linkedin.com/in/ronaldcj.