By ultan o'broin on Aug 26, 2011
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.
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.
- 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.
- 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.
- 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.
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.
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.
- 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.