Around the Interface in 80 Clicks
by Lisa Battle and Duane Degler
Performance Improvement, ISPI, 40(7), August 2001
Read our additional
thoughts on the subject, March 2002
The use of computers
internationally has increased dramatically. The rapid expansion of the
Internet has given people access to the same applications and content
anywhere in the world. With this, user expectations are going
up—users do not want to learn another culture and another language
to perform work.
As the market for
computers and the information they deliver evolves, the types of
people using them will be more of the “late adopters” rather than
the “early adopters.” Donald Norman wrote about the expectations
of these users, that software “truly meets their needs” and
promotes a “good user experience” (Norman, 1998, pp34-36).
Importantly, he also emphasizes the need for “no feeling of
puzzlement, no loss of control.” As designers, we can’t
necessarily rely on current interface conventions that appear to be
“standards.” The tools have to match people’s working needs, and
now for many people their lifestyle needs.
expectations are strikingly similar to the expectations we have seen
for software to be usable, with market demand growing steadily over
the past 4-5 years. We believe the demand for software that is usable
across languages and cultures is the beginning of the next wave of
demand from users—and the next great challenge for software
designers. Software can and should make an extra effort to provide a
good user experience.
internationalized software is difficult in part because of the lack of
guidance within the practical literature of software design. The
ordinary software developer, the project manager, and the consumer do
not have ready sources of non-academic information on this subject.
Those books or web sites that deal with the subject tend to be focused
on cultural investigation/analysis (del Galdo & Nielsen, 1996) or
on detailed programming/translation guidelines (Cross, 1999; Ebben
& Marshall, 1999; Sun Microsystems, 2000; W3C, 1998). How do these
guidelines translate into the practical design of applications and web
sites? There is a need for more holistic checklists of what to think
about when designing for the international user (Ishida, 1997). This
is why in this article we have tried to cast a wide net across a range
of subject areas.
We are user interface
designers and performance support specialists. We are not experts in
internationalization; however, this subject has come up repeatedly in
the course of our work. We have been asking ourselves the question:
what do we mean by performance, and is it possible to support it
internationally? As a result, we have started building our own
checklist of questions and issues we think need to be addressed when
designing software for international audiences.
design and performance support are not just about helping people use
software applications—rather, they aim to help people perform
real-world tasks successfully and increase the quality of the
outcomes. This increases the importance of providing localized
support. It isn’t enough to describe in a particular language how to
enter data into the software. We need to think about describing how to
perform a job successfully within another cultural context. In
addition, many people are increasingly doing knowledge work. For them,
it isn’t enough to support a task; we also need to be thinking about
supporting knowledge acquisition and use across cultural boundaries.
Culturally restrictive software could potentially get in the way of
that goal. The more we try and make things context-relevant for one
group of users, the harder it is to make things culturally relevant
In their book
International User Interfaces, Elisa del Galdo and Jakob Nielsen
outline three levels of international user interfaces, and confirm
that once you pass level one, there is insufficient expertise and
experience (del Galdo and Nielsen, 1996, preface). The levels are:
Process and display
the user’s native language, character set, notations, and
Produce an interface
that is understandable and usable in the user’s
internationalization and localization tend to become lumped together,
and there are several definitions of what they mean. While they are
closely related, they can usefully represent two ends of a design
spectrum. We define internationalization as creating representations
that are equally understandable across different cultures. In some
cases, this can be achieved through basic symbols (such as arrows, or
icons based on objects in nature) that are easily understood. However,
in most cases a symbol has to be learned, and thus the use of
international symbols leads to a “one-size-fits-all” standard that
takes time to become familiar. Eventually, users can learn to
understand and conform with de facto standards.
least in its ideal, involves adapting the software to the language,
culture, and norms of the local culture, so there is no cognitive
dissonance or need for the people to translate. In a way, localization
is like setting group preferences—a collective some levels above
user preferences, which tailor an individual person’s experience by
allowing him or her to specify how the computer should interact.
There is an implied
diversity in localization, because the software should support the
diversity of culture. In fact, due to the way localization often has
to be implemented practically, this is a false diversity. Translating
into a language group is not the same thing as translating into a
culture. When companies prepare international versions of their
software, a translation into French is considered sufficient for all
of France, Belgium, Quebec, Martinique and several countries in north
Africa. A translation into German is considered sufficient for
Germany, Switzerland, Austria, etc., just as English is suitable for
Britain, Ireland, North America, Australia, New Zealand, South Africa,
and anyplace else a specific language group is not catered for. The
reality is that while these places do belong to a language group, the
dialects, spelling, vocabulary and culture are often very different,
and there are different metaphors and ways of working. Translating the
language only is what we call “linguification” rather than
localization. There is an expectation that the user will still make
the effort to bridge other cultural gaps.
There are a number of
things that tend to get the most immediate attention – partly
because they are very irritating to users and partly because they are
easier to identify and fix (although the people doing it might not
think so at the time!). The purpose of this article is not to dwell on
these things, which are covered in detail in other places, but they
deserve a mention. These include:
application or web site and performance support elements into
major language groups. Allow for further translation of content
elements (such as help files) locally by representatives of the
space for text to expand when it is translated into other
languages. When designing screens, make sure that text can wrap
without ruining the design or truncating the text. If the screen
will contain a combination of message text and data, consider
the effect of concatenation on the translation.
Do not lock all
addresses into a “state and zip code” format. Most countries
have counties or provinces or districts or cantons (and they
rarely are two letters long) and post codes that are not five
sequential numbers. Include a “Country” field in addresses
and allow the selection of country to influence the display of
Do not lock all
telephone numbers into “area code / number” format,
particularly the 3 x 3 x 4 number format. This applies to both
the field formatting in the user interface and to data
validation. For example, a popular travel web site surprised us
by requiring the user to enter a phone number in a specific
US-based format. It actually validated the field based on that
formatting and returned an error message when the format was not
followed, but it never openly informed us of the required
Allow dates to
be entered and displayed in the standard format for each
country. Fortunately, operating systems allow users to set the
format. Software applications should use this default, including
both the sequence of numbers and the appropriate separator
appropriate symbol to denote the local currency. Allow the
symbol and any special characters to be positioned appropriately
in relation to the numbers. There may also be a need for
multiple currencies to be represented at the same time, to
eliminate the need for manual conversion.
entry in units of measure that are familiar to the users and/or
consistent with the source of the information, to eliminate the
need for manual conversion. For display, consider converting
data to familiar units of measure in certain circumstances if
doing so would increase comprehension without the risk of
miscommunication. Always be explicit about the unit of measure.
and symbols to make sure they are understandable, and replace
with local variants if appropriate. This is particularly
important where icons are derived from familiar objects that are
country or culture specific (such as mailboxes and
representations of people that are acceptable to users in each
culture. Gender, race, dress style, physical setting, and
non-verbal communication are all issues that affect the
conscious and subconscious “acceptance” of messages. This
issue relates not just to photos and video clips but to
animations, cartoon characters, symbols, and icons.
performance for an international audience, we need to examine the key
elements of performance in relation to the design of systems. The
three-element model of performance design that we use is the one
introduced by Gary Dickelman a number of years ago (Dickelman, 1996).
The elements are the performer, the process, and the information,
which must all be integrated (see Figure 1). Optimal performance, or
the “performance zone,” occurs when all three of those elements
are working together. If a software product does not take into
consideration a whole range of international issues, it can break the
link between those elements. We will take each one in turn and look at
what happens when it becomes disconnected.
1: Key elements to designing for performance.
When we are dealing
with internationalization, the primary focus is the performer—not
just as an individual, but as a cultural group. The product designed
for a performer in one cultural group may not work for people in
another. Imagine that we have taken the three-element model of
performance and removed the “performer” circle, and then attempted
to replace it with a different one (see Figure 2). The new
“performer” circle does not fit because the parts are not
interchangeable. To reconnect the performer with the process and
information, we have to understand the attributes of the cultural
group. To plan ahead for supporting a process with an international
audience, we analyze it by asking questions like these:
2: Disconnecting the Performer.
What major language groups and local languages do the
performers speak? Where do they live?
What differences exist between local languages and the
major language groups? What meanings are associated with regional
What differences exist between spoken and written
What style and tone would people in this cultural group
consider credible for a computer application? What style and tone
would people consider helpful and friendly?
In what other ways might the language create a distance
between the user and the application?
If the user will need to adapt to a different regional
variation of their language, how can we minimize the burden?
Is there a particular challenge in localizing for tonal
languages such as Thai, which require specific written conventions to
capture the shades of tone?
How do performers normally think about and represent
What date formats are considered standard? Do performers
deal with multiple formats?
What day does the week start on?
What other time periods are frequently used?
If the application refers to special days or holidays,
have the implications been considered for all countries? Will the
application recognize the holidays and special days of another locale?
Are generic designs really generic or do they contain
implicit cultural assumptions?
Do different ways of reading create expectations about
the flow or placement of information?
Which parts of the screen are likely to be viewed first
Do habituated skills (e.g. touch typing) conflict with
any part of the design? How does the performer’s equipment differ
from the design requirements? How might those differences affect task
Are there local expectations about the display of
information such as proper names? Can the software be configured to
match those expectations?
Are literal representations in icons going to be
recognizable to the performer?
Are "generic" visual symbols going to be
familiar? Do they mean the same thing across cultures?
If spoken language is used, what cultural biases do
people have about regional accents?
Do certain colors have political or religious
significance for the performers?
Do colors have other recognizable meanings for the
performers? If so, do these meanings conflict with the intended use?
Is it possible to configure colors if necessary to
better match the performer's cultural context?
Is the performer working in more than one country? If
so, how does this affect their needs and expectations?
What can be done to make their transition from one place
to another as seamless as possible?
Perhaps the most
obvious difference between groups internationally is the native
language. We mentioned earlier that the “linguification” approach
to preparing international versions of software involves translating
into a major language group, not the local language that people
actually speak. We recognize that there may be a practical limit to
the number of variations that can be produced, and that people are
usually flexible enough to adapt to a different variation of their
language. However, when taking this approach, the designer, content
writer, and translator should consciously look for ways to make the
user’s experience less dissonant.
To achieve this,
translators should avoid using words or phrases that are too specific
to a locale. The choice of vocabulary, including any slang or
references to specific places or events, should be as generic as
possible within the major language group, so that it will be
understood as widely as possible. Words that are unfamiliar or sound
“foreign” will likely distract the users from their task and make
the application seem less supportive. The language used in the
application should convey the appropriate level of authority (for
example, policy statements should sound authoritative) and the
appropriate tone (for example, helpful hints may be more or less
formal in tone depending on the audience expectations). It is worth
considering that in many languages, the written language and the
spoken language are different—the written language is far more
formal. For example, in French the way that ordinary people speak is
radically different from the formal written language. Designers need
to consider which tone is most appropriate for the content and the
audience. As always, it is important to have a native of the region,
not just someone who speaks the language, working on the actual
translation to influence these decisions.
difference between cultural groups is the way that they think about
and represent time. In working with computer systems, users frequently
deal with time elements—sorting lists in date or time sequence,
entering time periods for queries, receiving reminders of due dates,
scheduling appointments, making reservations, and so on. It is
important to make sure that any time elements are designed to be
familiar to the target audience, since they are so often encountered.
Diverging from local expectations can create significant attitudinal
and performance barriers. For example, we consulted on one project in
which users who were responsible for a scheduling task complained
about being expected to enter start and end times on a 24-hour clock.
Because they were accustomed to a 12-hour clock (clarified with AM and
PM), they had to stop with each entry and calculate in their heads the
correct time as required by the system.
Earlier in this
article we touched on the subject of date formats. Interestingly,
people who work internationally and have experience with different
standards for date displays may need more help in interpreting dates
than those who do not. During one international design session, we
noticed that Europeans (along with those of us who are “adopted
Europeans”) would habitually write out the name of the month for the
first 12 days of the month (e.g. “12 Jan 2001”), but would switch
to all numbers when writing the remaining dates (e.g.
“13/1/2001”). This was a way of avoiding dates that appeared
ambiguous (e.g. “12/1/2001”—is that December or January?).
Designers should look for ways of removing this ambiguity without
increasing the burden on the user. We are skeptical of a recent trend
in web sites to use three drop-down selections for each date to be
entered, which eliminates the ambiguity but increases the data entry
burden. This is acceptable for infrequent use and the entry of one or
two dates, but not for regular use.
Time periods are also
different from one culture to another. Probably the most commonly used
time period, the week, is not as straightforward as one might expect.
In the US, the calendar week starts on Sunday, whereas in other
countries it is common for the week to start on Monday.
If the labels on a pop-up calendar are not very clear, a user
might easily overlook this difference and make an error. Some
applications allow the user to search for transactions entered “last
week” or “this month” instead of entering start and end dates in
the search criteria. Designers must consider the cultural assumptions
inherent in these phrases when preparing for an international
audience. A phrase like “the current tax year” would have a
different definition in different countries, while a phrase like
“the last fortnight” might not translate at all. Colloquial
phrasing has been known to produce pitfalls (consider the phrase
“half eight,” which means 8:30 in the UK and 7:30 in some other
Special days and
holidays, of course, differ from one country or culture to another.
Even with the growing awareness of diversity and multi-cultural staff,
we would avoid reference to special days if possible. There are
exceptions, such as help content, training materials, or performance
support tools which need to provide relevant examples and
context-specific information to support the user’s job. For example,
a performance support system for a retail application in the US would
have to mention the Christmas season and the back-to-school season,
since these are a key part of the user’s work context. However, if
this performance support system were made available to an
international audience, the content would probably have to be
completely rewritten. Other exceptions might be calendars, scheduling
applications, and collaborative software environments, where informing
users of a cultural circumstance such as a holiday can be critical to
People in different
countries or cultural groups tend to have different expectations of
how things work. Their conceptual models are shaped by experience in
different environments. Through experience, many behaviors become so
skilled that a person no longer pays conscious attention to them (in
the field of psychology, such behaviors are said to be automatic).
These behaviors are very likely to be culturally bound. If we are good
designers, we are already trying to design things that work the way
people expect them to, but the possibility of an international
audience complicates this task. We believe things that may be
considered generic in design are in fact only generic because of the
cultural conventions of the designers and current majority of users.
When preparing products for international audiences, we need to
examine our assumptions.
Users may have
different expectations about the flow and placement of information on
a page. The standard of reading across from left to right is a Western
cultural expectation; Arabic cultures read right to left and the
Chinese traditionally read from the top right to bottom left. We do
not know how the user’s comfort with the software application is
affected by a change from the traditional direction of reading and
writing. We suspect that even if the user adapts to a seemingly
“unnatural” screen display, their culturally traditional reading
direction may still impact eye movement. Generally, we consider the
top left of a screen to be the “entry” point, with the lower right
being the “exit” point – that is why common commands, controls
and titles are top left, and often buttons (such as “Next”) are
placed toward the bottom right. Thus, cultural background may
influence user performance with directional actions and may suggest
the optimal placement of controls on a screen. We hope that in the
future, the eye tracking research being done in the field of
human-computer interaction may be able to clarify this.
People in different
countries also use equipment that works differently. A prime example
of this is the computer keyboard, which has a different layout in
different countries. This could potentially affect performance for
users working with software that was originally designed for a
different keyboard—special characters or control characters may not
be there. We have heard from people working abroad that this is
especially challenging for touch typists who are forced to move from
one keyboard to another. For example, an American who was recently in
Eastern Europe told us that she had been surprised to find a keyboard
missing the familiar “@” symbol—to type this symbol, she had to
learn the key combination “ALT-64.” Some of the differences affect
the keyboard shortcuts that designers provide to speed up tasks for
expert users. For example, Figure 3 shows the different placement of
the CTRL+Z key combination on the German (and various eastern
European), French, and US
3: Variations in key position lead to potential errors
problem with different keyboards is the potential lack of special
characters needed for correct spelling of proper names. For example,
we heard from Americans working in Bosnia that the original Bosnian
voter registration was done several years ago by international
observers who did not correctly enter the special Slavic characters in
people’s names. There are two different accented versions of the
letter “C” and three versions of the letter “S”, but the
internationals simply typed “C” and “S” (probably using
American keyboards that did not contain the Slavic characters). This
caused significant problems in subsequent elections, when Bosnian
voters returned to the polls and were told that they were not
registered to vote, because their correct names could not be found in
the database. The voters were angered and much time and effort was
spent re-entering voter records.
There are also more
subtle differences in proper names across countries. The sequence of a
person’s name—as well as what the “first” and “last” names
are called—is a cultural convention. For example, in some eastern
European countries and in Asian countries a person’s family name is
written before their given name, without any punctuation between (e.g.
“Washington George”). An application that did not respect this
convention might be harder for users to adapt to because it would
require extra mental effort. There may also be other local conventions
about the display of names. For example, in France a person’s family
name is always printed in all caps (e.g. “George WASHINGTON”). An
application that did not respect this convention would still be
understandable to the users, but would continue to seem foreign.
and implied meaning
difference between cultural groups is their understanding of
symbolism, which encompasses visual icons, sounds, colors, and
metaphors. Some symbols that we consider generic are actually a matter
of cultural convention. For example, we know of a large-scale
computer-based training initiative in a multinational corporation
where symbolism led to significant performance problems. The training
department was surprised to find that while Americans were scoring
high on the CBT, most Germans were failing. Upon investigation it was
discovered that the CBT required users to click on a checkmark icon
for “yes” and an “X” icon for “no.” In Germany, the
“X” meant “yes,” so many users were selecting the opposite of
their intended answer. Other symbols that represent real-world objects
may not be understood across cultures (for example, a literal
representation of the US standard manila folder may not be recognized
in other countries). With the rapid increase in web use, people are
creating their own icons and mixed icon/word controls. This increasing
divergence from any de facto “standard” could be a precursor to
greater localization of icons.
4: How far might customization stretch in the future?
interpretation may affect performance when users are working with
audio and video materials. The dialects and accents in spoken language
are automatically associated with meaning. Consider the difference in
effect between a Boston accent and a Georgia accent in the US. The
same type of difference exists in other languages. For example,
speakers of Parisian French tend to think that Belgian French sounds
uncultured and inferior. In some languages the difference is much more
extreme. People in the north of China may not even be able to
understand the dialect of Chinese spoken in the south of China because
the pronunciation and words are so different.
Color can convey
different meaning in different cultures. It can also be unwittingly
loaded with meaning. For example, in Bosnia red is the color of the
Serbs and green is the color of the Muslims. Any use of those colors
can potentially stir up hostile feelings that an outsider would not
have anticipated. However, we believe that color tends to convey
meaning in context, so it may be dangerous to generalize too broadly
about its use. For example, we were in a developers’ meeting when a
requirements analyst cautioned the group that the use of the color red
in error messages might not be good for internationalization, since
the Chinese associate red with happiness. The two native Chinese
developers in the meeting raised their eyebrows in surprise. One of
them said, “Now I understand! This must be why the Chinese drive
their cars with the tachometer in the red, because they feel so
happy… until the engine stops working!”
Metaphors that are
commonly understood in one culture may not translate well to another,
which poses a challenge in design. People who work in the performance
support arena will recognize that the “coaching” metaphor has been
widely used to suggest a friendly expert guide. This metaphor is
frequently reinforced by images or words that tend to center around a
specific sport. For example, we have seen numerous “Coach” buttons
decorated with baseball cap icons and at least one performance support
tool that made extensive use of the football metaphor, including green
“grass” with marked field lines.
We have seen in many
applications the assumption that the performer is situated in only one
country. However, this is not always the case. There are an increasing
number of people who live and work in more than one international
location because of business travel and job postings overseas. We
believe there is a need to provide the flexibility to support those
who do, so that their transitions from one place to another are as
seamless as possible. For example, we noticed that a popular consumer
web site holds a single profile (multiple addresses, credit cards,
etc.) for a person who lives and works in both the US and the UK, but
cannot distinguish where to ship from or what to charge based on the
shipping address selected. The .com and .co.uk sites are different in
all respects except the user’s personal information, but lead the
user to believe they are connected.
When preparing a
product for an international market, it may not be enough to convert
the existing product to a foreign language version. Even if the
information is translated sufficiently to make it understandable, the
processes themselves may not make sense to the performers or may not
adequately support their needs. This is because ordinary tasks,
standard practices, and work environments may differ significantly
from one country to another. The process becomes “disconnected,”
diminishing job performance.
5: Disconnecting the Process
To plan ahead for
supporting a process with an international audience, we analyze it by
asking questions like these:
How is this process normally done in each
country/locale? Is it done at all?
Is the goal or the desired outcome of the process any
different in another place? Are there different standards for
achievement or definitions of “success”?
What other processes or tasks are viewed as related?
Is the expected sequence of tasks different from one
locale to another?
How much control do people expect to have over this
process? Do people expect to be guided or told what to do?
Does the process consist of high-context or low-context
How much does the process depend on policy? What is the
source of that policy?
Is the process affected by differences in working
practice, such as workdays or staffing?
Does the process involve inputs from multiple countries?
Does the process require communication among people who
speak different languages or work in different countries?
How is the process structured in the current
application? In similar or competing applications? What assumptions
are implied in that structure?
There are differences
in standard working practices from one country to another that may
affect how well a particular software application fits into the local
environment. Designers should gather as much information as possible
about the tasks and the work context in other countries to identify
the types of differences that can be expected. For example, in some
European countries it is typical to take a two-hour lunch and extend
the working day later into the evening. A staff scheduling software
application designed in the US would need to accommodate this practice
in order to fit in. The number and types of staff in the work
environment may also be different. We heard from a German in a
multinational corporation that the company’s internal project
staffing processes assumed a much larger and more hierarchical staff
than his branch of the company actually had. One person typically took
on several roles.
There is also the
need to comply with different regulations in different countries. For
example, we know of a large consulting firm that had difficulty
rolling out a training system to its European branches because the
system did not capture course completion dates and status in the way
that was necessary for ISO9000 compliance. Similarly, any software
purchased by the US government is required to comply with Section 508
standards for accessibility to people with disabilities. It is useful
to know about these types of standards and practices as early as
possible to make sure that the design and the business rules are
configurable enough to accommodate them.
Because work is done
differently in different countries, task analysis becomes very
important. The expected sequence of actions, the size and scope of the
task, the inputs, and the standards for success may be different. This
becomes an important challenge for performance support, where the
purpose is to guide the user through the task to achieve a successful
outcome. For example, we sometimes introduce a sequence as a way of
supporting a novice user. However, if this sequence runs counter to
the local organization’s expectations of how the process is normally
done, it may instead increase confusion. There may also be an
expectation of the degree of control that a user would want to have
over the sequence. In some cultures that value individuality, users
may want to exert more control over their actions, while in other
cultures users may not have this expectation. There is also a need to
anticipate which tasks are considered related. For example, in the US
we might think of “change my address” and “change my direct
deposit” as related tasks, because when people move from one place
to another they are also likely to change banks. This is because in
the US the banks are statewide, not national. In many other countries
where there are national banks, these tasks would not be thought of as
related because when people move their bank account stays the same.
We recognize that
this sounds daunting. It is not practical or desirable to revisit all
of the tasks in a software application when preparing for an
international market. In order to focus and prioritize this effort, we
have started to identify ways of categorizing tasks as “high-context
tasks” or “low-context tasks.” In the translation field, others
have written about high-context and low-context cultures/languages. A
high-context language is one in which there are many references to
things that are not spoken directly but are assumed to be understood
by all speakers (Hall, as described by Hoft, 1995). Similarly, we have
defined “high-context tasks” as those that are more culturally
bound. When we review an application, we look for high-context tasks
that will need more attention to localization, low-context tasks that
can be internationalized, and rules that should be made locally
configurable. For example, in a training management application, the
task of registering for a training course is low-context, and we would
focus on making it generic enough to be understood internationally.
The task of creating development plans and mapping learning to
specific job requirements, on the other hand, is high-context, because
it is tied to cultural expectations about career advancement,
employment duration, incentives, and continuing education, as well as
local policy. A third task, getting manager approval for a course, is
medium-context, because although it is related to cultural
expectations, it is more closely tied to internal organizational
rules, and must be configurable.
the work process in another country is a primary goal, we must not
forget that in some situations it is necessary to accommodate multiple
countries or cultural groups at once. For example, it is not enough to
support the local currency if people need to use multiple currencies
as part of their standard work. A few years ago, a review of small
business accounting packages showed they could be configured to accept
input in one of several international currencies. However, once the
user had gone through the setup process and selected a currency, that
currency remained the default, and there was no ability to enter
amounts in other currencies. This was a problem for international
businesses, because the users were forced to manually convert the
currency amounts. Similarly, in collaborative work environments it is
important to support multiple language groups, because project teams
and design groups are increasingly made up of international
participants working in different places, different time zones, and
for an international market is not limited to the language
translation. It also includes making sure that the content is relevant
and understandable. In terms of the three-element model of
performance, even if the process is understandable to the performer,
the information content may not make sense. In this case the
information becomes “disconnected,” diminishing job performance.
6: Disconnecting the Information
To prepare information for an international audience,
we analyze it by asking questions like these:
Does the information support the task?
Can the users read the information in the language(s)
Is the meaning behind any symbolic information
Does the layout seem clear or intuitive to users in
Can the users find the information, and what cognitive
strategies are they likely to use?
How much context is currently provided in alerting or
feedback mechanisms? What assumptions are implied in those messages?
Will any examples make sense to people in a different
country or culture? Is it necessary to write different examples to
make the point or support local guidelines, rather than translating
The basic issue is
being able to read the information. Imagine a situation where you have
just gotten off an airplane in Kuala Lumpur or Delhi. The process of
finding your way around an airport is familiar to you as an
experienced traveler, but there is no easy way to puzzle out the
written language. The “data” on the signs has no informational
value to you. This is exactly the situation that prompted the
development of international symbols for the physical world. These
symbols have become at least recognizable enough to provide the
informational value you need in that context. There is not yet an
equivalent symbolic “language” for software. To some extent this
is what icons attempt to do, and some succeed by default if not by
design, because certain software is now widely used around the world.
Users in different
cultures may have different approaches to finding information. On the
web, seeking strategies are increasingly relying on search. Search is
not the most effective method, but other strategies are affected by
the way that people think about and categorize content, which varies
from country to country. For example, the Library of Congress
cataloguing system is applicable only in the US; other countries may
have their own standards or no standard.
of the layout and organization of information may also be different.
For example, in France, reference books have the table of contents in
the back rather than in the front. We have heard that it takes many
months of frustration before an American student acquires the habit of
taking a book off the shelf and immediately flipping to the back to
see what it contains. If users of our software have similar
expectations that we violate unknowingly, their performance will be
organization of content depends primarily on the type of content and
the situation in which it will be used, culture may also have an
effect. For example, in
Japan it would not be unusual for a user to take the manual home and
read it before working with an application for the first time, while
in the US people prefer to scan a quick-reference card and figure it
out as they go, using task-specific help if they get stuck.
It is important to
review warning messages and feedback for cultural relevance. The
instructions that accompany a warning and specify “appropriate”
action may need to be revised for different audiences. The required
action (e.g. contact the help desk, or policy-specific information)
may be referring to an infrastructure that is not there in a smaller
country. Thus, warning messages cannot afford to be too rigid. This
may be the case even when common international practices are the goal,
such as when carrying out multinational drug trial research. The
standardized software tools must still communicate effectively to
content, it is important to notice any local references and examples
that rely on cultural context and may not translate. We know how
valuable it is to provide examples in performance support, but we must
be aware that an example that makes sense in one country may just
confuse users in another. For example, an application used in the
insurance industry would need examples based on state regulations.
However, if an insurance company were multinational, it would need
completely different examples to reflect the different types of
regulations that exist in countries with a single national regulation.
As designers, we need to build this flexibility into the information
architecture so that it is easy to pull out an example and replace it
with something different that is more appropriate to the culture.
In the past, many
software companies have treated localized versions of the information
as a secondary concern. Localized documentation and user interfaces
are often released months after the initial language version, which
has an effect on product distribution and support. For example, we
recently saw a product that was available on the Internet for
downloading, but only in English. There was a notice asking people to
check back in a few months for the western European language versions.
We suspect that many potential customers would forget to come back and
look again. If they decide to download the English version, they may
not be able to get support from local staff. For example, we heard of
a situation in which European users in a multinational corporation
received a new version of a software package and began calling their
local help desk with questions—only to find that the help desk staff
had not yet received instructions on the product in their language. It
creates a huge hit to productivity and credibility when the support
staff cannot meet their end users’ needs because they do not have
adequate tools available in a language they can understand.
Over many years of
experience in the software development field, we have seen how easy it
is to reflect personal bias and local assumptions into the way that
software works. Breaking those habits is certainly a challenge, but
one that increasingly must be met. While we, like most designers, may
have more questions than answers, there are a few things we can
conclude from our explorations into internationalization. In fact,
most of these principles are also general principles of good
design—when they are done well, we have found that they contribute
greatly to the internationalization effort.
Question your assumptions. Avoid thinking or saying
“…but everyone knows…”
Plan to be international from the start, and analyze the
users and the environment effectively.
Don’t expect it to be too easy if you do it right.
Design applications that are configurable and modular.
Business rules and formats can then be tailored more easily to working
practices in other parts of the world.
Look for ways to remove barriers to performance by
designing for simplicity. The software should be transparent—it
should not draw the user’s attention away from what they are doing.
Create a content architecture that allows content types
to be tagged (e.g. procedure, example) and allows examples to be
replaced with localized variants. When designing performance support
materials, include placeholders for local content and allow customers
to add or modify content that is meaningful within their culture and
organization. It may be impractical for the software provider to
attempt to create all the content.
Focus on tailoring support materials to the culture: if
the software offers support, help, and advice, that support should be
very well targeted to the user’s context. Otherwise, it will
increase frustration by giving information that does not make sense.
The users will begin to distrust the help because it does not relate
to their needs. It is better not to provide support materials at all
than to provide inappropriate support.
the top of the page
Cross, J. (1999).
Internationalize with Localization. Microsoft. Online, Internet.
February 1999. msdn.microsoft.com/library/periodic/period99/vjp9922.htm
(1996). Gershom’s Law: Principles for the Design of Performance
Support Systems Intended for Use by Human Beings. CBT Solutions,
September/October 1996. As read Online, Internet.
del Galdo, E.M. and
Nielsen, J. (eds). (1996). International User Interfaces. New
York, N.Y.: John Wiley & Sons.
Ebben, S. &
Marshall, G. (1999). The Localization Process: Globalizing Your Code
and Localizing Your Site. Microsoft. Online, Internet. 21 April 1999.
Hall, Edward T., in
Hoft, Nancy L. (1995). International Technical Communication: How
to Export Information about High Technology. New York, N.Y.: John
Wiley & Sons.
(1997). Challenges in Designing International User Information.
Online, Internet. Posted 28 October 1998. www.xerox-emea.com/globaldesign/paper1.htm.
Norman, Donald A.
(1998). The Invisible Computer. Cambridge, MA: The MIT Press.
Inc. (2000). I18N Verification Checklist. Online, Internet.
(World Wide Web Consortium). (1998). 18n/l10n: LISA –
Internationalization/Localization. Online, Internet. 3 July 1998.
the top of the page
Copyright, Reuse and
The content of this article may be referenced with the
appropriate citation information included (see below). The entirety of the article must
not be reproduced without written communication with ISPI (www.ispi.org).
Also, we would appreciate your notifying us if you intend to use these concepts or
images, as we are curious to know where they prove valuable.
To cite the material, please include the following
information. We recommend the format:
Battle, Lisa and Degler, Duane (2001). Around
the Interface in 80 Clicks. Performance
Improvement (EPSS Special Edition). ISPI, 40(7), August 2001. As viewed online,