How to build international products to scale

In September 2012, Apple launched iOS6 with its usual fanfare, and one of the key innovations Apple fans were so excited about was the announcement that this version of the famed OS included a new Apple Maps app, fresh off the internal press from Apple, including 3D Maps as a world premiere. Within days of the launch however, the Apple Maps app was a bust, with major issues in translation of famous locations (Berlin, for example, now called ‘Shoeneiche’), clunky search results (searching for ‘London’ in the UK resulted in ‘London, Ontario, Canada’) and unacceptable visual glitches in map data in a number of countries (especially the 3D map data). Launching a product in over 100 countries at once is a huge undertaking of course, but the executives who declared the app ready for launch had overlooked some core learnings of international product launches.

Most companies looking to roll out an international product (as in, a product that can be launched and automatically adapted to multiple national markets) are focused on ensuring that all texts are correctly translated in the local language. However, as the example above illustrates, there are a host of other components that go into planning for and building truly international products.

Impact to product architecture

First of all, the architecture of the product needs to be conceived with international adaptability in mind from the ground up. A few examples of that are: ensuring that all text components (“strings”) are structured in such a way that they are easy to extract for translation and then reintegrate; creating a feature matrix (a logic behind the visible product that decides which features appear when) that is complex enough to handle location, phone region, phone language, etc.; allowing for the feature set of the product to adapt to the user’s detected location; what part of the logic can be on the server, or has to be on the phone (client-side) to account for countries with higher cellular network latency. All of these components and more can be factored in to make the product easily scalable to 2, 5, 10, 50 countries…

Performance and server architecture are also key items to have in mind: ensuring that a product has the adequate performance 24/7 in countries across the globe requires a server architecture with the adequate level of server nodes (based on expected traffic, do you need server nodes in the US, Latin America, Europe, Asia,…?) and the ability to respond in real-time even in cases of heavy traffic load. This will depend on hourly usage based on which countries use your product most at which time, so load can be balanced across a 24-hour spectrum based on optimized usage curves.

Region vs language matrix

For mobile apps specifically, the best way to detect what country the user is from (whether or not his phone is connected to the network) is to rely on the regional setting chosen by the user on his phone (or defaulted out of the box). This can also be combined with the language setting (for example, a Chinese national who lives in the US and bought a US phone but wants the phone and app to be in mandarin) to create a complex matrix of supported regions/countries vs languages. This allows the product to have as much flexibility as possible in terms of the customers it serves, but also know which setting to default to when a language or country isn’t supported (for example, default to english in Finland if we don’t yet support suomi)

Complexifying the feature matrix

A standard feature matrix is going to support a number of standard scenarios: for example ‘if the user is logged in, show logged in homepage and not the Login button’. However building for international means allowing for additional complexity beyond just features interacting together: for example, ‘detect user’s country - if Columbia, show logged in state and Facebook Dating feature; if US, show logged in state but no Facebook Dating feature’ (as the Facebook Dating feature is being currently tested in Columbia but until very recently was not available to US users).

In the example concerning search results in the Apple Maps app above, the Search feature cannot just surface what appears to be the first logical result (in alphabetical order, ‘London, Ontario’ or ‘London, Canada’ comes before ‘London, UK’) but needs to also take into account the user’s location (if the user in Toronto types ‘London’ as a keyword, then ‘London, Ontario’ is a valid result; if the user is in the UK, much less so). The search results matrix therefore needs to be weighed by user’s region (determined from the phone settings or from the computer’s IP address) or user’s current location (determined by the app directly).

More generally, the feature matrix needs to be able to support more precise automated decision-making based on context (which country the user is accessing the product from, where the user is, which language the user is favoring, etc.)

Cultural differences in feature interaction

Cultural aspects also impact feature interaction: for example, when searching for an address, a US user will use the character ‘&’ for an intersection but a Mexican user will not search for an intersection (or use the &). The Mexican user will search for the address via abbreviations, as Mexican addresses are long (they display over 6 lines, which the interface needs to take into account). Icons are also a uniquely cultural trope and can lead to a lot of misunderstandings: in one of my apps the British icon for a pharmacy had my French users asking why we had bottles of milk all over the map!

This can also be applied when A/B testing an app or website (testing iterations of certain components of a website page to identify which will drive the most successful user behavior): A/B testing for button colors for example can be heavily influenced by cultural perception - though the perception of green as Go and red as Stop is fairly international at this stage, there are still large difference in the meaning of black vs white for example (the color of mourning is black in certain countries, and quite the opposite, white in certain others).

Localization vs translation

The examples above illustrate the difference between localization and translation. Localization takes into account a host of cultural components that will impact the visual design and feature interactions, beyond simply translating texts or audio prompts. Localization experts will look at the text they are translating in the context of where the text is situated in the product, what the contextual meaning is, how certain languages treat certain contexts, slang or inappropriate connotations and overall cultural nuance.

I highly recommend working with localization agencies such as Moravia or SDL when you are building for a big international rollout, as they have the expertise and resources to support this aspect of localizing a product.

Setting the QA team up to succeed

Once the product is being built, trade-offs will need to be made in terms of local vs centralized testing. Though a number of scenarios can be tested automatically and centrally (at headquarters), some core features will really benefit from in-situation testing, which of course has a cost in terms of deploying and sourcing human resources, as well as travel expenses. The trade-off will usually be around quality and security risks vs costs incurred to test in-depth (and possible impact of a failed launch, in the Apple Maps case).
Ensuring that appropriate testing is carried on will require a detailed test plan that takes into account the main usage scenarios in each country, the peak usage loads, and certain local specificities such as wifi vs cellular usage, level of internet bandwidth, type of devices used, etc. This plan will need to be prepared and thought through well in advance to ensure that it covers all the main product features and scenarios based on the country rollout plan once the product launches.

Central vs differentiated marketing

In an increasingly globalized world, having a unique brand and product positioning with some local customizations is the most efficient way to go. This means also having a core marketing message that is the same everywhere, which also helps all your local teams hone in on the unique benefits of the product. However I recommend leaving room for some level of adaptation locally, especially with regards to marketing campaigns, to increase market fit and resonate as strongly as possible with local users.

These are the key items you need to have in mind when rolling out global products. All of the above can be applied to global mobile apps, websites, software tools, data analytics dashboards, etc. Overall, building and launching international products is both challenging and hugely satisfying. The scope of addressable market and the complexity management it requires make for a great experience as a Product leader, and these projects are unique in terms of scale and breadth, including the size of the teams involved.