In UX the golden rule is "you are not your user." Global UX is no different, but with an added layer of multiple languages, cultures, and with that design perspectives and expectations.
Most of us as consumers don’t think twice about grabbing Google Translate for a quick translation, but in our professional work we need to be careful. When designing an application that has global potential how much time are we spending on internationalization? Are we considering the language of the content a small segment of the overall user experiences or merely translating content? If so, we need to rethink our approach. Global UX includes translation, but is not defined by it. Let’s discuss what needs to be considered and implemented for a successful global-ready launch.
UX is, above all else, about the user; what they expect and need out of a design and how well those requirements can be accomplished within the business model. While designing, keep something in mind: We are not our users! Jessica Rensing of Carinal Solutions' Cincinnati office expands on this user-first mindset in her article on how personas help us understand what users want. As an example, let’s assume we are building an e-commerce website with a large percentage of users in the United States. A user Gabriel needs to access the site on his mobile device while on jobsites. He lives in the U.S. and orders products for his team semi-monthly and needs to do so quickly and easily. Using these considerations, we know this website needs to be responsive, perform well in low-connection environments and allow a low click ratio from product to checkout. But what about language? Gabriel lives in the U.S. but let’s assume he speaks Spanish as his first language. The client has a few translated pieces of documentation about the company and products on product detail pages in Spanish, but how will he navigate to those pages using the intended flow if he has trouble understanding the content? We could advise a translation of the entire website or key portions of the website but isolating the content from the context can cause serious issues. Translation alone is not enough. We need to solve Gabriel’s user case by providing a product that considers the impact of where he lives, what his culture is and what language he uses comfortably in the design. This is the basis for Global UX.
The culmination of two concepts, Global UX is broken down into Internationalization and Localization. Internationalization is progressively enhancing a site or application for global markets that can be eventually localized; it is the best-practice for design and development. Just as responsive web-design and accessibility optimizations are the expected protocols, allowing a site’s content to reach a wider audience on the user’s terms, Internationalization meets the user where they are. The methodology provides content in a way that best meets personal needs instead of just hardware needs. Localization is the application of Internationalization on a specific location and culture to meet linguistic and legal requirements. When we translate, it falls under Localization. However, relying on the idea that translation = global-ready will set our applications up for less than stellar results. Machine translation over the past few years has improved, but when literal translation does not carry over context the meaning can change dramatically. Non-verbal elements can also fail to translate meaning successfully such as color and iconography. Context is key to a successful global integration thus location, culture and language must be considered together from the initial research, planning and design phases of the UX process.
We all have our preferred operating system, browser and device. For some they become a piece of our identity, but technology and its implementation differ based on location. This can include how users access and use the web. Let’s consider Mozilla Firefox. Did you know that the Firefox homepage experience can be drastically different based on your location? A browser or search engine is a good case study to understanding the expectation a user will have for content they consume on the web. In North America, we are an ask and receive culture. We want information as quickly as possible. Searching and easily accessing favorited items are a common feature for browsers and search engines. China by comparison is a browsing culture. The eye focus is expanded across the screen, covering the entire page rather than the upper left. Firefox China, like Yahoo.com, has a layout that focuses on being a hub of information and providing it all at once. China users tend to spend longer periods of time on a page (30-60 seconds as compared to 10 seconds) and preference is placed on users selecting from a list of information instead of typing keywords.
“[Asian users] take a more holistic approach when reading which includes more skimming, scanning and jumping back and forth. This means that the placement of UI elements, such as calls to action, might be impacted simply by the way an audience reads.” – Salesforce
Many of these approaches are politically-driven, but these cultural considerations are vital in the research stage. The browser best showcasing the Asian online screen scanning is Baidu. The market share in China for Baidu averages 60% when compared to Google China which only manages 25-30%. Baidu advertises itself as free, social, customizable and in direct competition to Chrome, despite using a variation of Chromium. The layout consists of multiple, easy to access social tiles, easy sharing and downloading capability. Due to bans the Google Chrome use in China has remained low, allowing for Baidu to dominate, reinforcing a specific expectation of how to consume information on the web, much like Internet Explorer’s early influence based on support and the capability of browsers. International standards that ensure technology will support text on the web in any language (such as encoding and reading direction) and localized legislation for consumer security (such as the recent cookie-consent alert) are a large part of Localization. For languages that rely on non-Latin characters proper character encoding through Unicode and proper UTF declarations ensure the letters appear correctly. Reading direction standards could be left-to-right, right-to-left, a mix of the two (as seen in Arabic, Urdu and similar languages) or vertical. With these standards in mind proper use of CSS, SVG and XSL-FO allow the content language to flow as intended. The cookie-consent notification is an example of how we need to be aware of localized laws when focusing on specific regions. Improper handling of global standards and expectations can damage SEO and brand trust for users, or worse break the law. We need to research early and often prior to launch. As was the case with Brexit in 2016, or earlier when Europe moved to a single-currency (Euro), our localization efforts might need to change based on current events.
At this point we’ve compiled the research and completed user studies. Time to wireframe and prototype! Whether initial copy or only placeholders, the first advice is to design knowing that widths, heights and in some cases content order will change. The responsive design approach should include a method such as grid or flexbox to handle layout changes, but also consider changes to the type itself.
On average words in the English language are five characters in length, however this length is shorter or longer when translated depending on the language. For example, the word views in English when contextually translated into German is mal angesehen. The term’s ratio of width when compared to English is 2.8 times longer. If we created a fixed width button or column for this phrase the design has a high potential to break outside the bounding box. Character length is not the only change in translations, character spacing and character width also change for special character languages such as Japanese, Chinese and Korean. The Korean translation for views is 조회 and while only two characters in length is nearly the same box-size length as its English counterpart, having a ratio of 0.8 times the English width. Speaking of non-Latin characters, it is very common that these characters are taller and require more leading, or vertical space between lines of text. Remember in these scenarios, not specifying static dimensions is best-practice.
Two other visual changes when designing for multiple languages is that data formats and standard form layouts are not necessarily the same from one language to another. Languages that use a different currency symbol ($ vs € for example) or currency division (0.00 vs 0,00) will not create a huge impact on early wireframes, but are important to remember when entering development. Dates and phone numbers however (especially if dynamically created) should be accounted for in early designs. If designing a calendar, we should remember that the start of the week differs culturally as does the format of a date. The United States' usage of month-day-year can cause issues if changed to year-month-day or day-month-year. If we are not paying attention this can cause easy confusion to our users.
Two standards for formatting form elements is a full-width label atop a form element or having the label inline. In the case of inline, avoid multiple inline elements such as dates that use the U.S. order or that are formatted as statements. I am <blank> years of age may seem like a very conversational and easy to understand format, but creating strings that need to be translated separately can cause a word to be translated incorrectly. For example, bat could be a sport equipment or a winged animal. Some languages will also place adjectives after nouns instead of preceding them. We would not say chair green but that is the correct literal translation order for Spanish silla verde to specify a green chair. Outside of literal translation, languages also have genders and pluralization differences. Without context translations go awry. For these reasons statically placing form elements in between one or more text strings is not proper global UX.
Red means stop and green means go, right? In UX we know this is not true and that meaning cannot rely on color alone. Color taking on a specific meaning can only go so far as how well the user can see and understand that color. Users may have color-blindness or simply be from different countries. Color-meaning varies greatly based on region. Take a stock market app that uses green to indicate a stock increase and red to indicate a stock that has dropped in share price. In Asia, the color associations in this example would be reversed. Best-practice is to include a secondary visual cue, such as an icon, to denote meaning. Image-only meaning, especially when relying on metaphor, however can be misunderstood if not given localized considerations. An icon of is often used to denote the items a user has decided to purchase. Along with , and are some of the rare universal icons that have global recognition. Some fashion retail sites have adopted a bag icon in place of a cart icon which, depending on the market as well as location, can have negative CTA as well as confusing meaning. It is recommended to avoid non-localized icons for specific markets as shorthand for concepts. Imagery to avoid can include any of the following: hand symbols or gestures, religious symbols that are not globally recognized, animals to denote emotion (for example, dove for peace or dog for loyalty), single letter graphical elements and politics. Use localized labels along with color and iconography to ensure meaning is not lost. Photography may also need to be localized to reflect the appropriate people and places, but best-practice would be to avoid location-specific imagery unless the location is the intended or directly relates to the content. Use text-free images, inanimate objects, images of nature, globally recognized equipment and modes of transportation. Remember the target culture when using visual-shorthand to invoke mood, emotion and ideas. On the same concept of meaning shorthand is the divisive use of flags, specifically to denote language. “Flags are not languages” is a popular UX idea and the reason is that flags represent a country and a country is not made up of a single language. A user in the UK may not want to see an American flag to represent the English language, but the same goes for Spanish-speaking users in the United States who do not identify with the flag of Spain. Flags are also often political. What is the solution? Flags are countries so use them to represent countries. Languages are languages so they are better represented through words versus imagery. Certain localized sites may also need to use a mix of the two where location is detected and then a user can select language. In this way, a location’s language and culture can be identified for ideal global UX. To ensure the usability of the language itself, in addition to the previously discussed character widths, spacing, and height, one forgotten consideration for translated content is the font used. In the age of web-fonts, even for content in English not all fonts support all symbols on the keyboard users in the United States are accustomed to. These symbols do not need to be complex such as the Macintosh command symbol (⌘) but can be as generic as an ampersand (&). Beyond symbols we need to be careful of the font’s styling, weight, width and default spacing. Certain fonts can distort a letter, but font-weight and font-size can make the text illegible in some cases. This is reflected in the trendy use of thin fonts for body text and very small type in form helper text or legal copy, regardless of language. It is bad UX if users need to squint to read the content provided, but as is the case with Japanese and Indic fonts at small sizes the characters can become completely unreadable. Some font families also do not support bold and italic characters. CSS has properties to force the font to be bold or slanted, but with non-Latin character languages distortion of a letter can increase difficulty in readability. When designing for usability an application’s performance and the technology used play a big role. Developmental practices (when applicable) such as allowing offline content to be available and ensuring website functionality to persist when Javascript is disabled all ensure usability in a variety of situations. The latter is especially important since Chrome for Android recently announced they will be disabling Javascript on 2G connections to aid in better page load and performance on low connections.
When our applications and sites can reach users wherever they are, whatever language they speak or how they communicate, and is sensitive to a user’s cultural differences then the user experience we have created is ideal. Some projects will only need internationalization techniques and no translations, but other projects may require full multi-language support. No solution will be perfect and global UX is an ongoing process, especially in regards to translating and implementing new content after release, but the benefits as both developer and user are worth it. Proper localization and internationalization reduces frustration from a user as well as miscommunication. Even a small amount of effort can open a new user base, reduce bounce rates, and create a more accessible end-product. Remember, Global UX is UX and we should all work to incorporate a global mindset into what we design, build and develop.