Cross-Cultural Factors Should Be Considered in Enterprise Software UX Design
By Applications User Experience on Aug 08, 2011
Anna Wichansky, Senior Director and Chair, Oracle Usability Advisory Board
In 2010, we expanded our Oracle Usability Advisory Board (OUAB) to Western Europe. We now have 26 representatives of 19 enterprises from Europe participating. While all board meetings are open to all customer members regardless of geographic location, we try to rotate meetings to accommodate participants throughout the world. We held our May 2011 meeting at Oracle Thames Valley Park (near Reading in the United Kingdom). The meeting was largely attended by UK and European customers.
Although the major UX issues with enterprise software applications are nearly the same throughout the Americas and Europe, we have noted some differences at play in the international sphere. Taking into account these differences when designing the user experience will help prevent applications from alienating some enterprise customers.
Bettina Reichart, Oracle Worldwide
Translation Group; Craig Parkins, Cedar Consulting; and Netta Rankin, UN High
Commission on Refugees, discuss translation issues at the OUAB meeting in Reading, UK,
on 4 May, 2011.
Language Localization and Translation
Language is probably the largest single user experience component. Nearly 7,000 living, spoken languages exist in the world. This variety creates a major user experience challenge.
The Oracle Worldwide Product Translation Group tackles this challenge every day. The 200+ employees translate Oracle products into more than 40 languages. These individuals manage the projects, build the technical infrastructure to gain high re-use, and manage a network of external vendors. The group employs local language specialists to ensure quality of translation for more than 30 markets.
And yet, terminology inconsistencies still exist. Specifically, our customers have mentioned issues with terminology used in American English texts. For example, in the US, certain accounting terms are clear and their meanings agreed upon by domain experts. In Central European countries, where there’s a more abbreviated history of using Western-style accounting methods, standardized terms are developing more slowly.
Also, some customers use a mixture of languages in their implementations. For example, workers from a Belgian auto manufacturer read form field labels in English but enter the data in French. This means that when field labels are translated, we must be careful to choose the correct word form in the new language, or the form no longer makes sense.
Finally, several UK customers commented about applications content in American English. These customers said that they would feel more comfortable using the British English equivalent.
Features and Functions Adapted to Local Cultures
Financial applications need to be sensitive to the number of characters allowed in account number fields (for example, Swiss requirements for 69 bank account characters).
Employee-employer relationships may not have the same titles as those used in the US. For example, in Europe, the term partner or member is sometimes used to refer to an employee, and the term reviewer is sometimes used instead of manager.
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).
European Union countries have a localization requirement to include the Value Added Tax (VAT) in financial transactions, and paradoxically these may be different depending on the country.
The Nature of the Enterprise Itself
Several customers in Europe and the UK work in enterprises that have unique organizational cultures that must be considered from a user-experience perspective.
One commercial example of such a culture is a large partnership with 70,000+ partners (employees) operating several major retail chains. It is not a traditional corporation. It has a constitution, and partners vote. An important tenet of the mission is to increase the happiness of its partners. This customer would like to have software that reflects its value system—software with a user experience that is helpful, pleasant, and sensitive to the partners’ needs.
Several other profit-making customers are either government-subsidized or government-run, and therefore highly regulated. The software for these customers must take into account these regulations.
Another example is a large, international, non-profit public sector enterprise. This organization has a consensus-driven internal culture, a large number of languages and customs within organizational units, and many highly experienced employees resistant to change. The conditions in which the employees of this enterprise work vary widely and come with unique challenges. Use of enterprise applications, for instance, may be very different in locations where basic needs like plumbing, water, and electricity are issues (e.g. Somalia).
In summary, enterprise software companies tend to develop applications requirements, features, and functions based on the customer needs that they see reflected around them every day. However, when designing software for customers around the world, companies must consider the wider range of human factors and seek out information on the variety of international requirements to serve customers the world over.