How to Scale Internationally: Global Product Design

Most companies rolling out international products that automatically adapt to multiple national markets tend to focus primarily on proper language translation. However, a host of other essential components should not be missed when in the building and management of global products.

A great example is the launch of Apple’s mobile operating system iOS6 in 2012. One of the key innovations Apple fans were so excited about was the announcement of the new Apple Maps app, freshly built internally at Apple, including the world premiere of 3D Maps. However, within days of the launch, the Apple Maps app was judged a public failure, with major issues in search results and location translation (e.g., Berlin became Schöneiche bei Berlin; searching for London in the UK resulted in London, Ontario, Canada; and Ireland suddenly had a new airport). Product launch in more than 100 countries at once is a huge undertaking, and some glitches are bound to occur, but the Apple executives who declared the app ready to be released had overlooked some core learnings.

Product Architecture Design Matters

The key requirement for international product design is to lay the foundations of product architecture that are easily adaptable to different countries. It is crucial to ensure that all text components (so-called “strings”) are structured in a way that they are easy to extract for translation and then reintegration. Creating a capable feature matrix that shows what features appear when is also an essential step. It has to handle more contextual information—such as location, phone region, or phone language—than a purely local product would. Enabling the product’s feature set to adapt to the user’s detected location should not be an afterthought. As different countries tend to have different levels of cellular traffic, product teams have to decide what part of the architecture logic should be on the server, and what part will reside on the user’s device. Some products might also require an offline mode, which is a subset of the features available when the phone or device is not connected to the network. By fully engaging with all aspects of what product architecture is and taking all of these components into consideration, the product will be ready to scale, be it for two or 50 countries.

Performance and server architecture are two more key questions that have to be addressed ahead of time. Ensuring that a product has adequate performance 24/7 in countries across the globe requires a server architecture with an adequate level of server nodes and load-balancing capability. Based on the amount of traffic, product teams have to decide whether they need server nodes in the US, Latin America, Europe, or Asia, since it is more optimal to have nodes closer to regions with high traffic in order to ensure a real-time response. Based on optimized hourly usage curves, the traffic load can be balanced across a 24-hour spectrum—for example, the major West Coast servers can be offloaded by moving traffic to the East Coast when the usage in the East drops. A fully realized global product management is key.

Region vs. Language Matrix

For mobile apps, the best way to detect a user’s country and where their phone was issued is to rely on the regional setting chosen by the user or defaulted out of the box. This can also be combined with the language setting to create a complex matrix of supported regions and countries, rather than languages. For example, that would enable a Chinese national who lives in the US and bought a US phone to have the phone and app display the Mandarin language. Another decision the product team needs to make is the default settings when a language or country is not supported. For example, if the software does not support the Finnish language in Finland, the default should be English. This allows the product to offer preferences and customization.

Complexifying the Feature Matrix

A standard feature matrix will support a number of standard scenarios. For example, if the user is already logged in, they should be able to go directly to the homepage, not be confronted by the login page. However, global product management means increasing the complexity beyond the features that are interacting together. A good global product design example is the Facebook Dating feature, which was first tested in Colombia but was not available to US users for some time. In this case, if the software detects the user’s country as Colombia, it should show the user’s login state and the Facebook Dating feature. However, if the user is in the US, the login state should be visible, but not the dating feature.

Similarly, in the Apple Maps example, the search feature should not surface what appears to be the first logical result, but rather take into account the user’s location. In alphabetical order, “London, Canada” comes before “London, UK,” but if the user is in the UK and types “London” as a keyword, the location in Canada should appear as the second, not first, choice.

Therefore, the search results matrix needs to be weighted by criteria such as the user’s region, determined from the phone settings, computer’s IP address, or user’s current location, recognized by the app. The feature matrix should also support precise, automated decision-making based on context, such as the user’s base country, current location, and language preferences.

Cultural Differences in Feature Interaction

Cultural aspects have an impact on feature interaction as well. For example, a US user would type the character “&” to refer to an intersection when searching for an address, while this character is not commonly used in other countries. Mexicans search for an address using abbreviations, for example, “Col. del Parque” for “Colonia del Parque,” as Mexican addresses are typically long. Icons are also a unique cultural trope and can lead to a lot of misunderstandings. One of the apps I worked on had the British icon for a pharmacy, and my French users were asking why we displayed milk bottles all over the map. While we may take the “commonly understood” symbols for granted, we should not, since visual communication is affected by cultural and linguistic norms.

This can also be applied to A/B testing, a technique that involves iterations of certain product components to identify which of them drives the most successful user behavior. A/B testing for button colors can be influenced by cultural perception. Though the perception of green as “go” and red as “stop” is largely international, there is still a significant difference in cultural perceptions of colors’ meanings. For example, in various countries, the color of mourning can be either black or white, which will generate opposite reactions in users if you use the incorrect color.

Localization, Not Only Translation

The examples above illustrate the difference between localization and translation. Localization takes into account a host of cultural components that impact visual design and feature interactions, going well beyond simply translating texts or audio prompts. To name a few, they include diversity in currencies, measuring systems (metric vs. imperial, or Celsius vs. Fahrenheit), and formatting (date formats are different in the US and Europe), as well as a variation of textual characters and orientation to the design (Arabic reads from right to left, and that has a lot of impact on the ergonomics of a page).

Localization experts look at the text in the context of where the text is situated in the product, the contextual meaning, and how certain languages treat certain contexts; they will also take into account slang or inappropriate connotations and the overall cultural nuance. A localized product is adapted not only linguistically but also culturally.

Setting the QA Team Up to Succeed

When a product reaches the testing stage, a product team has to consider local and centralized testing. Although a number of scenarios can be tested automatically and centrally from headquarters, some core features would benefit from in-situation testing. Driving on a country’s roads will give you valuable insights into the local maps software version; the same applies to testing a festival app with the local cellular network rather than wifi. Testing in the field is more expensive because of the human resources required and the corresponding travel expenses. Typically, product teams encounter tradeoffs between quality and security risks on the one hand and costs incurred due to in-depth testing on the other.

A detailed test plan is essential to ensure that appropriate testing is carried out. It consists of a host of components, including:

• Main usage scenarios in each country
• Peak traffic loads
• Local specificities, such as wifi vs. cellular usage
• Level of internet bandwidth
• Types of devices used

This global product management plan should be prepared and discussed well in advance to ensure that it covers all the main product features and scenarios based on the country rollout once the product launches.

Location-based Marketing

In a globalized world, having a unique brand and product positioning with some local customizations is the most efficient way to go. This means having a core marketing message, which also helps all local product teams to concentrate on unique product benefits. However, adapting local marketing campaigns for each country is recommended in order to resonate strongly with local users and to increase the market fit.

When product teams have input into the go-to-market plan and the budget planning for localization, they also have to consider the local marketing iterations for all the product messaging and marketing materials. This means the teams have to invest time consulting with local marketing teams, agreeing on localized versions, and having all the marketing assets ready ahead of the launch date.

The Challenging but Satisfying Nature of Global Product Design

As we have seen, when teams are engaging in global product design, the key items you need to address in global product management are the impact on product architecture design and the feature matrix, adapted go-to-market plans, and localization. This process can be both challenging and satisfying—given the scope of the market and the management complexity, you will gain incredible experience as a product leader.