In early 2003, Pathfinder Associates contracted with a large user interfaces in Arabic.  The project was to create data gathering and logistics management applications for educational reform activities in an Arabian Gulf state of under a million people.

We  would be responding to the unique challenge of creating  a bilingual  application for those local users, who themselves com- prised members of multiple cultures. Thus, we were  not tasked  with globalization, which assumes  the creation  of a base  design  that can be changed to meet the needs of multiple countries,  nor with localization, the process  of infusing a specific cultural context into a pre- viously internationalized product. Nevertheless, we would find ourselves addressing many of the issues relating  to both of these activities.

The Arabic interfaces desired by the research firm had to be usable to workers with varying degrees of technical expertise who needed to complete time-sensitive tasks. These tasks included gathering data on the classes each student was taking, and then tracking exams through the phases of the testing process(such as distribution, grading, and recording) using barcode scanners. In one case, the application inter- face was to be implemented in both Arabic and English. Of key interest to stakeholders was obtaining reliable data and implementing a manageable national assessment process involving millions of exam documents and hundreds of schools.

Background

The first phase of the project began in August 2003 and called for the development of a user-focused, custom web application called “Enumeration” that would enable the research firm to efficiently collect a wealth of data on nearly 100,000 students, teachers, principals, and schools. This application would drive a new—and greatly expanded— process of gathering information about schools, teachers, and students in the Arabian Gulf state. The Enumeration application would be deployed in autumn 2003 for four weeks of data gathering. Users would work on location at schools on laptop computers.

The second  phase of the project  called for the development of an  application called “Receipt Control” that needed to be  usable for both Arabic  and  English speakers with varied  education and  experience levels. Receipt Control would be  used  to manage the distribution and tracking  of exams  in a standardized testing program administered over a four-week period  in the spring  at several  hundred  schools.  The application would need  to handle  nine million exam  and answer books.

Challenges

An immediate  challenge was  that the actual interface  design  would be done  primarily by monolingual English speakers, plus a native Arab speaker on the user experience design  (UXD) team who ended up playing  the role of the team’s cultural expert.  From the beginning, the entire group  would have  to become skilled in thinking in the particulars  of Arabic,  such as bidirectional reading flow (in Arabic,  numbers are read from left to right and text from right to left) and script-like letter- forms. It was  also necessary to gain  an understanding of the cultural behaviors of the project stakeholders, as well as of the ultimate end-users.

Because  of the sheer  magnitude of the project,  and  the resultant need  for vigilance in maintaining the efficiencies and  interrelationships among  all the teams  involved, some of the predictable bottlenecks  inherent  in a development effort such as this were encountered.  For example, our highly iterative design  process, which traditionally  relies on the use of low-fidelity wireframes  and  prototypes,  was  met with some skepticism from a few of the stakeholders who expected a more finished deliverable at each  stage  of development. In truth, we have  often encountered this expectation in our own culture; in this context, it became a cultural as well as a methodological bridge to cross.

Managing a cross-cultural team working on two continents in significantly different time zones also called for creative strategizing. The American project team underestimated the difference in time conventions of another culture, such as work schedules and vacation periods. Also, our end client was unfortunately excluded from sufficient participation in the design review process because of the complexity of the relationships of the companies involved, as well as budget, time, and scheduling constraints. This was a journey of discovery for our team as well, as we found our own cultural assumptions challenged.

The design and delivery of the general user experience were the explicit expectations for the project. However, another project— equally complex—soon emerged. Pathfinder’s UXD team assumed the role of “cultural translators,” doing connection and liaison between two worlds. Researchers have proposed an elaborate strategy to bridge cultural differences in virtual software teams by creating multidimensional cultural “profiles” to be employed as a framework for team development; we largely proceeded more informally and directly.

Throughout the entire lifecycle of the projects, a relentless and unforgiving timeframe exacerbated the difficulties inherent in this complex project. This was compounded by the sheer number of people involved and the diversity of their skill sets, which drove many aspects of the business process. Involvement of so many people  in so many different aspects of the project necessarily dictated a waterfall of decision-making. Obtaining consensus or agreement had  to go through many levels of approval. Every change had a cascading effect on the other aspects  of the project.

Solution: Process 

We started with our highly visual, iterative UXD process  because we’d had  success with our methodology on previous  projects. In particular, we felt that our Requirements Visualization process would overcome  many communication and logistical barriers.

Initially, we built and delivered prototype screens to the research and data analysis firm to pitch the project. Based on these prototypes, a three-year project commitment was awarded to the firm, with Pathfinder commissioned to address the user-experience aspect of the application.

Our high-level process included the following steps: Wireframes were iterated with business, development, and linguistic experts at an early stage to resolve issues in information architecture. Next, click-through rapid prototypes were created and used to distill business logic details and nuances. We created a style guide to guide future design enhancement. We developed a translation strategy to anticipate the placement of text on the screens.

Soon, the task flows and wireframes our team created became the vehicle for fleshing out requirements and deliverables for business and technology teams. These became widely adopted and were the primary tools used across team functions and disciplines, bridging language gaps and skill differences. The development team, business analysts, and stakeholders negotiated priorities and scoping using these tools as well. Hence, our deliverables were woven into every project plan. The lesson learned from this experience was that our Requirements Visualization strategy was even more critical for cross-cultural projects.

Our user-centered approach was improved and refined over time. Example personas and Requirements Visualization became part of every project plan. Additionally, sessions of rapid prototyping that included UXD and lead business analysts in the Gulf state permitted user feedback to be implemented quickly in iterative mode.

Our user-experience design lead, a native Arabic speaker, served as our cultural “bridge” throughout  the project, and provided essential skills and capabilities. In addition to linguistic fluency, her personal knowledge of the target school system provided domain expertise. She was  sensitive to the unwritten subtleties of cultural differences and facilitated many of the project processes.

In execution, we predictably encountered a combination of wins and losses. The most critical absence we experienced was the lack of sufficient user data. Unfortunately, we were extremely constrained in our ability to employ user research, and there were few resources to consult for meaningful  firsthand research. Field observations, interviews, and anthropology studies would have been very helpful to the process as well.

We would have preferred to conduct more extensive formal usability testing. The optimal amount of testing could not be conducted due to several constraints. First was budget, as time and travel across the globe are very expensive. Second, was our limited access to users, as many are employed only during the four-week enumeration and four-week testing period.

We had a single opportunity to gain feedback from a combination of stakeholders and end-users, but again, large-team dynamics and cultural differences dictated the format. We wanted to do individual testing, but that proposal was rejected, in part because the client team preferred to obtain respondent feedback in a group setting, much like a usability focus group.

Our work in many ways expanded upon the notion of culturability, or the merging of culture and usability. Reflecting on the development history of these multiple applications, we realized the importance of four components of the projects:  translation, information architecture, visual design, and interface development.

Translation

Creating applications in a target language other than one’s native tongue is a daunting prospect; the vast differences, on many levels, between Arabic and English contributed to the challenges.

The correct expertise in key roles is of primary importance. Language proficiency without cultural knowledge is insufficient and complicates the translation process in many ways. Although this insight appears self-evident, it was crucial to our complex translation process, members for which were distributed among Texas and Illinois in the United States and Egypt and the Gulf state in the Middle East. These sensitivities range from an awareness of the nature of formal Arabic language to the contextual usage of words in the local dialect.

Information Architecture

The information architecture (IA) for these applications needed to be optimized for repeatable, efficient, task-based interactions. Additionally, we discovered the influence of the IA in guiding the processes that were taking place within the users’ physical environments or in facilitating goal-directed tasks. We strove to facilitate human performance in entering (and avoiding re-entering) large amounts of data in Arabic. Workers are time-constrained because the schools close at specific times each day. Workers had a range of technology experience, most toward the lower end. Additionally, we learned that in one specific user group (comprising workers foreign to the Gulf state), there was a hesitancy to ask for help. Thus, the interface would need to be very intuitive and lead the user easily from one step to the next. In Receipt Control, for example, the interactions of the application were optimized for linking documents and contextual data-finding to minimize errors in the data. Thus, physical process was modeled in the interaction.

In Enumeration,  the IA dictated how the physical  process was sequenced. Information was input in the following order:  principals, teachers, and students. In this intentionally linear  process, input fields were grayed out until the preceding steps had  been  completed—but all the necessary steps were visible. Over the duration of the projects, we refined our methods and reduced time and errors significantly. Initially, there were many contextual miscues resulting from the translator’s inability to select appropriate terms. Also, there are dialectical changes to local Arabic from formal Arabic. Some words simply don’t translate literally but must be described in alonger, more conceptual way. This is fine as an abstract notion, but potentially challenging if you have eighty pixels of width for a button. Arabic does not have the concept of acronyms, and many technical terms caused translation challenges.

Because one of the applications would be used by two sets of users that were mutually exclusive linguistically, we were required to design a flexible information structure that could be reversed, enabling one design to function for both right-to-left and left-to-right reading patterns. Page layouts had to take into account the wider and taller Arabic fonts. However, our interchangeable localized interfaces meant that there would be one set of code to manage. Using the same single interface page and source code, we changed the look and feel of the page based on the current language being displayed. Our application detects the current language being used and supplies the user with an appropriate interface based on their language needs using a single code base. For the Arabic interface, all fields shift to the right so that the fields appear to read from the right; users type from right-to-left; the text is in an Arabic font and the scrollbar appears on the left.

The user tasks addressed were not overly complex, but needed to be accomplished repetitively at high speed. So, fewer steps would result in greater efficiency. The IA solution was contextually sensitive, supplying activities on an as-needed basis. This minimized interruptions to the workflow. To lessen the burden of repetitive data entry, solutions were devised to synthesize data entries with a single click. By employing strategies such as these, we were able to make the transition from features to flow. Rather than assembling a patchwork of disparate functions, we were able to draw the applications and the end users into a closer, more satisfying relationship.

Prior to final completion,  behavioral nota- tions were expressed in all wireframes  to assist communications  with developers. The actions of each  button, click, and  input field were thoroughly documented to avoid  ambiguities and errors in the costly development stage.

Auditory Interface Design

We learned the importance of sensitivity to the physical environment. Strong visual and sound cues can be especially important in extending the interface off the screen and cutting through the chatter of different environments. The Receipt Control application required users to monitor data on test documents using a barcode scanner in conjunction with the web application. Using HTML and JavaScript, we created a barcode scanner interface that accepted an input stream from the handheld barcode scanner, validated the stream, broke it down into component pieces, and then displayed the data on screen in a dynamically growing table. After all codes were gathered from documents in a batch, the entire list of barcodes was submitted to the server for processing. This process benchmarked at thirty-five to forty barcodes per minute, or 2,100 to 2,400 per hour.

For users, Pathfinder had to find a way to respond to the user when a bad or duplicate barcode was scanned. Two different sounds were selected: As the barcodes were validated, workers heard a single error sound for a bad barcode and a double beep sound for a duplicate code. This auditory reinforcement let workers monitor their input without being distracted from their primary data-gathering tasks.

Help as Needed

Appropriate and  timely exposure  to help information allowed  users to anticipate events, which built a sense  of comfort and trust in the interface.  We  designed a floating moveable Post-it-type information popup using only code and  markup.  When  the worker holds the mouse pointer  over an icon, an information note pops  up with directions on how to use the page. Moving the mouse off the note closes it. Clicking on the note makes it “stick” to the page; it can  be moved  around and  set aside  to provide  direction  while the user adds  data  to the page.

Visual design

The two applications were visually linked through the use of a custom-designed Arabesque pattern at the top. The two applications are distinct but feel related. Color combinations were refined over iterations to accommodate cultural preferences and the work environment. The resulting design resonated with the local users. By using traditional Arabic patterns as a linking element across applications, the visual language also captured the essence of the reform effort.

We employeda rigorous approach to visual systems. Icons were designed to draw attention to actions and transcend the reliance on language. We had to ensure that icons worked culturally, as they are read like text. Pictures are orientation-based; buttons are flipped in form, as well as language. Typography was a challenge. Compared to English, Arabic words occupy more space horizontally and are set, with the chosen typeface, four points larger than the English font. Letterforms change, depending on whether the glyph is at the beginning, middle, or end of a word, altering the rhythm of ascenders and descenders. Arabic fonts had to be bold to be legible.

Over time, the color choices were refined to higher-contrast colors and clear typographic hierarchies because of the environment in which the applications would be used, and the repetitive nature of the tasks. Our user feedback alerted us to an apparent cultural preference for stronger, brighter colors.

The primary  result was  the evolution of palette  and  contrast  levels from Enumeration 1 to Receipt Control 1 to Enumeration 2.  Less ornamentation, less texture, and  fewer visual distractions  reflected  the realities of task-specific interactions.

Interface Development

Others’ research on the Arabization of GUIs prepared us somewhat for development issues and constraints, but in true pioneering fashion, we managed to come up with a few challenges of our own.

Due to the business  requirements  guiding the design  and  development, the applicationwas  to be deployed in a browser, yet function as, and  appear to be,  a desktop  application. This platform choice  had  a downstream effect on all aspects  of the project.  The applications were  standardized for Microsoft Internet Explorer (IE). However,  IE is coded in English, adding another  layer of translation.

Additionally,  programming was  restricted to the use of HTML and  JavaScript  to maintain customizability and control of the application through future iterations.  However,  this choice meant  that functionalities such as objects and system-level controls could not be used.

This had  a consequent impact  on coding. There was  considerably more client-side coding, estimated  at 10,000 lines for the twenty-five to thirty screens  in Enumeration 2, which complicated other translation  issues like page orientation.

As with interface  and  visual design,  the building  of the applications had  to accommodate  English-language development. We worked  out most issues in English, and  then transferred to Arabic.  We  set up a production system that allowed  us to code  using the English left-to-right direction  and  create  a single interface  that would work in both directions and  both languages with only minor tweaks—two style sheets, one interface. Our process evolved to building the page backwards in English with images flipped. Then we would drop new images in after translation and tweak accordingly. This involved changing the direction of the page in HTML by adjusting coordinates and directional flow of text (left-to-right to right-to-left).

Our initial interface design used fixed-width Arabic fonts in input cells and tables. However, after reviewing the final interface and obtaining user feedback through testing, we found that the Arabic readers found the fixed-width fonts to be illegible. We performed a complete font study with our users and decided to use a more standard proportional Arabic font that gave us greater clarity and readability. These changes were made in the style sheets, providing us with an efficient change across the interface.

In the “school classes” page of the interface, individual students from a list of all students in a school get grouped together into academic classes. We employed dynamic drag and drop interactions with floating windows to speed the formation of these groups. Users are able to select more than one student and then click and drag these students to a holding area to form a group. This strategy made the interface three times faster than adding students to the holding area one by one.

Results

Pathfinder‘s UXD strategy enabled the design to work in the Arabic culture, yet be produced by a largely English-speaking team. The effectiveness of our solution enabled us to create design methodology conventions that could be re-used across cultures. Our deliverables were produced on-time and within budget. Additionally, we found we were able to leverage many of the design and development processes created for this project across a wide variety of clients and projects.

For the client, timely enumeration and exam tracking was achieved on a national scale. The applications are now going into a third year of use. Successive iterations of both applications with incremental improvements have proven the basic design to be solid.

We achieved these results for the end users:

• Saved time in the data collection process by creating drag and drop functionality like a desktop application. This advanced interaction delivered the twin benefits of increased speed and a more enjoyable experience.
• Used sounds to increase the efficiency and accuracy of tasks that had to be repeated thousands of times.
• Created an information architecture that brought information to the users contextually when they needed it. Users were not compelled to “click and wait” for help text but were able to enjoy more efficient task completion.
• Created an interface that connected with the local preferences for design and visual cues.
• Created guided processes, increasing the speed and efficiency of high-volume, goal-oriented tasks.

During our interface design process, we created strategies that can be re-used for effective Arabic-English user-experience design and for other languages and cultures as well. The key points are as follows:

• Ensure that you have a person who can function as a “cultural expert,” equally familiar with the home and target cultures.
• Develop rapid prototypes and vet them with users early and often.
• Have everyone on the design team develop a clear understanding of the target language structure, flow, and letterform variations.
• Check to make sure technical terms and abstract concepts can be translated.
• Have everyone on the team understand at least the basics of the cultural preferences for visual elements.
• Keep a translation glossary.
• A design team in situ can facilitate effective and timely communication.
• If possible, design layout structures to flexibly accommodate both English and the target language.
• Develop and test a production translation model.

 

 

[bluebox]

Additional reading

• Badders, Leon, Komlodi, A. International User Interface Design Topics.
  Definitions of globalization and localization (PDF)
• Erumban, Abdul Azeez, de Jong, S. B. “Cross-country Differences in ICT Adoption: A
  Consequence of Culture?” (2005) SOM Research School
• Dafoulas, Georgios, Macaulay, L. “Investigating Cultural Differences in Virtual Software Teams.” Electronic Journal on Information Systems in Developing Countries. (January 2002)
• Hofstede, Geert. Cultures and Organizations: Software of the Mind. McGraw-Hill (London, New York 2005)
• Barber, Wendy, Badre, A. “Culturability: The Merging of Culture and Usability” Proceedings of the 4th Conference on Human Factors and the Web (Basking Ridge, NJ, June 1998)
• Portaneri, Franck, Amara, F. “Arabization of Graphical User Interfaces.” Published in International User Interfaces

[/bluebox]

[greybox]

This article was reprinted from the DUX 2005 Proceedings by permission of AIGA, the professional association for design. DUX 2005 was the final World Usability Day session. Pathfinder Associates also presented a paper at the Chicago World Usability Day session.

Thanks to the designers and team members who worked on all the applications, ensuring the success of this project over two years. Special thanks to Bernhard Kappe, Matthew Nolker, Paul Dittmann, Shalom Sandalow, and Kevin P. Wojdak for their help on this submission.

[/greybox]