Since every consulting engagement is different, and our clients have their own product development processes, there is no single process. That being said, when developing our own products we do follow a specific NPD process, summarized on the diagram below. The diagram is a good way to organize communication of all of the things we can do FOR YOU. Click on the summary diagram below for elaboration...
Introduction
While hardly an expert on the deep technological aspects of Internationalization (often referred to as I18N) and the related topic of Localization (L10N), I have been responsible at the executive level for Internationalization/Globalization standards for transactional (financial) applications, as well as a contributor on Internationalization/Globalization issues in many of my consulting engagements.
The Main Issues for Internationalization and Localization of Websites and Web-based
Transactional Applications (Summary)
Example: On the right of the screen is a thumbnail of a website that is Internationalized and Localized for German and English. It happens to be the website for a tool (AttrakDiff) that we use extensively for online 'card-sorting' studies related to naming and categorization of website commands into a good navigation structure. (note: Many are surprised that many modern German technical terms are "borrowed" from English)
- Internationalization refers to the overarching framework or architecture of an application to support multiple languages, multi-byte characters, different sorting orders and ease of Localization; which is described under Localization below.
- An Internationalization framework includes multi-language, multi-format (date/time/address), and, for eCommerce applications, multi-currency capability. Specifically, we are talking about error, warning and informational messages, labels on screen controls and elements, online help, dates, time/time zones, numbers, currency, phone numbers, personal titles (Mr., Dr., Mrs., etc.) and postal addresses.
- Localization (L10N) is when an entity (group, company, engineer, third party, partner, etc.) converts the current language application to another language.
- An application must be easy to Localize by separating all user viewable messages into one “area.” Someone who is converting the application from one language to another need only look in one area to convert/translate the messages, as opposed to searching throughout the entire application looking for and hoping they find all the messages/text that could be displayed to a user and, thus, need to be converted.
Critical Internationalization (and Localization) Requirements, by Category
Documentation defining the process to Internationalize / Localize the application is always necessary.
- User selectable language within a website or system
This requires that more than one language be supportable by a single instance of the system (rather than running a separate system for each language)
- Ability to switch from one language to another within a session (i.e. “on-the-fly”)
This is only required for certain kinds of websites, but it should be kept in mind as an issue for anyone developing a truly Internationalized site.
- Messages (error, alerts, informational) should be in the language chosen by the user.
A fall back strategy is that messages are displayed in the language of the localized version of the site.
- Support for the ISO/IEC 10646 Unicode universal character encoding standard used for representation of text for computer processing
- Applies to characters, numerals, special characters, and diacriticals
- Supports left-to-right AND right-to-left AND vertical input and reading
- ‘BIDI’ (Bi-Directional) support:
- Middle Eastern languages such as Hebrew and Arabic are written predominantly right-to-left.
- Numbers are written with the most significant digit left-most, just as in European or other left-to-right text.
- So the complete document is bi-directional in nature, a mix of both right-to-left (RTL) and left-to-right (LTR) writing. Text written in the Hebrew and Arabic languages is often referred to a bi-directional, or ‘bidi’ for short.
- Cultural sensitivity to use of color, graphics, and symbols
- Observe that many colors, graphics, symbols, and words that are suitable for the western culture may have different meanings and may even confuse users from other cultures.
- For example, the red color indicates stop in the US but it might not be the case for other cultures.
- An envelope graphic may replace the mailbox graphic that is used as indication for "email". The envelope is easier to recognize for users from other cultures than the mailbox.
- Many Western languages are written from left to right, but Arabic and Hebrew are written right to left, and this orientation can affect the interpretation of visual cues and icons. For example, an arrow pointing to the right can mean "continue" in the United States but just the opposite in countries where Arabic is spoken.
- Sensitivity to etiquette, policies, tone, formality and metaphors
An excellent example to illustrate this point is the example of AttrakDiff, used at the beginning of this posting. Great effort was taken by the AttrakDiff team, including extensive ethnography, online surveys, interviews and so forth to ensure that the German was well-translated for English speakers. Literally translated German can seem gruff and overly formal in tone to many English speakers.
- Support for Arabic lunar calendar
- By default, the system must support all currencies as by ISO 4217 standard.
- Currency should be displayed using common currency codes (e.g. USD, EUR, GBP) or currency symbols (e.g. $,€,£).
- Transactions/monetary amounts should always be stored with a currency attached.
- All screens displaying summary account information will allow for the ability to display amounts in user-selected currencies.
- Monetary values must have a precision of 18,3 digits
- Some countries have multiple interchangeable currencies so we would need to support these. For example, Argentina permits the Peso & the US dollar (1:1), Belize permits the Belize dollar & the US dollar (2:1)
- Many other issues with banking systems…
There are issues such as International identification of banks and accounts, but that is beyond the scope of this summary.
S1 Teller provides a base set of transactions and core services necessary for fulfilling the rigorous requirements of today’s teller environment, including host communications, sharing and storing of information, cumulative totals, electronic journal, transaction security and approval, and balancing aids.
UX Design Research and Key Insights
Under my leadership of UX at S1, Enterprise Teller received the benefit of extensive ethnographic study of bank branch culture, including many depth interviews of Tellers and bank branch management. A number of banks, in different regions of the U.S. participated in these studies. Enterprise Teller also went through numerous iterations of prototyping, usability testing and design.
The "Master" Insight: The work of a teller requires effective interaction in a work environment that differs significantly from the work performed by users of consumer-oriented financial systems (e.g., web-based Personal Banking). Some of the key aspects of Teller's unique needs are:
The only part of Enterprise Teller that I can show is the screen shot shown here, as there is no demo available for public viewing (a policy decision of S1).
Click on the image for a larger view.
S1 Personal Banking provides self-service capability to customers of banks for basic functionality such as account balance lookup and online bill payment.
The general "look and feel" of S1 Personal Banking can be seen in the standard Balances screen shot shown below:
Click on the image for a larger view.
The names of commands, navigation structure, layout and so forth were refined through many iterations of observation, depth interviews, terminology/categorization studies and usability evaluation (ranging from Expert Reviews to full lab-based Usability Testing with large numbers of participants).
This extensive UX work notwithstanding, many banks want S1's Personal Banking system to be branded according to their own internal standards. For this reason, the ability to customize was built into the technical architecture of most S1 products, including Personal Banking.
One of the first banks to apply a radically different appearance to S1's Personal Banking system was Regions Bank. Their re-design was so good that it was adopted as an example in the official S1 Design Pattern for Navigation. An early version of this customization is shown in the screen shots below:
Click either image for a larger view.
Regions Bank has gone through a total corporate re-branding and they have refreshed their version of S1 Personal Banking accordingly. To get an idea of the current state of Regions Personal Banking, click here.