Thursday Oct 06, 2011

PayPal Error Message 3005: Where User Experience and Translatability Collide…

… and neither comes off very well. I received this huge error message as I was updating my credit card details in PayPal. I was working in the English language, yet this multilingual monster came my way.

PayPal Message 3005

Generally, these multilingual messages cause translatability issues. Most translatable files conform to a bilingual source-target paradigm, and not a multilingual one. The single language target enables better use of language assets and flexibility with process. Of course, the arrival of CMS and GMS-based translation solves a lot the coordination problems of keeping multiple languages translation in sync. It is also possible this message was served up from a server way rather than being actually multiple translations in a single container on the file system (I didn’t view the page source). Regardless, why bother? The users working language is known.

As for those message numbers (Message 3005), are users expected to look them up and act? Generally in the enterprise applications space these numbers are only useful to help desk or support personnel or specialized functional administrators with the right security permissions to actually do something with the application in response to looking up what that number means in a knowledge base. In this case, looking up the number leads to frustration too.

Dealing with these generic application failure issues has long been a user experience issue. If would have been better to throw a shorter specific message in my working language was shown, one with a more precise title, a cause text that reflected what I was doing, and a precise action text to perform to fix the issue. An assurance that my money and other personal details were safe too should have been provided. Making that message number and some diagnostics available on demand only, and capturing any details in the background so that a security specialist or other help desk person could check that none of my data was compromised would have been preferable. At least I was not told to contact my system administrator, so I am thankful for that!

Wednesday Sep 07, 2011

What's in a Name: Global Considerations for Apps

Enjoyed this article about the assumptions made by programmers (and therefore developed applications) about names:

Falsehoods Programmers Believe About Names

"My system will never have to deal with names from China.
Or Japan.
Or Korea.
Or Ireland, the United Kingdom, the United States, Spain, Mexico, Brazil, Peru, Russia, Sweden, Botswana, South Africa, Trinidad, Haiti, France, or the Klingon Empire, all of which have 'weird' naming schemes in common use."

Head-wrecking stuff. Actually, it's a little unfair to blame it all on programmers, they aren't the only ones to fall into this trap, and if they have not been educated in the ways of internationalization, there's little point in blaming them. However, there are serious UX implications of these kinds of assumptions. You can read more about this impact on users in the usableapps entry Cross-Cultural Factors Should Be Considered in Enterprise Software UX Design.

"Names may require prefixes to delineate male or female employees, but sometimes there is no place to put these prefixes in the form fields. And some recent immigrants to Europe do not use last names (for example, those from Myanmar, Afghanistan, and Pakistan)."

Oracle Fusion Applications offers superb support for global names and how the user wants to see them. That's another post.

Bottom line:

  • Don't allow developers to design your apps, leave that to user experience professionals.
  • Internationalize code so that it is neutral of any one name format and can be localized for regional requirements.
  • Investigate your target market and what regional conventions means for the UX and design accordingly.
For more great information on the global challenges of handling names, and how you might deal with them on the UI and database side, see the W3C's Internationalization article Personal Names Around the World.

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.


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. Director, Global Applications User Experience, Oracle Corporation. On Twitter: @localization



« May 2015