Writing for global audiences
By: Susanna Zaraysky
Tags: Next Billion Users, UX, Internationalization, Content Strategy, Writing

Draft clear content so users know how to take action

Illustration by Alexa Ong, Next Billion Users illustrator

I wrote this story with assistance from Luke Easterwood, LeAnn Quasthoff, Jessica Caimi, and Erik Ninomiya, UX writers who have focused on the needs of the Next Billion Users.

John Steinbeck said that “Poetry is the mathematics of writing and closely kin to music.” The Nobel Prize winner in Literature understood the challenge of writing well. Writers must always consider the effect their word choice and grammar have on the meaning and flow of the text, as well as how those choices might make their readers feel.

It can be especially challenging to write for a global audience made up of different cultures, languages, abilities, and expectations. Before you begin, it’s essential to question your own assumptions, deeply understand your users’ contexts, and recognize the potential impact of your writing choices.

The writing guidance you see here includes principles and recommendations for both new and experienced internet users that were formulated after doing user testing around the world. Before going over writing examples, let’s review some of the main challenges involved in creating content for diverse groups of users.

Writing challenges

Challenges users face include limited literacy, limited technology experience, or both. Language and technical terms should be simple to accommodate a wide range of user fluency.

Tech fluency

Tech fluency means understanding the capabilities of devices and apps. Where mobile use is less common, gestures, such as swiping and dragging, can be unfamiliar. Visual cues and videos are needed as instructional tools. Showing how to swipe might be communicated with a simple animation of the horizontal scroll or swipe as the user lands on the screen. (To learn more, consider following the Material Design guidelines for gestures.)

Language

Users interact with language in a variety of ways. For example, many users in India find inputting text in Indic scripts, like Hindi, difficult due to the complexity of the script. Users might be more comfortable typing in English, in Hinglish (a mix of Hindi and English, written in the Latin alphabet), or in Hindi written in Latin letters. In Kenya, many use a Swahili interface, but search in English.

Translating many technology terms can be counterproductive to enhancing comprehension and can, in fact, make terminology more confusing. Many users first learned technological terms, such as Bluetooth, software, and hardware, in English and might be unfamiliar with the translations in their native language. To determine which technical vocabulary to keep in English, it is best to consult with a localization and translation expert.

Writing strategies for global users

As you’re designing experiences for global users, approach language with care and consideration, and keep the following best practices in mind:

Reduce ambiguity for users with clear and simple language

Provide translation guidance to translators and linguists

Create relevant content that matters in users’ daily lives

Examples

Here are some examples of these best practices in action.

Keep language simple

As explained in the Material Design writing guidelines, it’s important to keep words simple. This principle is especially important for emerging markets since non-native English speakers might be using apps in English and could find complex sentence structures hard to understand. New internet users might not understand technological concepts, so explaining steps, like opt-ins and permissions, requires even more care.

When possible, avoid long introductory clauses.

Do (green): The welcome message has a short introductory phrase. Don’t (red): The welcome message has a long introductory clause that may be hard to follow.

Use basic sentence structure. Try to target a single thought per sentence.

Do (green): The UI text has 2 sentences with a different thought per sentence. Don’t (red) example: The UI text has one long sentence with 2 different thoughts.

In general, choose clarity over brevity. Longer messages can add needed context and increase trust, while short sentence fragments can lead to confusion. Add clarifying details if you have the space.

Do (green): The longer message clearly states how much storage is available on the device. Don’t (red): The shorter message doesn’t explicitly state how much storage is available on the device or SD card, possibly causing some users to feel uncertain.

To learn more about the importance of clarity when writing about data storage and cost, read Nurture Trust Through Cost Transparency.

Consider using more words to avoid a potentially complex or unfamiliar term.

Do (green): The question about knowing more than one language is clear and understandable. Don’t (red): The term multilingual might be too hard to understand.

Refer to word lists available online. Different word lists focus on different goals. For example, Ogden’s basic English lists 850 of the simplest and most useful words. It’s composed of simple interactions, such as put, give, and go, and picturable words, such as arm and ticket. Consider using this word list — or one like it — to keep your UI language easy for everyone to understand.

You can also consider creating your own product, category, or location-based word lists as needed.

Lost in translation

As your app might be localized to other languages and regions, it’s key that your UI language can be easily translated into other languages.

Writers sometimes find it tempting to use idioms or slang to create a conversational and approachable tone. But it’s important to understand that colloquial expressions can prove difficult or impossible to translate, reducing global comprehension.

Where there is imagery, think about how the words and images go together. Idiomatic language that plays off an illustration might make it challenging for visually impaired users who rely on screen readers to understand the context and meaning. The language should be comprehensible on its own.

For example, a ride-sharing app might use the colloquial term “Your chariot awaits” when a car is approaching the customer’s location. The phrase might be cute for a native North American English speaker, but not make sense to approximately 20% of people in the US who speak another language at home and to those outside of the US whose device language is set to North American English. If a Bosnian-speaking user translates “Your chariot awaits” with an automatic computer translation service, it is literally translated to “Vaša kočija čeka,” not to the Bosnian equivalent of “Your ride is waiting.” The rider might wonder where their 2-horse chariot is! If the same app showed a notification saying “Hold your horses” to inform a waiting passenger that their ride is late, the non-native North American English speaker might also not understand that “Hold your horses” means to “wait.”

Do (green): “Your ride is here” is easy to understand and translate. Don’t (red): “Your chariot awaits” is too colloquial and may get translated literally.

Do (green): “New features are available” is clear and easy to understand. Don’t (red): “New awesomeness ahead” is too colloquial.

Do (green): “One moment” is clearly understood. Don’t (red): “Hang on” is too colloquial.

If you’re using slang or colloquial phrases, provide a description of what this phrase means to your localization partner or translator so they can properly translate the phrase to other languages.

Use global examples and highlight local references

When you reference examples in UI text, try to use global examples (information that’s understood by people around the world) when possible. Certain references, like local places and holidays, won’t always work for global audiences. If it doesn’t make sense to use a global example, be sure to explain the reference to your translator or localization team so that the translator can substitute a locale-specific example. Some instances where local references should be called out include:

Providers (internet and cable)

Locations (cities)

Names (common first names and nicknames)

Currencies