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.

Friday Aug 19, 2011

Translatability Best Practices for Doc and Help

Translatability guidance aimed at user experience (UX) designers who are prototyping doc and help interactions and content. Considering these points will make your content easier to translate. Areas for attention include respecting the demands of XML structured authoring (DITA, DocBook, or other), how to share content, avoiding  translatable attributes, not contributing to the horrors of hard-coded alphabetical sorting orders, steering clear of the PRE element for tables and such like, allowing for graphics text expansion and redraw,  taking care with indexing and keywords, dealing with UPK translation issues, and so on. [Read More]

Thursday May 12, 2011

English as a Source and Target Language: The UX Dimension

I am often bemused by translation (or localization if you're outside the enterprise apps space) discussions on the interwebs that assume the source material for translation is always English and that the target language is always something else. The reality, of course, is different. There is a user-generated content explosion and much of which needs to be translated into English or other languages for global and community support reasons, multinational enterprises create content in languages other than English that may be relevant across their organization in other countries, and therefore needs translation, and so on.

And then we have the age-old debate about US English versus UK English. Some say it doesn't matter that UK English users receive US English content. Claims are made that UK users can 'figure it out' or are already so familiar with US culture that the differences in terminology or spelling between the two country variants  of English (yes, I know there are other variants) are transparently consumed.

I disagree. I think there is an important user experience (UX) dimension here. Admittedly hard to quantify in tangible terms, the use of the local variant in content is important and has an impact on user perception of the product. It can also have wider implications. Users who see themselves coldly described as  "ID  #" in a screen or help system when they should be called "Employee", "Associate", "Partner", or whatever, are hardly likely to warm to a product with hostile language and it certainly does nothing for corporate culture. In other words, the UX is diminished. Does it always have to be that way? No.

Google has done a very good job in providing US and UK users with versions of the Chrome browser that reflect the differences in terminology and spelling. This is done by allowing the user to select the version they want at download time, and then by language, regional detection (the web-based help using en-GB for UK users for example). Check out the following screens. See how "preferences" becomes "options", "hood" becomes "bonnet", "wrench" becomes "spanner", and "customize" becomes "customise". Did Google do this just because they could? Doubt that very much.

Under the Hood

Preferences and Under the Hood in US version.

Under the Bonnet

Options and Under the Bonnet in UK version.

Hood and Wrench

Wrench and Under the Hood in US version error page.

Bonnet and Spanner

Spanner and Under the Bonnet in UK version help system.


Customize in US version UI tooltip.


Customise in UK version UI tooltip.

Nice job.

This is something we need to explore further with enterprise application users. Users should have the language they use in their workplace or at home and not that of another country or region.

If they can't have that, then at least they should be able to change it easily to whatever they do want. That's what user-centered design and UX is all about.


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