Top

Supporting Localization

Enterprise UX

Designing experiences for people at work

A column by Jonathan Walter
February 4, 2019

Users want to work in familiar languages and environments, so companies that build and sell enterprise products to customers from different cultures and in different locales must support these expectations. Doing so requires localization—adapting documents or products to ensure they’re culturally appropriate. However, product teams often overlook this requirement or put off localization until late in the development cycle.

Even when localization is a formal requirement, a product team that is battling a tight deadline or budget constraints may choose to skip localization or defer it until a later release. Their localization effort languishes in the team’s growing pile of UX debt, remaining unaddressed until a senior executive receives an angry phone call from a customer, complaining about the product’s subpar experience in their native language or environment.

How can you, as a UX professional, support localization, help reduce the odds that your product might alienate customers, and avoid contributing to your team’s UX debt? In this column, I’ll provide a localization expert’s perspective on this topic, then describe some practical ways in which you can design user interfaces to better support localization.

Champion Advertisement
Continue Reading…

An Expert’s Perspective

Localization is a tricky topic. People often confuse the term localization with globalization or internationalization. To disambiguate these terms and get another perspective on how UX designers can better support localization, I spoke with Elena Dunne, a terminologist and localization expert at Rockwell Automation, who has over 15 years of experience in the language industry as a localization project manager, consultant, and terminologist.

Jon: First, some level-setting. People often confuse the terms: localization, internationalization, and globalization. How would you correctly define these terms?

Elena: There is no consensus on the precise meanings of these terms in the industry. In general, localization is just what you said: the adaptation of a product to a specific market. We typically discuss localization within the context of software, Web, or digital technology in general.

Localization includes translation and other changes that are necessary to make a product culturally appropriate without breaking its functionality. In other words, localization is about adapting a product so users experience it as if it had been designed in and for their language and culture—even though the original product was based on the mental models of the culture for which the software was originally created, and mental models differ between cultures to a certain degree.

Internationalization is about designing a product in such a way that localization is easier and can be accomplished without the need for rework or product redesign. Microsoft refers to internationalization as globalization. However, most think of globalization as a larger process of economic, social, cultural, and political integration.

Jon: As a terminologist and localization expert, what are the most common misconceptions people have about your role?

Elena: The most common misconception about terminology management is that it is only necessary because of translation or localization. While there is general agreement in the language industry that terminology management allows better quality control in translation and faster turnarounds, there are other benefits of translation, localization, and authoring, especially when taking digital transformation into account.

Let me give you a few examples. If you have a large repository of high-quality multilingual terminology data, you can reduce the amount of data necessary for training a machine-translation (MT) engine to obtain acceptable results. Terminology is at the foundation of controlled authoring, so terminology management is a huge part of effective content strategy. And if we look beyond the domain of localization and content creation, we find that product information management, taxonomies, knowledge management, intellectual property, branding, and compliance all benefit from using terminology management tools, processes. and data. These other domains just don’t call it terminology management.

In your field of User Experience, you certainly cannot ignore terminology—or language in general. Why? We interact with software and Web user interfaces through language. And, in the case of speech technology and the devices that use it, language is the user interface.

Jon: What are the most common localization oversights you notice in software applications, regardless of industry?

Elena: Most software-development tools nowadays enable developers to create better, internationalized software. Plus, the awareness of internationalization in the development community is generally much higher than it was ten years ago.

Most traditional internationalization issues stem from legacy code—for example, code that doesn’t allow text expansion and resizing; lacks support for Unicode and bidirectionality for input, output, and display; or uses hardcoded or concatenated strings. While most development teams should have gotten past these issues by now, many companies still have a long way to go in making both internationalization and terminology management integral parts of their product-development process.

Jon: What are some practical ways in which UX designers can support localization early in the design process?

Elena: Looking beyond code internationalization and talking specifically about language or terms, a lot of general usability principles hold true. Take, for example, consistency. This is not just about maintaining consistency between the user interface and the Help content but also between related terms within a product, across other related products, and with formal or de facto industry standards. In other words, take into account all existing terms before you create new ones, and use both existing and new terms consistently throughout a product. Doing so has a positive impact on your localization cost and turnaround.

When you create a new name for a product or function, document the motivation behind naming that product or function and what it does, then provide that information to translators. When translators understand the meaning behind the words they are translating, they’ll create a higher-quality localized product , and uses will have fewer questions.

Assume that you’ll need to modify some visual elements such as icons or colors and build the product in a way that makes such modifications easier. Using sounds and voice adds another layer of complexity to product localization, and you should consider that as well.

I talked earlier about mental models and how they are the foundation on which we build applications. One tactic that most organizations can fairly easily employ is to get one or more people on the development or usability teams who do not share the same mental model as the rest of the team. In other words, get one or more people from a different culture, then ask them for feedback frequently. More often than not, such conversations will result in light-bulb moments because their feedback will likely challenge the team’s assumptions. There is a huge upside to having a diverse workforce—a goal to which many organizations now aspire.

Jon: If product stakeholders and business leaders are hesitant to fix localization anomalies, how would you recommend that UX designers convince them that fixing them is worth the time and effort?

Elena: This goes back to having a customer focus. Customers can often choose which products to use, and they expect quality in their hardware and software products. After all, why would anyone buy a product that doesn’t work properly? So product quality is no longer a key differentiator, but customer experience is. In a digital world, in which language is part of the product, you cannot create a positive experience for a customer if you ignore the language.

Localization is an essential functional requirement that a product team should set—along with other functional requirements—from the start of a project. Internationalization, or globalization in Microsoft’s terminology, is what enables localization. As digital products and systems become more and more connected, failing to embed internationalization and localization best practices into product development undermines a company’s long-term ability to stay competitive.

Designing for Localization

As Elena has told us, following localization best practices is an essential requirement that extends far beyond simple language translation. Doing so is well worth the time and effort. As UX designers, the decisions that we make directly affect users’ satisfaction with our products, regardless of their time zones, languages, and cultures. Plus, our decisions potentially influence how much UX debt our product teams incur. Here are some practical ways in which you can support localization during your design process.

  • Use standard language. Even if you’re not directly involved in writing copy, ensure that the products you design are free of idioms and slang. For example, while most native English speakers would be familiar with phrases such as playing hard ball or waiting until the eleventh hour, those who are not proficient in English might become confused or, worse, be offended by them. Use clear, simple words in your products that accurately convey their intended meanings. Resist the temptation to use fancy or complex words, even if they look great on the page or sound pleasing to the ear. Simple words usually work best.
  • Place labels above fields. As I explained in “UX for the Industrial Environment, Part 2,” placing labels above fields accommodates the lengthy character strings that often result from translation better than using left-aligned labels does. Left-aligned labels require more horizontal space, risk breaking layouts, and reduce the available space in which the user can input data.
  • Employ redundant coding. Don’t rely solely on color to differentiate elements in a user interface. Doing so would ignore the needs of users with color-deficient vision. Plus, you might run into cultural issues. For example, red means something different to users in China than it does to western users. Most westerners associate green with good or on and red with a problem condition or stop. However, in China, red typically means happy or good luck. Pair color-keyed user-interface elements with icons or text labels to disambiguate their meaning.
  • Make containers responsive. Expansion of the length of text strings is common when translating them into other languages, so minimize the use of bounding boxes and containers with fixed dimensions. This includes buttons. If a call-to-action requires a lengthy text string, use a hyperlink instead of a button.
  • Use familiar icons whenever possible. While you should use labels to convey obscure actions, concepts, or objects, labeling icons unnecessarily can lead to layout issues when translating text strings into other languages. Many icons are now universally recognizable. After years in use, common symbols such as those for Save, Help, and Delete do not require labels to convey their meanings.
  • Avoid setting fixed positions to ensure that content flows naturally. As for responsive containers, any elements in the user interface with fixed or hard-coded positioning risk breaking the layout. Ensure that elements adapt to the content that surrounds them. View your product’s user interface in a language other than your own to better understand how its layout might change.
  • Avoid hardcoding text strings in the user interface. Remind developers to make all text elements easy to extract for translation, including Alt-text, titles, toolbar labels, and menus.
  • Avoid specifying units in the user interface. As for text strings, ensure that a localization specialist can readily adapt all units of measurement, currencies, and dates and times within a user interface based on region and user preference. For example, users in the United States typically prefer viewing measurement data in the Imperial system, using units such as pounds, inches, and feet, while users in the United Kingdom prefer viewing the same information using the Metric system, using grams and meters.
  • Remember to support power users. Keyboard shortcuts and access keys must be localized, too!
  • Take care with images and videos. When sourcing images or videos for your application, avoid showing symbolism or language relating to the human body that might be offensive or confusing to users in other cultures. As Elena mentioned earlier, recruiting colleagues or peers from other cultures who don’t share your mental models can challenge your assumptions. Get their feedback.
  • Make sound decisions. Voice user interfaces (VUIs) are everywhere now. Earlier in this column, Elena said that VUIs introduce a new level of complexity. As Frederik Goossen explains in his UX Planet article, “Designing a VUI — Voice User Interface,” words are all designers have for communicating through a VUI. “This makes it especially difficult in the case of conveying complex information and data,” explains Goossen. “This means that fewer words are better.” Designers must be especially diligent in their use of simple, direct language when responding to users’ verbal queries to avoid misunderstandings, especially when supporting localization. Granted, an application should support a great variety of utterances from users. For example, a user might say, “How do I get to Starbucks?” or “I want directions to Starbucks.” But designers should avoid having a VUI respond using complex verbiage or being too casual in tone, which could confuse or possibly offend international users.
  • Create chatbots, not chatterbots. The same principle of simplicity that applies to VUIs also applies to chatbot user interfaces such as Alexa, Siri, Google, and Cortana. Increasingly, chatbots are multimodal user interfaces with both voice and visual outputs. While most chatbot user interfaces benefit from having visual affordances such as a chat history and interaction cues, ensure that bots reply simply and directly so users communicating in different languages and dialects can still understand the bot’s responses. Moreover, as with VUIs, use bots for simple tasks because they cannot usually understand complex multiclause sentences or open-ended questions. Therefore, a human should step in for more complex user interactions. And, while many companies attempt to channel their brand’s persona through their chatbots—for example, Flo from Progressive or Eno from Capital One—attempting to delight users by using brand-specific slang or idiomatic phrases might sacrifice your giving users the clearest, most efficient feedback possible and cause them to become confused or be offended.

Conclusion

Earlier, Elena spoke about how all systems and digital products are becoming more connected. Plus, they’re connecting in novel ways that might have seemed like science fiction just ten years ago. The multimodal user experiences of our computers, our phones, our cars, and even our household appliances have created a groundswell of opportunity for UX designers. The fact that many of these products cross geographical borders and span multiple languages just increases the number of opportunities, as well as challenges. If we don’t handle these modern interactions with empathy and care, we risk undermining users’ experiences with our products instead of helping them.

Remember, engaging with people who have a different mental model from your own or that of your teammates can help to trigger those light-bulb moments that illuminate potential issues before they become too large for your team to solve later on. Use the tips I’ve described in this column when designing products. Do not put off supporting localization. Empower developers by providing mockups and specifications that already support localization and remind copywriters to do the same. Use standard language in products if people with different languages, dialects, and cultures could potentially use them. Users want—and deserve—to work in languages and environments that are familiar to them. 

User Experience Architect at Rockwell Automation

Cleveland, Ohio, USA

Jonathan WalterJon has a degree in Visual Design from the University of Dayton, as well as experience in Web development, interaction design, user interface design, user research, and copywriting. He spent eight years at Progressive Insurance, where his design and development skills helped shape the #1 insurance Web site in the country, progressive.com. Jon’s passion for user experience fueled his desire to make it his full-time profession. In 2013, Jon joined Rockwell Automation, where he designs software products for some of the most challenging environments in the world. He is UX lead for a revolutionary analytics appliance for users on the factory floor. In addition to his Fortune-500 experience, Jon has contributed his skills to a real-estate startup. Jon rounds out his time by writing and reading anything he can get his hands on.  Read More

Other Columns by Jonathan Walter

Other Articles on Localization

New on UXmatters