Friday Aug 26, 2011

Internationalizing Designs and Usability Testing for Enterprise Apps: Points to Consider

User experience is global, and usability research and testing must involve real applications users doing realistic tasks in all of Oracle's target markets worldwide. However, creating designs and prototypes for every language that Oracle translates its applications into (30 plus) is neither feasible nor required. Here's some guidance about creating lo-fi designs, prototypes and testing scenarios that will work well internationally, make the target audience comfortable, while obtaining relevant feedback on materials.

The Reality...

Optimally, the user experience shown in designs, prototypes and described in testing tasks should be in the natural language and use the regional preferences of users in the target market. Users should always be allowed to work in the language of their choice, entering and printing and viewing data, and seeing their local data, time, currency separators, sort orders, and so on of their region. The reality of the modern global enterprise allows us some more leeway however, and this can work in favor of more scalable UX processes too.

How to Adapt Designs, Prototypes and Test Tasks for International Audiences

  • Remove any obvious US functionality from the UI or required test tasks. For example, social security numbers, address formats, data pickers that launch US-format calendars, or popups on editable fields suggesting US date formats as examples.

Social Security Numbers are not used globally, so tailor your experience to the market

  • If localization functionality is being shown, then change the UI and tasks to reflect the reporting or other legal requirements of the country or region. For example, VAT in the EU instead of sales tax, what the various statutory requirements for employee leave and holidays are and so on. Consult with local sales consultants and localization developers to tailor the UIs.

Find out what requirements, laws and regulations are in operation for the workplace in the target market and reflect that.

  • Take care when showing personal or employment data in designs or prototypes intended the EU especially, avoiding invalid tasks that might cause privacy issues in Germany for example. Remember social media-type interactions and integrations too in this regard.
  • Adjust any functionality and testing tasks to reflect what users might do locally. For example, if searching for information using a mobile app, German users may prefer to search a German website (.DE domain) for local information, using translated keywords and so on.

Use international features to reflect the user activity of the target market.

  • Find our what are the most common formats and variables used by the organization as it works, and adjust any test tasks to reflect those. For example, rather than a list of currencies to scroll through, why not present the local users most used currencies at the top of a currency list of values.

Use the commonly used data and activities of the target market.

Other observations about taking international user experience considerations into account are detailed in the usableapps blog Cross-Cultural Factors Should Be Considered in Enterprise Software UX Design.

Decide About Translating Designs, Prototypes, and Testing Materials

  • Whether the design or prototypes needs translation depends on the user profile and the work involved, so review that information carefully. In some countries (for example, Japan, Korea, China, France, and others) using an untranslated UI for testing is not advisable, and certainly for public sector users a translated version should be used too.
  • Do not fall for the old argument that “they all speak English” when testing in European countries. Although conversational English is widespread amongst users of enterprise apps in Europe, the domain expertise required by some enterprise applications is more easily acquired and functionality understood in the native language of the user. Any public sector testing will hinge on being able to provide translated designs and test scenarios.
  • In other cases, such as testing with users in US-based multinationals, an English language UI may suffice if it uses the regional settings of the local users and the tasks involved in any testing reflect what local users do when working.
  • Depending on the market and user profile and other information you may also need to translate any test instructions, questionnaires, surveys and other materials, as well as translating any quantitative data or other observations gathered. Test sessions may also require you to use an interpreter to guide users through tasks, so pilot these sessions so the interpreter and usability engineer knows what's involved, and the right cultural approach can be taken when coaxing information out of test subjects or helping them along.
  • Use professional translation services and interpreters who preferably have domain expertise in the test area. Do not rely on Google Translate. Working with local in-country domain experts who speak the language of the user is the way to go. Leverage the language assets and expertise of the corporate translation team, or already subcontracted translation companies working on applications.
  • Create designs in formats that can be easily translated. HTML is ideal, and PhotoShop layers or Visio (VSD) files can also be translatable.
  • If you cannot translate the UI, then be prepared to explain how to users how application will be translated, and also explain how the language shown in applications can be changed further. If in the UK, for example, be prepared to deal with the issue of US spellings used instead of the UK variants by emphasizing regional support, localizations, and how the language can be changed to reflect the enterprise requirements using personalization or other extensibility tools to maximize the usability of the application.
Be ready to explain translation, personalization, and other language change mechanisms.
Personalization is particularly important in the mobile apps space (as evidenced by the Apple iOS5 personalization feature, coming).

Using Regional Settings

  • Always use local regional or common formats in user preferences. In enterprise applications, multilingual support (MLS) is critical: this functionality allows users to enter and view data in their own language and use local settings while running the UI in another language; a situation often encountered in multinational companies. Change the US defaults for dates, times, currency symbols, decimal separators, and so on to reflect what is used in the target market.

Use the regional settings of the target market. Common formats help testing efforts scale.

  • Construct test tasks that require users to enter or use data using those settings, not the US equivalents. There is nothing more infuriating to non-US user than being told to enter a date of 03/03/03.
  • If you must compromise on these regional settings, for reasons of scale for example, then choose a common format instead over the US one. For dates for example, a common format of dd-MMM-yyyy will avoid confusion internationally.
  • Even something as simple as changing the sign in name in your application to a friendly local format can make testers feel more comfortable.

Do you have any other guidance on successful internationalization of designs, prototypes or usability testing? Any observations or tips to share? Let me know, using the comments.

Monday Feb 07, 2011

Games Localization: Cultural Points

Great article about localization considerations, this time in the games space. Well worth checking out. It's rare to see such all-encompassing articles about localization considerations aimed at designers. That's a shame. The industry assumes all these things are known, yet the evidence from practice is that they're not and also need constant reinforcement.

We're not quite in the games space in enterprise applications yet, but we're getting there, and gamification is a hot UX topic. In the enterprise apps arena, there may be a role for games in the training space, in CRM through building relationships and contacts, gathering sales and marketing data, answering service requests, and so on. Or in HCM, for talent development or recruitment purposes. No end of possibilities.

Other thoughts can be gleaned from this appslab post Why Gaming is the Future of Everything. Beyond the obvious considerations, check out the cultural aspects of games localization too. For example, Zygna's offerings, which you might have played on Facebook: Zynga, which can lay claim to the two most popular social games on Facebook - FarmVille and CityVille - has recently localized both games for international audiences, and while CityVille has seen only localization for European languages, FarmVille has been localized for China, which involved rebuilding the game from the ground up.

This localization process involved taking into account cultural considerations including changing the color palette to be brighter and increasing the size of the farm plots, to appeal to Chinese aesthetics and cultural experience. All the more reason to conduct research in your target markets, worldwide.

Wednesday Feb 02, 2011

Text Expansion Awareness for UX Designers: Points to Consider

Awareness of translated text expansion dynamics is important for enterprise applications UX designers (I am assuming all source text for translation is in English, though apps development can takes place in other natural languages too). This consideration goes beyond the standard 'character multiplication' rule and must take into account the avoidance of other layout tricks that a designer might be tempted to try. Follow these guidelines.

  • For general text expansion, remember the simple rule that the shorter the word is in the English, the longer it will need to be in English. See the examples provided by Richard Ishida of the W3C  and you'll get the idea.

    So, forget the 30 percent or one inch (excuse me?) minimum expansion rule of the old Forms days. Unfortunately, remembering convoluted text expansion rules, based as a percentage of the US English character count can be tough going. Try these:

    Up to 10 characters: 100 to 200%
    11 to 20 characters: 80 to 100%
    21 to 30 characters: 60 to 80%
    31 to 50 characters: 40 to 60%
    51 to 70 characters: 31 to 40%
    Over 70 characters: 30%

    (Source: IBM)

    So, it might be easier to remember at the prototyping and design stage a simpler rule that if your English text is less than 5 characters then allow it to double in length (an increase of 100 percent) during translation, if it's more than 20 characters then allow for a 30 percent increase, and if it's in between those two ranges then assume a 75 percent increase. (Bear in mind that ADF can apply truncation rules on some components in English too).

    Note that iIf your text is stored in a database, developers must make sure the table column widths can accommodate the expansion of your text when translated based on byte size for the translated character and not numbers of characters. Use Unicode. One character does not equal one byte in the multilingual enterprise apps world).

  • Rely on a graceful transformation of translated text. Let all pages to resize dynamically so the text wraps and flow naturally. ADF pages supports this already. Think websites.
  • Don't hard-code alignments. Use Start and End properties on components and not Left or Right.
  • Don't force alignments of components on the page by using texts of a certain length as spacers. Use proper label positioning and anchoring in ADF components or other technologies. Remember that an increase in text length means an increase in vertical space too when pages are resized. So don't hard-code vertical heights for any text areas.
  • Don't force wrapping by using tricks such as /n or /t characters or HTML BR tags or forced page breaks. Once the text is translated the alignment will be destroyed. The position of the breaking character or tag would need to be moved anyway, or even removed.

    Don't be tempted to manually create text or printed reports this way either. They cannot be translated successfully, and are very difficult to maintain in English. Use XML, HTML, RTF and so on. Check out what Oracle BI Publisher offers.

  • When creating tables, use table components. Don't use manually created tables that reply on word length to maintain column and row alignment. For example, don't use codeblock elements in HTML; use the proper table elements instead. Once translated, the alignment of manually formatted tabular data is destroyed.
  • Finally, if there is a space restriction, then don't use made-up acronyms, abbreviations or some form of daft text speak to save space. Besides being incomprehensible in English, they may need full translations of the shortened words, even if they can be figured out. Use approved or industry standard acronyms according to the UX style rules, not as a space-saving device.

Restricted Real Estate on Mobile Devices

On mobile devices real estate is limited. Using shortened text is fine once it is comprehensible. Users in the mobile space prefer brevity too, "as they are on the go, performing two to three-minute tasks, with no time to read lengthy texts. Using fragments and lightning up on unnecessary articles and getting straight to the point with imperative forms of verbs makes sense both on real estate and user experience grounds.


Oracle Applications Cloud global user experience (UX): Culture, localization, internationalization, language, personalization, more. A globally-savvy UX making it all fit together for Oracle's worldwide partners and customers.

Audience: Enterprise applications translation and localization topics for the user experience professional (designers, engineers, developers, researchers)!

Ultan Ó Broin. Senior Director, Oracle Applications User Experience, Oracle EMEA. Twitter: @localization



« June 2016