A Developer’s Guide to UX in App Localization
App localization is an essential step towards good UX in your app. One of the most important qualities you can develop to improve localized UX is empathy with your users.
Join the DZone community and get the full member experience.Join For Free
If you have not yet met the term “user experience,” then now is the time, especially given its huge impact on app localization success.
Your app’s user experience is typically the one thing that makes or breaks the success of your app. It’s simple. If users do not see value in your app, have fun using your app, or simply get something out of it that they appreciate, then they will not use it. Your software will become shelfware. All the days you spent coding and testing will have been for nothing.
How much impact do you have on user experience? Probably much more than you think — and when it comes to app localization, even more.
Why You Never Really Knew About UX Until Now
I know what you are thinking: If UX is so important, why is so little emphasis put on UX compared to the code-writing aspects of software development? There are two main reasons:
- UX is often mistakenly viewed as a marketing or UX specialist-only responsibility, a kind of y-feely domain involving users “on the other side of the wall.” You might get instructions or requests to design or modify an interface in a certain way, but nobody ever seems to explain why.
- Apart from a catch-all approach of “making sure the app user has a good time,” many people only have a hazy notion of what UX is about and cannot explain the little they understand to others.
Even Big Software Vendors Struggle With UX
Try this definition of user experience from one of the biggest software vendors on the planet (yes, Microsoft, I’m looking at you):
“An activity of encounter by a computer user with the auditory and visual presentation of a collection of computer programs. It is important to note that this includes only what the user perceives and not all that is presented.”
This is akin to a restaurant offering cold, dead fish instead of lip-smacking, gourmet sushi. We need a better way to delight users with localized versions of your app, build solid and loyal user bases in different countries, and keep app subscriptions rolling in (if such is your business model).
A Localization UX Issue Sampler
Before getting to a more effective definition of user experience, take a look at some of the ways that poor app localization might negatively affect UX:
- Foreign language text is longer or shorter than the original version and makes the layout look strange or simply wrong.
- Variable handling generates grammatical errors that make localized strings look ridiculous to native speakers of the localization language.
- Minimum font sizes that were acceptable in the default language (the one you have been working in to build the original version of the app) make other languages unreadable.
- Right-to-left and left-to-right language localizations leave users with different impressions or just plain confused.
These examples of UX issues concern technical aspects of app localization, and therefore they concern you as a developer directly. However, there are many more potential UX problems (see below) that will also involve you as you manage app localization cycles, sending text strings off for translation, and working with your product management or marketing colleagues to ready your app for new markets and cultures.
Start as You Mean to Go On
If you are going to build better user experiences into your app localizations, you will need to know what to aim for. So, let’s try another definition of user experience to start off on a better track, this time from the Nielsen Norman Group.
“All aspects of the end user's interaction with the company, its services, and its products. The first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother. Next come simplicity and elegance that produce products that are a joy to own, a joy to use. True user experience goes far beyond giving customers what they say they want or providing checklist features. In order to achieve high-quality user experience in a company’s offerings, there must be a seamless merging of the services of multiple disciplines, including engineering, marketing, graphical and industrial design, and interface design.”
This is far more inspiring. A big reason is that one of the persons contributing to this definition is Don Norman, who invented the term “user experience.” The other person in the Nielsen Norman pair is Jakob Nielsen, who was already reinventing website usability in 1999 with his book Designing Web Usability: The Practice of Simplicity.
UX, UI, and Usability in App Localization
To position things properly for what follows, let’s see why user experience, user interface, and usability are different. Of the three, only user experience encompasses the whole range of impressions, feelings, likes, or dislikes that users have when using your app. That does not mean the other two things are unimportant.
The user interface must offer access to functionality that is of value or of interest to the user. The app and its UI must also display good usability by being clear and simple to use, pleasing to the eye, easy to learn, and efficient (as in the minimum necessary number of taps, swipes or clicks) in taking users where they want to go. UX groups together the quality of the UI and the level of usability, and then adds further aspects. For app localization, for example, this includes the correct use of colors, symbols, backgrounds, and indications of direction (how to navigate a localized page.)
What Is Your App Localization UX Role as a Developer?
While it is true that marketing and product management may spend more time on profiling culture-related app localization requirements, as a developer, you are likely to be involved in ways that go beyond your IDE. For example, you may well handle the translation process, sending content (text, graphics, audio) to translators, integrating feedback from localization reviewers, and making the final localized versions of content available as part of the app package.
Frankly, it does no harm to be sensitized to ways in which not just language-dependent but also culture-dependent elements can affect the UX of localized versions of your app. Then it won’t seem so strange when marketing asks you to change the app screen background image for an app localization into Japanese to one that has brighter colors and a sun-ray effect, because culturally these changes will better match expectations of customers in Japan (yes, really!).
Don’t Make Users Think About Your Localized App
Steve Krug wrote his book Don’t Make Me Think to help people think like a usability expert (a large part of creating the user experience), even if they have a different job role, like being a developer. He aimed his ideas at web applications, but they carry over naturally to mobile apps too. Among some of his pithy suggestions are:
- Don’t make people think. People typically don’t want to have to puzzle over apps to get what they want out of them.
- Apps should explain themselves, at a glance, from the first screen onwards.
- Don’t waste people’s time. Keep text short and sweet, and minimize distances over layouts and through menus.
- The back button is good. If people guess, don’t penalize them. Let them back out again easily.
Further care is needed when it comes to app localizations. The interface and the usability of your app are likely to have been created according to your own cultural norms. However, what may seem natural in one culture may look strange or different in another. For example, this could affect the UX of a localized version of your app in these ways:
- Translation of terms, especially short phrases or single words for buttons. The shorter the phrase, the more important it is to get to the intention behind the phrase and work from that to find the appropriate translation or equivalent for localization.
- Forms for user input. Some cultures (Anglo-Saxon, for instance) often offer three fields for users to enter their names: given name, middle name, and family name. Elsewhere — in Asian countries, for example — the norm may be just two fields. If you insist on offering three fields, you are “making them think,” which from a UX standpoint is not the way to go.
Internationalization and User Experience
The ideas above for improving user experience are more effective when they are integrated into an app from the start instead of being layered on as an afterthought. A similar concept already applies in the internationalization phase that precedes language-specific app localizations.
Internationalization is the process of separating out as much user-facing content as possible from the app, to make it language independent. The separate user-facing content can then be localized into one language after another, according to marketing or end-user requirements.
Internationalization also covers graphics and audio content and by extension can cover any other aspect of an app that is not only language-dependent but also culture-dependent. Platforms like Android and iOS make it relatively easy to separate out content and also provide convenient functions to automatically handle localized formats for numbers, dates, and quantities. On the other hand, while offering considerable help in ensuring good UX, internationalization, like UI and usability, is just one part of the whole user experience of a localized app.
Practical Aspects: Language Length and Font Sizes
Foreign language equivalents of texts in your own language will tend to be either shorter or longer. In some cases, the difference can be dramatic. For example, the word “user” in English is usually translated as “benutzer” in German (twice as many characters) and “utilisateur” in French (almost three times as many characters. Clearly, trying to squeeze all these extra letters into a space tailor-made for the shortest version will cause problems with display and layout, usability, and therefore UX.
Minimum font sizes that work (just) with languages like English may make other more complex language characters unreadable (漢字, for instance). Additionally, line height used for English or similar Western languages may be too small for Chinese and other languages needing greater line heights. Whatever the font size or line height, the characters for any localized language must be readable. This may mean increasing minimum values for all language versions, or possibly using different layout criteria for different localizations (see below).
Double-Length, Pre-, or Pseudo-Localization to Find Problems
Word length problems caused by volume expansion as in the English/German/French example above can be detected by making a double-length version of separated text strings and displaying this double-length version. Text overruns will be much more obvious. However, for app localizations that lead to volume contraction (English to Chinese, for example), the services of a native speaker with an eye for layout may be indispensable to identify where too much blank space is being generated and where fields, buttons, or layouts may need to be modified.
If your app runs on a PC or via a PC browser, using a keyboard, watch out for hotkey or macro-style key combinations that may not be available on keyboards for other languages. You may find it better to use function keys (F1, F2, F3, etc.) which are often available no matter which keyboard is being used. Alternatively, avoid this kind of hotkey functionality from the design stage onwards.
Handling App Localization UX Issues Caused By Layouts
A localized version of an app can lead to unsightly changes in layout, even when automatic adjustment is used (like Auto Layout in iOS). The examples in the previous section indicate why this can happen. A layout that lined up nicely in the default language may become distorted as it struggles to display foreign language equivalents. Efforts to standardize on one set of dimensions for a language with medium space requirements may not work either, especially when volume expansion and contraction can double or halve text lengths, respectively.
The best solution or compromise may be different in each case. It is likely you will only recover a reasonable UI and UX that works for different localizations by trying different options and getting native speaker input. However, some options might include:
- Using drop-down menus to disguise length differences (this may lead to more clicks or taps being required, thus degrading usability)
- Dynamic layouts that display longer texts on two lines instead of one (visually, this may look inconsistent between different localizations)
- Programmatic changes to layouts, driven by the language or locale (country/language combination) of the localization. This is a possible solution to the changing number of name fields between different localizations (see the Don’t Make Users Think section above).
Right-to-Left and Left-to-Right Displays
Right to left (RTL) languages such as Arabic and Hebrew not only change the direction of text compared to English, for instance, but they also change notions of time and sequences of actions. RTL native language speakers may expect to see a “trash can” on the left of the screen rather than the right, because that is where they naturally end up before taking a final action to throw something away. Similarly, “next” and “back” buttons will logically be on the left and the right, respectively, instead of on the right and the left, as in English language screens. In RTL displays, time runs from right to left. Watch out also for icons used to indicate functions such as text justification. They too will need to read from right to left, for example, with a “ragged left” icon, instead of a “ragged right” one.
App interfaces that are highly dependent on lateral movement to make their logic and user experience work properly for LTR languages may need to be rethought and redesigned for RTL languages if the same quality of UX is to be achieved. This is yet another aspect that is best handled in the initial design phase, rather than trying to change an existing app. Sometimes you will not have the choice. However, if you are in the fortunate position of starting to design a new app, you can take these aspects into account, according to the different localizations you think you will require. You can also avoid the issue by using a vertical navigation design from the start, which obviates the need to start either from the left or the right.
UX Issues With Partial Localization
By now, you may well realize that localizations may be partial or incomplete in a number of different ways. Unfortunately, few if any partial localizations allow reasonable levels of user experience.
Mixing of phrases in different languages goes against the overwhelming preferences of native language speakers to buy and use products that work in their language. In mixed LTR/RTL language situations, the result may be even worse.
Partial Cultural Localization
Inappropriate colors and symbols can also wreck the user experience in a localized version when the original or default items are reused without due care and attention.
Partial Localization of Formats
Omitting to change number separators from periods to commas, for example, when localizing into French from an initial English version, will make the interface look strange to a French speaker. With automatic formatting methods built into various operating systems, there is little excuse for getting this wrong. Some uses of variables may need more thought, however, to make sure that grammatical structures are converted properly into their localized equivalents.
One possible exception to partial localization is the localization of only the promotional information about the app for use in an app store, such as Apple App Store or Google Play. This ploy allows marketers to see how many native speakers download the app, helping the marketers to gauge sales potential for a specific localized market. However, this can only be a temporary situation, and the product must then be properly localized or revert to the full default version afterward to avoid user disappointment and possible negative feedback.
Translation Contexts and Glossaries
In Spanish, the English word “run” can be translated in more than 100 different ways. If a user is using a localized map app, “run” might mean a jog from A to B, but for a home automation app, “run” might mean “execute a program” as in setting the alarm, or switching a house into night mode. Context is vital in such cases, especially when there's only one right choice and so many other wrong ones.
Translation notes and comments that you append to text strings help translators pick the right translation, maintaining user experience quality for the localized language. Useful information includes:
- Subject context, as in the feature or domain most closely related to the word.
- Sentence/syntax context (for instance, whether the word is a noun, a verb, etc.).
- Definition, or an alternative way of expressing the word.
- Specific usage about how the word is being used in this specific case.
A translation glossary can also help preserve a good user experience in localized versions by ensuring that certain words are always translated in the same way, that brand names remain untranslated, and so on. Such glossaries should always be reviewed by native speakers before being distributed for general use.
Once again, remember that translation must sometimes go beyond words and make sure that cultural differences are properly reflected. On the Google home page in English for example, there is the link entitled “I’m feeling lucky.” In some cultures, luck is viewed differently, and the phrase may be changed to “I choose to trust in God” to correspond better to native speaker expectations.
App localization is an essential step towards good user experiences for your app in international markets. However, it needs more than word-for-word translation. As a developer, one of the most important qualities you can develop to improve localized user experience is empathy with your users. This is, for instance, the understanding that what looks like a small detail from a non-native speaker’s point of view can sometimes derail the user experience for the native speakers. By working with your marketing and product management colleagues, you can then design and develop apps that combine efficiency in coding with excellence in user experience, boosting sales, adoption, and customer loyalty wherever your localizations are applied.
Opinions expressed by DZone contributors are their own.