Think Globally, Design & Develop Intelligently

At Myplanet, we create for a global audience.

Whether it’s a project for an enterprise client or a product being developed in-house, our work reaches all over the world. So when we say we design, develop, and build with the mission of improving experiences for everyone, we really do mean everyone.

But big, internationally distributed projects aren’t the only ones that require we keep an international audience in mind.

Anything produced on or for the web has a global audience, whether it’s intended to or not. Which means anything being built for the web needs to be, at minimum, aware of a complex and non-homogenous audience.

Consider the Possibilities

The list of considerations when trying to span cultural and linguistic divides could go on forever, but not all issues are conquerable within the scope of most projects.

For example, increasing amounts of research show that the language we speak changes they way we understand things, even when the words are exact translations between languages. Panos Athanasopoulos, a Professor of Linguistics and English Language at Lancaster University, states that “the language you speak in really can affect the way you think.”

Language impacts a user’s mental model, but as designers and developers the onus isn’t necessarily on us to factor in the difference between an object-first and an action-first way of thinking into our work.

Similarly, though we all probably recognize that the culture someone is raised in has significant bearing on what they care about, how they think, the way they make decisions and prioritize actions, and their online comprehension and understanding, there’s only so much scope we can reasonably expect to take on.

So while all of this is important and should be considered when we craft for the web, the truth is it mostly goes beyond what we, as the designers and developers building an experience, can adjust for.

In fact, for the average mom-and-pop shop website, the modifications to be aware of for that “complex and non-homogenous audience” don’t need to extend much beyond basic usability and accessibility standards: Is the language clear and easy to understand? Are the images and graphics similarly easy to understand?

When creating for an international audience, however, we need to do more.

Some of the adjustments to be made are obvious, like being able to switch languages, and some aren’t as obvious, like making date and time formats regionally specific. But even the obvious things require forethought.

To make a site or application work in different contexts, you need to have created a design flexible enough to allow for changes, and a back-end that is easily modified for the implementation of those changes.

Which brings us to internationalization and localization.

According to the World Wide Web Consortium W3C, “Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale)” and “Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.”

Internationalization is the precursor, then, to localization. And when you’re working on a large-scale, global-reach project, you’d better be thinking about both.

Think Internationalization, Enable Localization

As with so many things, the earlier we start thinking about these things the easier (and more cost efficient) their implementation will be.

Myplanet Developer Rene Hache notes that “it’s very easy to do internationalization code modifications at the start of the project. If you build it into the CSS from the get-go, it’s a relatively quick and straightforward business.”

To expand on that, let’s take the example of drop-down arrows:

If you’ve built a site with the option to have left-to-right (e.g. English) and right-to-left (e.g. Chinese) language support, it’s not just the characters that change. All readers naturally understand a drop-down arrow at the end of the entry field, which, for right-to-left readers, would be at the far left of the field.

Ensuring that drop-down arrows switch sides when you switch languages is something that can be written into the code from the beginning of the project, so that it happens more or less automatically when you enable certain language localization modifications. And that’s the kind of back-end support you need to think about early in the process.

“It’s way less costly if you plan for it from the beginning, rather than trying to implement it later,” says Rene.

In Any Language

Language modifications are obviously one of the biggest areas for designers and developers to think about when planning for internationalization and localization.

Amit Jakhu, one of our Designers at Myplanet and author of Crafting Type for the Web, notes a number of potential challenges and pitfalls when trying to design for an international audience.

Something as straightforward (or not, as most designers would tell you) as a font choice can become complicated when the font you selected in one language isn’t supported with another character set.

And optimizing your button text — something that drives usability and can make for a cleaner, more appealing design — can get complicated when a direct translation doesn’t make sense and a longer substitute must be used instead.

In fact, content of all types can vary widely based on factors ranging from word length, to idiomatic and colloquial alterations, to content focus areas for different markets. If content authors are trapped by specific margins and spacing constraints, it can be a huge impediment to the success of a site.

Different character sets can also change spacing and formatting, and even when the characters remain more or less the same (as in the examples of English and German), the difference in the expected length of words can also alter spacing and margins. English is a compact and short-worded language, which means entry fields often skew too short for longer, more compound-word driven languages, like German.

And to all these considerations, there are still more to add. Amit notes that certain icons and graphic images don’t mean the same thing across cultures, and obviously the use of images with text (something to be avoided if at all possible) would necessitate images with translated text as well.

Using bold or italics isn’t a universally understood method of adding emphasis, either, and date and time formats change depending on the region as well. Support for various currencies — including not just the inclusion of different currencies, but the way they present — and a slew of other small but essential alterations need to be made when localizing for a specific region or regions.

For Amit and the teams at Myplanet, what this means is thinking ahead and planning for lots of changes. “We try to keep the elements flexible as much as we can, so we can grow and change as needed,” he notes.

Rene agrees: “Be stringent with your coding standards — it’s quite easy to do — so that adjustments are easier and more straightforward in the long run.”

And Katie McCoy, Practice Lead, Product Management at Myplanet, agrees with them that planned flexibility is key. “We need to ask at the start of a project: What can be done to configure the back end (WYSIWYG adjustments, etc.) to make it easier on content authors? How can we accommodate the different design elements we’ll need to adjust, and the language support we’ll need to have, and other things such factors, for an international audience?”

And Still There’s More!

There are other factors that must be considered as well.

While users in established tech markets like North America have and use desktop machines with wired connections, that isn’t the case for many other parts of the world. Studies have shown that mobile is often the only means of access and connectivity in emerging markets — and that’s unlikely to change.

In those circumstances, connecting to and accessing a site may be difficult to do and is likely significantly slower. Knowing our users face this challenge at the outset necessitates a lighter build (something we should be striving for for our mobile users anyway) and changes the priorities of a designer or developer.

Browser choice changes globally, as well, with certain browsers not only preferred in different part of the world but some even being restricted entirely. Factoring different browsers into testing and using those that are most common to the regions you know you’ll be targeting is a necessity.

And then there are the other, more nuanced issues such as privacy and personal information collection or the level of formality in addressing a user. These too may shift depending on cultural norms and understandings.

The variants and potential pitfalls are somewhat endless.

In the end, we cannot account for every possible culturally-motivated confusion or each language-influenced difference. But by thinking through the potential for these issues and confronting the possibility that we may uncover even more we hadn’t thought of down the line, we give ourselves the opportunity to build smart, flexible options into our frameworks and to minimize confusion and strife for all our users.

Written by: Leigh Bryant

Liked this? Loathed it? Felt very middling about it? Let us know in the comments and/or share it with others!