Regionalizing Your Mobile Designs

Regionalization means considering the entire context of people’s different needs in other parts of the world, not just hiring some service to change the display language.

Do not just let anyone write a story that says “translate the website” but think about the entire range of things that can change when you really offer your app or website in a new region.

This is a HUGE topic so we’ll start with these very long bullet lists, and I encourage you to use the rest of the article to find the details of each one that applies. Read it all if you can, but if not — or just using it as a reminder or reference for your team — then search inside or scroll to find the relevant bits:

All of your content must be in a CMS (Content-Management System) database, and absolutely no content should be hardcoded into the presentation layer.
This means absolutely all of your content—including images, audio recordings, alt text, email messages, PDF guides, video explainers, and knowledge-base articles for customer-care representatives. Everything!
Content should be in UTF-8, or Unicode, so whenever your product displays content, it can support any character, in any language. There should be no call for ASCII limits anywhere.
Make sure your input fields are not regionally specific. For example, your name and address fields probably make a lot of assumptions that aren’t true for other regions.
Automatically set region, language, currency, and other display values, either by using the user’s device preferences or by using location detection as a proxy and making best guesses.
Choose the set of languages you intend to support—based on your users’ actual locations and what they can understand, not on what you feel is right or on global averages.
Don’t make assumptions about a base language. Instead, check regional standards for dialects and variants.
Because there is no language that people universally understand, don’t set any language as the default. Instead, build a set of fallbacks for each region or a user-preferred language in cases where their top choice isn’t one you support.
Allow users to change any of these settings, in case you’ve guessed incorrectly or for collaboration or shared devices.
Keep track of your users. Remember, they don’t change just because they’ve traveled to another country. They still speak the same language and buy things in their home currency. Automatically set language once, then leave it alone.
Think about how changes to language might impact your user-interface (UI) design. For example, right-to-left languages should probably invert most of a user interface. Can you do that?
Understand regional laws and policies such as privacy restrictions. These often involve more than just UI changes and might require special handling of personal data or requests for clearing private data.
Don’t assume anything about your local audience is true everywhere. Even simple things such as mobile-network speed are not universal worldwide. How does this change the fundamental way your product should work?

Now we’ll get into details and tactics about how to design for different regions, as well as describe how to format specific attributes such as date, time, currency, names, and units of measurement:

About 2 billion people speak right-to-left languages. Global products need to be able to work with flipping the entire UI.
Flip the ENTIRE UI. Right-as-forward should flip, and reveal arrows should be on the left for right-to-left languages.
Conversational UIs like “Send message to” then a picker won’t work for many other languages where the object of the sentence should be first if you just translate. Can you re-order for each language, or should you avoid these pitfalls entirely?
About half a billion people use one or another (different from “normal” arabaic numbers) set of easetern-arabic numerals. These are still base 10, but the gyphs are the same.
- Also, the zero can be confused with a decimal, so refer to regional formatting carefully to be sure your numbers are readable.
Abbreviations and jargon often do not make sense or do not translate well. Start by making sure the native language of the app works for every user, and it will work better for other languages.
Don’t translate organization names, or localize spelling of common features. Pearl Harbour, for example, is not a real place (see the extra U).
Only about 60% of countries use a comma as a scale delimiter for large numbers (thousands indicator), and a decimal point to indicate a break between whole numbers. Regionalize all figures so they are easily and accurately read.
Currency symbols are not always in the same place, so must be able to be before or after the value.
Lots of countries share currency symbols. $ is used a lot of places, so if ambiguous (along borders, lots of trade with other countries, etc) use or add the international abbrevion. USD is for US Dollars, for example.
- Tip! Once you get currency localization, use it to make all your prices read better. 99¢ is much more easy to read and appealing (more sales!) than $0.99.
Never store dates or times as strings but as temporal data in UTC (Coordinated Universal Time), then let the product localize it and present in the current time zone.
Always display time zone, and UTC offset. Don’t worry about time zone abbreviations being non-global values (lots of repeats) as it’s just enough to reassure users you aren’t giving the wrong time, from the place they traveled last week or where your service is located, but local to them.
24 hour time is “24 hour time,” not military time or anything else. 12 hour time is “12 hour time,” not normal time.
10/1/2020 and 1/10/2020 are the same date in two different regions, but which date? 10 January or 1 October? Don’t just change to the right order for the region, but when you can possibly fit it, just letters for months. 1 Jan 2020 is pretty clear. Also you can often drop years and it will fit just fine.
In some languages such as French, the convention is not to capitalize the names of months. Follow regionalization rules carefully and precisely, don’t assume anything.
Many countries invert the display of given and family names, prefer to use all caps for family names, or have other display conventions with which you may be unfamiliar. Addresses are even more complexly variable.
Don’t impose any formatting on names or addresses unless you literally have to. Only certain banking, credit reporting, and a few other government functions actually need separate fields. Everyone else can just use one big “Name” field, one big “Address” textarea. Users will fill it in right, services like Google Maps and Places can parse it.
Unit sets such as Metric or English are probably not what you’re used to. Never, ever refer to your regional default as Default, Normal, or Standard.
In the US, or where you work with US users, the two labels should be “Metric” and “U.S. Customary.” Imperial or English is something else and not a unit set, respectively.
Explain what the units are when letting users pick a set from a list to make it clearer. Not everyone understands the difference.
There are unusual regional units. “Imperial” and “Latin America” are both unit sets I have also added to products.
Translating values to other unit sets should follow the same rounding rules. 2.1 miles should convert to 3.4 km, not 3.37962 km.
Don’t convert all numbers. Metric thread sizes are nonsense when translated, for example.
Don’t convert degrees of latitude and longitude in positional data. Yes, I’ve seen that.
Spaces in formatted numbers, or value/label pairs must never break or wrap to the next line. Use non-breaking space characters or other formatting techniques. The degree symbol follows without a space 67° F.

The earlier you understand all the complexities of regionalization, the more quickly you can make decisions about how to solve your short-term problems—with the least wasted effort or technical debt—and the better position you’ll be in for either your next major release of an existing product or an entirely new product.

Additional Resources

I am not perfect at this, but when I find good sources for more, better, or just more interesting takes I add them. Here is a great Twitter thread on how some regional naming conventions utterly do not comport with western “firstname/lastname” standards, and how those standards are pretty rigid so you might not know because people make fake westernized names to fit onto visas, into employment databases, etc. Don’t be like that!

https://twitter.com/Hung_TT_Nguyen/status/1503936865916919813

Full Article, Part 1

Originally published at: https://www.uxmatters.com/mt/archives/2020/11/regionalizing-your-mobile-designs-part-1.php

The Internet can make the world seem very small, but a lot of the digital products you’ll work on must eventually work well for the billions of people outside your home country.

“Easy!” some product manager might say, giving your team a story to add multiple-language support to your app or Web site, maybe add a few specific features to make it acceptable to your new audience or local governments, and upload it to the app store.

But there’s much more than autotranslating to a new language to prepare your product for another market. A lot of the problems you’ll encounter in new markets are likely to emerge from your translation being culturally insensitive or just your being unaware of how different things can be in other regions.

Implementing Regionalization

Regionalization means considering the entire context of people’s different needs in other parts of the world….

Instead of just translating a site or app, you should think about regionalization. Product teams too often misunderstand region to be the same as their sales regions, then conflate region with language and various settings. But we don’t mean that.

Regionalization means considering the entire context of people’s different needs in other parts of the world, not just hiring some service to change the display language. There’s a lot to it, so for starters, here’s a list of some things you should think about when planning to offer your Web site, app, or other digital product in additional regions or around the world:

All of your content should be in a CMS (Content-Management System) database, and absolutely no content should be hardcoded into the presentation layer.
This means absolutely all of your content—including images, audio recordings, alt text, email messages, PDF guides, video explainers, and knowledge-base articles for customer-care representatives. Everything!
Content should be in UTF-8, or Unicode, so whenever your product displays content, it can support any character, in any language. There should be no call for ASCII limits anywhere.
Make sure your input fields are not regionally specific. For example, your name and address fields probably make a lot of assumptions that aren’t true for other regions.
Automatically set region, language, currency, and other display values, either by using the user’s device preferences or by using location detection as a proxy and making best guesses.
Choose the set of languages you intend to support—based on your users’ actual locations and what they can understand, not on what you feel is right or on global averages.
Don’t make assumptions about a base language. Instead, check regional standards for dialects and variants.
Because there is no language that people universally understand, don’t set any language as the default. Instead, build a set of fallbacks for each region or a user-preferred language in cases where their top choice isn’t one you support.
Allow users to change any of these settings, in case you’ve guessed incorrectly or for collaboration or shared devices.
Keep track of your users. Remember, they don’t change just because they’ve traveled to another country. They still speak the same language and buy things in their home currency. Automatically set language once, then leave it alone.
Think about how changes to language might impact your user-interface (UI) design. For example, right-to-left languages should probably invert most of a user interface. Can you do that?
Understand regional laws and policies such as privacy restrictions. These often involve more than just UI changes and might require special handling of personal data or requests for clearing private data.
Don’t assume anything about your local audience is true everywhere. Even simple things such as mobile-network speed are not universal worldwide. How does this change the fundamental way your product should work?

Now, let’s dive into a few of these considerations in more detail, focusing just on things that relate to the user interface to keep the scope reasonable.

Doing More Than Translation

Rewrite the text in the new language to ensure that it has the proper structure and uses other appropriate aspects of a specific language.

Of course, you must provide the content in your digital product in other languages. But don’t create your entire design in your product team’s native language, then just translate the text to the other languages. Instead, render, or localize, the text into the language your intended local audiences would understand. Internally, it would be best to avoid the use of the word translate to ensure that no one thinks they can fake it and just use Google Translate.

Don’t just translate individual words or phrases. Instead, rewrite the text in the new language to ensure that it has the proper structure and uses other appropriate aspects of a specific language—such as gendered words and plurals.

The context of a phrase you’re converting is critical. For example, if a translation service saw the word close without the context of the corresponding user interface, they wouldn’t know whether it means near versus far, refers to a process function such as closing a ticket; or means to close a dialog box, window, or app. Any number of words might be appropriate for each of these meanings, but the wrong one could be confusing or even dangerous.

Too often, translators receive words or individual phrases in isolation, without any order or context. Instead, you should integrate translators with your team. This would ensure they understand the product and can see the entire user interface and its interactions, so they can understand what they’re labeling and know what user interface to associate with the text.

Because of the large number of users who might not know an app’s primary language or be native speakers or who do not speak a dialect that varies enough from a language they know to be confusing, you should avoid using slang, jargon, colloquialisms, or metaphors, even in your base UI language. Avoid jokes or anything else an international audience might not understand or that some users might find insulting.

If your company uses very casual marketing language or you’re dealing with large amounts of written content such as articles or reviews, handling this kind of text is very different from localizing UI language. You’ll need not just dedicated translators but probably localized marketing and editorial staff as well, to make sure the content keeps the proper tone and makes sense.

Using People, Not Just Tools or Services

You need to manage the relationship with your translator, monitor their output, and make sure they do translations completely, competently, and consistently.

In modern business, it seems that everything gets outsourced these days, including translation services. As with any vendor, you can’t just throw your content over the wall and expect good results. You need to manage the relationship with your translator, monitor their output, and make sure they do translations completely, competently, and consistently.

One approach to doing this is working with your content manager or content designer. (You should have one of these anyway.) Someone on your team should be a writer and focus only on that work. They shouldn’t just create text and labels but also manage the content by creating and maintaining documents in which all the text stored, as well as style guides that indicate how to write content and a glossary of terms.

You can see how this would help with localization. You wouldn’t need to have anyone go page by page. Instead, they could start by translating tricky technical or branded terms. By using this approach, you can make your text more consistent and better structured.

Plus, you should try to engage locals who are familiar with your product—at least to review the output of the translation service. They could even help write the text and would often be happy to do so. Many organizations already have offices around the world or partnerships with local distributors, sales, or repair or customer services. In my experience, they’re almost always thrilled to have someone from corporate headquarters ask for their help and are willing to put in the time, as long as you compensate them for the extra work.

Not Fearing Other Languages

Do not avoid implementing other languages such as German just because their words are generally longer, making it impossible to fit long words into limited spaces.

While the words of different languages do vary in length, they’re generally within 10% of each other’s length. Even text in written languages that employ ideograms or logograms, such as Chinese, does not end up being notably shorter than alphabetic languages such as English.

Misconceptions about the differences in word length across languages often result from bad translations, which typically end up being very literal, formal, and, therefore, long. If you instead render the content properly and consistently in each language, the text length should be similar.

Leveraging Style Guides and Branding

If you don’t already have a written style guide or glossary for your digital product, now is the time to create one. You probably have a fairly consistent set of words and phrases you use to refer to functions, features, products, company divisions, and so on. In addition to your having a writing style guide to help ensure the consistent use of text, the localization effort makes having a style guide for each language critical. Create equivalent words and phrases for each language’s style guide.

Teams often distribute localization efforts across several people, then do everything at once, instead of working on it bit by bit, with the whole product team overseeing the results, as you built the original product. Without having such style guides, inconsistencies and inaccuracies in your internal and technical terms inevitably creep in.

Branding—for product names, taglines, catchphrases, and individual product attributes— all too often does not get translated. This is a mistake. Confirm that the branding text is relevant, understandable, and not locally insulting. Localize as much branding text as you possibly can.

Offering a Complete Experience

In addition to displaying the text of your Web site or app in the localized language, you must also translate the text of all the PDF documents you let people download, email and SMS password resets, shipping notices, and absolutely everything that is part of the customer’s experience.

Interactions must also be consistent. Too often, organizations offer most or all of these ancillary digital features in other languages, but they do not inherit the settings from the app or Web site. For example, if you have a setting for language, there’s no need for a setting for email language. Once users set regionalization features, save their settings, and use them by default for downloaded documents, email messages, and everything else.

Also, don’t forget to translate the following:

metadata for Web site crawlers—Doing so improves your search results.
alt text, element names, and ARIA labels—This makes your content more accessible to all.
app-store descriptions—Translate all content, including change logs.
app-store images—Never use US-English screenshots for app stores outside the US.
other marketing content—For demo videos, at least provide captioning options in multiple languages.
Help documents and user guides—This should include all user assistance.
customer service—Your company probably provides customer service both online and by phone.
social media—Offer both localized versions and links to whatever social-media platforms are preferred or available in different regions.
legal documents—These include privacy policies.

Employing Default and Fallback Languages

Consider creating a table of the most likely fallback languages by region. … English is not a suitable, global fallback or default in much of the world

There are around 6,500 languages in the world. Despite English barely edging out Mandarin Chinese for reach, by no means does everyone speak English.

Don’t let bias creep in and assume that everyone speaks your language or that the most popular second languages locally or worldwide are what the people using your app or Web site can actually read and write. Obtain the actual data for the regions in which you’ll market your product or your audience who would use your product. Try to find out the specifics about your users. There is no average person, so your specific audience could have very different needs from the rest of their region.

Many things about language usage are more complex than you might think. For example, there’s really no Chinese language, but various dialects. Only about 70% of the Chinese population speaks Mandarin. Often, you can work around such language issues by using simplified or generalized language. Shared written languages are often easier to generalize than spoken languages. Therefore, you’re in a better position if you’re designing UI elements than if you were distributing written articles or producing TV shows.

A common generalized language for the Americas is Spanish. But the Spanish dialect that people speak in Europe, Castilian Spanish, is relatively uncommon there. Plus, among the more than 20 countries that officially speak Spanish, there are some ten officially recognized regional dialects. However, many of these countries share a Latin American Spanish, ISO es_419, for official documents, which people in most Central, South American, and Caribbean countries can use with adequate results. But if your audience is in Mexico or the US, they use a fairly different dialect, so it might not work for those users.

Don’t fall back to English or whatever your native language is. Instead, consider creating a table of the most likely fallback languages by region. In many of the largest countries in the world— for example, China, Russia, and Brazil—less than 10% of the population speaks English. Therefore, English is not a suitable, global fallback or default in much of the world. In general, don’t specify any one default language. Instead, use regional settings and your knowledge of your users and their regions to offer them the most suitable language.

Selecting a Language

It rarely matters where the user is right now, but instead, where the user lives or what language they know well.

We’ve all seen a Web site whose first page is a giant map of the world, with a list of countries and perhaps a subordinate list comprising the languages that are spoken in that region. This is a terrible, out-of-date design practice for many reasons. We can do better using simple Web technologies—and even better for mobile apps. Instead, use automatic methods of selecting the most likely language for the user, then let the user change it easily.

Automatic settings are easiest to implement in mobile apps: you can simply read the device language from the phone or the regional settings from the app store. Anyone who wants to use your app would certainly want it to be in the language they use on their phone or tablet. However, if you don’t offer their language, the fallback rules come into play.

Avoid using location services such as GPS (Global Positioning Systems) to determine language. It rarely matters where the user is right now, but instead, where the user lives or what language they know well.

On the Web, determining location has always been more difficult. However, recently, the Geolocation API (Application Programming Interface) has gained good browser support and provides accurate information. However, not all older browsers support it. Plus, the user has control and might block access to this information.

The fallback is IP (Internet Protocol) location, which is often troublesome. However, issues regarding the wrong location are generally unimportant for regionalization. Many browser sessions return IP addresses for a service provider’s home-office location instead of the user’s computer location, which could be a problem for weather reports. But at least it’s usually in the user’s home country, so it works well enough for our purposes.

Changing Localization

A key thing to remember is that people neither change much nor change quickly. Don’t switch localization settings such as language just because the user is traveling. Save the user’s settings and make them persistent for the user. But also allow the user to change these settings. There are plenty of use cases in which users might want to change their localization settings. For example, a fallback language might not be the best choice, so users may want to select another location or language. They might share a computer or be collaborating with others. They might have first visited your Web site outside their home region, making their first visit an anomaly. They might be using a VPN (Virtual Private Network) for privacy, which obscures their location. They might want to change only some settings such as units of measurement, but keep the UI language the same. Allow the user to make individual changes, without assuming they also want to make other changes.

Don’t require users to restart their session. In fact, you should even avoid their having to refresh a page, which wipes out whatever they’ve already selected and reduces the value your product to them.

Communicating Localization Settings

Whenever the user can select a language, be sure to use text labels to indicate the current language if at all possible.

Be very careful with the use of icons for any localization settings. The most common icons depict national flags. This can sometimes be politically contentious even for regions, but is simply incorrect for language and other settings.

Whenever the user can select a language, be sure to use text labels to indicate the current language if at all possible. Never label a function that lets the user change the language using the language that is currently selected. The users who need to change the language might not be able to read a label in the current language.

The one thing that should never be translated: the labels in the language picker. Instead, always label languages in their actual language—for example, as follows:

English
Español Centroamericano
汉语

Users who encounter a user interface in a foreign language quickly notice text in their own language. They might also recognize languages other than their own more readily in their own language than languages whose labels you’ve translated to the same language.

Next: Displaying Regionalized Content

So far, I’ve covered the concepts of regionalization and selecting the language for a region—both automatically and manually—and described some of the pitfalls you might encounter in selecting languages and creating processes to convert your app or Web UI language.

In Part 2, I’ll get into the details about how to design a user interface to support some of the more likely changes in the display of regionalized content—both broadly and in details such as decimals, currency, dates and times, and supporting input to accommodate the ways names and addresses vary worldwide.

Full Article, Part 2

Originally publised at: https://www.uxmatters.com/mt/archives/2021/01/regionalizing-your-mobile-designs-part-2.php

Planning Your Design for Global Use

You should consider the worldwide reach of your product and what other languages or language conventions could mean for your assumptions about how people use your user interface.

In addition to the functionality differences I mentioned earlier, there are many things in your designs that simply converting text to other languages can impact. If you fail to consider these, you’ll end up with a product that’s difficult to use for many users—or that could make it impossible to enter some markets.

One important thing to consider is the twelve languages that are written right to left, including Arabic, Azeri, Persian, and Hebrew. About 2 billion people speak such languages, so this is an important consideration. However, many teams build user interfaces that assume left-to-right text. For example, I generally build lists with left-aligned labels, more information to the right, and optional functionality such as a menu in the rightmost column. The user first finds the information’s label, then scans across the additional information and the options to the right. Keeping the same design grid, but flipping the direction of the language would make this design hard to use at best. Does your platform support flipping an entire user interface depending on language selection?

Likewise, many teams agree that forward is rightward, so when building forms, they place submission buttons on the right and Cancel buttons on the left. Plus, selection lists that load new pages place a right-pointing arrow at the right of each line to go forward; a left-pointing arrow at the left of each line to go back. Consider how these assumptions about left and right that are based on users’ behaviors would work if you flipped the rest of the UI conventions for right-to-left languages.

Even just the order of written items can cause problems with your designs. For example, if you like to design very conversational products, as I do, you might have a user-interface element that comprises the phrase “Send confirmation message to,” with a drop-down list of users following it. This sounds very reasonable, and you could even easily reorder the elements for right-to-left languages, but you could not translate this user interface to the many languages in which the object of the sentence—the person to whom the user is sending a message—should appear first rather than last. Should you place the list of users first? Is it possible that your platform could support that sort of UI change in concert with a language change, or would you need your designs to avoid this sort of conflict?

Right from the start, you should consider the worldwide reach of your product and what other languages or language conventions could mean for your assumptions about how people use your user interface.

What to Translate and What Not to Translate

Avoid introducing abbreviations or jargon in titles or subheadings. Instead, spell out words and explain abbreviations or acronyms when you first introduce them in the text.

Our product-design processes use lots of jargon, brand names, and abbreviations. All too often, we use such terms without much thought in our final product designs. We can’t always avoid their use entirely, but we can use them intelligently to ensure that all users can understand such terms better, and they work when the user selects a different language.

No matter how much your product owner insists that all users are trained experts or are familiar with your system, they might not be familiar with it. Despite your best efforts, people might forget or misunderstand your user interface. Don’t assume that all of your users are familiar with specific terms. Avoid introducing abbreviations or jargon in titles or subheadings. Instead, spell out words and explain abbreviations or acronyms when you first introduce them in the text.

Avoid using nonstandard abbreviations that are internal or unique to your organization, project, or product. Never use text within icons because it cannot be translated and won’t always make sense. Even some international standards make this mistake—for example, the international standard for a generator icon is denoted as a circle with a big G in the middle—so it could take some effort to get around this problem.

Unless there is a common translation for an organization’s name such as Doctors Without Borders / Médecins Sans Frontières, use its official native spelling instead of translating it to a local language. Watch out for similar words that have different spellings in dialects such as British English versus US English—for example, Programme / Program or Centre / Center.

Formatting Data Display

Many digital products display data of some sort. They rely on users’ easily and accurately reading the information they present. Therefore, we must display the values, the units, and the labels themselves in ways that match the users’ expectations and workflows. Display the data and units in common formats with which users are familiar and at a scale that works for the task at hand.

Displaying Numbers

Arabic numbers are used by most but not all of the world. Confusingly, the Arab world doesn’t use them, but instead mostly uses a character set called Easter-Arabic. Same system, base ten and all, just different glyphs. Oh, and some regions vary within this, so Persian (Iran, mostly) uses slightly different ones.

Do make sure of what your audience uses; global financial services based in Arabic countries may use western conventions. Find out before designing it.

Formatting Numbers

Numerical formats are not as consistent as you might think. Render numbers using the region-specific preferences that users have set on their device. Commas and decimals have different, inverted meanings in some regions. All of the following examples are the same number:

1,205.43
1.205,34
1 205.34

Only about 60% of countries use a comma as a scale delimiter and a decimal point to indicate a break between whole numbers.

In some regions and in official scientific works, spaces replace commas or decimals as the scale delimiter. Officially, these spaces should be the Unicode character U+202F, which is a nonbreaking space. But if that doesn’t work on your platform, using U+2009, or a normal space, should work, as long as you have otherwise provided enough room for the value to fit on one line.

Eastern Arabic numerals present another use case, especially because their zero value is easily confused with a decimal. Aside from use of the comma, there is an Arabic decimal separator ٫ (U+066B) a sort of comma-shaped glyph. Here is Pi shown with that separator:

٣٫١٤١٥٩٢٦٥٣٥٨

There is also an Arabic thousands delimiter ٬ U+066C, though the quote ' or arabic comma ، U+060C may also be used. Here is 1 million in Eastern Arabic numbers with the proper delimiters:

١٬٠٠٠٬٠٠٠٬٠٠٠

Formatting Currency

If you provide product pricing in multiple currencies for local markets, you must indicate them accurately. This involves a lot more than just changing the symbols. The position of the symbol can also vary, with some symbols appearing before and some after the numerical value. Many locales also add a space between the value and the currency symbol. Treat this as a unit indicator, so use a nonbreaking space between them, ensuring that users always read them as a single phrase.

Many countries use the same currency symbol—for example, the dollar sign, $. If it is not clear whether your product is from one region or another or there’s any chance that users might become confused about what currency they’re using, substitute the international code for the currency for the symbol or add the currency code. You can show Canadian dollars in either of these ways, but the second approach is often necessary to avoid confusion with US dollars—especially because of the physical proximity of these countries and their shared language. For example:

$1,205.43
CAD 1,205.43

When using the letter code, be sure to use special formatting such as a slightly different font size, weight, or color to make the value easier to read.

Once everyone is on board with using these codes when displaying currencies, you can even use them to improve the display of currency within a single market. In the US—as well as in many other countries—cents have their own symbol, which appears after the amount. Displaying a price as 99¢ is much better than $0.99, so if you sell many items that cost under one dollar, displaying costs in cents would be worth the effort.

Formatting Time

Always display the time zone to reassure users that the system has rendered the time properly.

Never store dates or times as strings. Instead, use temporal data in UTC (Coordinated Universal Time). Apps can parse such values to display date and time information appropriately, using the user’s regional display preferences and usually their current time zone.

Always display the time zone to reassure users that the system has rendered the time properly. Even users who do not travel might want reassurance. For example, they might be aware that a far-flung server farm is feeding them data, or they might be on a corporate network or using a mobile provider that could indicate their location incorrectly. Sometimes it is necessary to display data for other time zones—or for more than a single time zone at once—for example, when the user is making travel plans.

There is no useful standard for human-readable names of time zones. This tends to worry engineers, who want all attributes to be globally unique. Ideally, we would use a long name such as Central Time, US, but that would usually take up too much space. Plus, such long labels might obscure the actual data—the time value itself. In practice, using the conventional local abbreviations works well enough. Very rarely is a time zone so wrong that users would get data for an entirely different country and become confused.

To be extra careful—or for audiences for which time is more critical or who have a more technical mindset—include the UTC offset. Even people who don’t know their UTC offset would eventually learn it by seeing it in your product and would notice if the time zone had changed. Here’s an example:

12:42 pm CT (-6)

Be careful not to confuse people with labels for time zones. Always ensure that they get translated. Ideally, similar to what I suggested for pricing, find a way to use typography design to either emphasize the time value or deemphasize the time zone so it won’t be distracting.

In many parts of the world, 24-hour time is simply called 24-hour time, not military time. It may even be the standard time format. So when users can select 12-hour or 24-hour time, label the values as such.

If you’re using a 12-hour clock, the official way of displaying the period of the day—either am or pm—is in small caps. However, digital user interfaces support this poorly, so use lowercase instead, with a space after the time and no periods. Use a nonbreaking space character or another method of ensuring that the time period never wraps onto another line.

While the official convention for the separator between hours and minutes varies, the colon is in wide enough use—and the context is usually clear enough—that there is no compelling need to regionalize times by removing this character in different contexts. While this is not strictly proper, it’s simple, so is what I often end up doing. However, if the proper regionalization is easy to achieve with a plugin or operating-system support, by all means use it.

Formatting Dates

You should make all dates unambiguous. Therefore, you should display the month in text whenever there is sufficient space….

In dates, the month, day, and year appear in different orders in various regions—and sometimes even depending on certain types of job roles. In the US, we generally use a MM/DD/YYYY format for numerical dates—for month, day, and year. But much of the world uses DD/MM/YYYY. The following two values represent the same date in two different regions:

10/1/2020
1/10/2020

But numerical dates are always ambiguous. When you’re displaying dates in only one format, how can the user know at a glance whether they’re properly regionalized? Does the date in the previous example mean October 1st or January 10th? Regardless of the need to properly regionalize the order of dates, you should make all dates unambiguous. Therefore, you should display the month in text whenever there is sufficient space—whether spelling it out in full or abbreviating it, with no period following the abbreviation—as follows:

Oct 10, 2017
10 oct 2017
October 10, 2017
10 octobre 2017

In some languages such as French, the convention is not to capitalize the names of months, as in the previous example. Follow regionalization rules carefully and precisely.

Formatting Names and Addresses

Many countries invert the display of given and family names, prefer to use all caps for family names, or have other display conventions with which you may be unfamiliar. A good overview of some of the issues is provided in this Twitter thread.

Addresses are even worse. Many countries have street addresses that do not follow the standard format we use in the US: number plus street name. Or they use address formats that require the use of many more lines to accurately indicate the address.

The easiest way to resolve this issue is to avoid imposing your own country’s formatting on data from another country. The conventions we’ve adopted that parse data into separate fields is partly a result of our detail-oriented engineering cultures, but it’s mostly because of standard banking and credit-reporting practices that require matching information. Regional, and not applicable to most of you. If you don’t do credit reporting, you don’t need to parse out names or addresses (and even if you do, that’s only part of it; ask for a specific format version for that purpose, then).

Instead of using labels such as First name and Last name, or trying to make them into “given name” / “family name” fields, simply provide a Name text box—or an Address text area. Then people can fill in their information as they see fit, and you can store it in whatever format they use. Doing this provides valid data for almost all real-world use cases.

Services such as Google Maps can handle addresses in any format, and it is rare that addressing a user by their first name or last name alone is valuable, so you won’t be limiting your functionality, either.

Using Units of Measurement

Store dates and times as readable data, not text strings.

If no explicit preferences exist for the display of units of measurement in a given context, either display them using the user’s device preferences or follow the specifications for particular regions or languages.

Store dates and times as readable data, not text strings. However, you must store almost all other data as translatable units. Many technical systems retrieve or store all data in SI, or the International System of Units, which are not units most people use—even engineers. But systems can easily convert them to any measurement scheme.

It is important to let users set their own preferences for units of measurement. They may be accustomed to using units that differ from those that are prevalent in their mobile device’s current location; their preferences for units might change from task to task, as they change devices or clients; they may be consulting on a project in another region; or they might be working in an industry with different conventions from those of their current region.

Unit sets such as Metric or English are probably not what you’re used to. Never, ever refer to your regional default as Default, Normal, or Standard. Instead, use the proper labels for the two most common unit sets, as follows:

Metric
U.S. Customary

These are not likely to be the only unit sets you’ll need. There is also an Imperial unit set, which is not the same as U.S. Customary. In Latin America, they use Metric, but with a few U.S. Customary units thrown in. For certain industries or regions, you might need to add one or both of these other unit sets as well.

Using these labels for unit sets goes only so far in describing units of measurement, especially if users are completely unfamiliar with them, don’t have a clear understanding of what they mean in comparison to one another, or don’t have an accurate label in mind. Therefore, when you’re allowing users to change their units of measurement, be sure to provide a brief list of the units they would be using in proximity to each label for a unit set, as follows:

Metric—km, kg, l, kPA, °C
U.S. Customary—mi, lb, gal, psi, °F
Imperial—mi, lb, imp gal, psi, °C
Latin America—km, kg, l, psi, °C

This is just one example. If you’re building a fitness app, you probably won’t need liquid volumes or pressures, so just display the most important units for your users and their contexts.

When you’re displaying units of measurement, ensure that there is always one space after the value, separating it from the unit label that follows—with the exception of the degree symbol. Always use a nonbreaking space (  or U+00A0) for that space. Value/unit pairs must always appear together or they would make little sense. In tables, you can sometimes get away with having a column header indicate units to avoid repetition, increase readability, and save space.

Whatever level of precision you use in your original design should carry through to converted units of measurement. For example, if you have rounded decimal places to no more than two places, rather than precisely converting a unit of measurement, round it off to approximately the same degree. Also, use the proper units that follow local conventions, and make sure that they are readable and understandable.

Original—2.0 lbs.
Wrong units, too long—0.907185 kg
Better—.91 kg
Best—907 g

Excessive precision or providing the incorrect unit options can reduce the readability or value of the information.

Not all measurements should be translated. Specifications or marketing values should usually remain in their native units—for example:

Metric thread sizes would become nonsense if you translated them to another unit of measurement.
The name of a product that includes a horsepower rating would be inconsistent and confusing if it were translated to display in kw.

Be sure that you understand what information you’re displaying and how the user would use it before allowing it be translated or converted.

Formatting Positional Data

Most of the time, we simply display locations on a map or as an address. However, if you must display a location as coordinates, this can sometimes cause confusion when you’re regionalizing a user interface. Coordinates are not quite the same as other display units.

You could display the horizontal position—the coordinates—in any of a large variety of systems, but it would not correlate to any of the units of measurement I’ve described. Do not confuse and accidentally translate degrees of latitude and longitude with degrees of arc or temperatures. In most cases, you should be able to display the positional data directly in the format you receive, but special user types might require specific formats. For example, governments use USNG and militaries use the related MGRS. These are very, very different systems, so translating from degrees to grids is not a simple formula.

When necessary, display horizontal position accurately, as a simple measurement, usually in meters. Unlike coordinates, you should convert this value into the user’s preferred display unit.

When you’re displaying the vertical position, or altitude, it is also a conventional length, so subject to conversion based on the user’s or regional preferences.

Designing for Context and People

The success of any new mobile app does not depend on its feature count or technical completeness, but on your designing and building it for real people and the way they actually work.

Yes, this is yet another article that basically says everything is more complex than you might have expected. The best way to address a new need is to have thought of it early on. This is true of almost any aspect of design, and there are no cheats.

The success of any new mobile app does not depend on its feature count or technical completeness, but on your designing and building it for real people and the way they actually work. I hope this overview has given you a few more insights into how people’s needs vary across regions, so you can plan and research the right approaches to take for your next UX design project.

Articles, ReportsSteven HooberNovember 15, 2020