Designing for Non-Native Speakers

For the past few years, I’ve worked on sites and web apps that have large user groups of non-native speakers of English. That has given me a chance to look at how they are accepted (or rejected) by people who don’t speak English as a first language.

Some curious facts emerge when you compare the languages most sites use, versus the languages most internet users speak. While around half of all web pages are in English, only about 28 percent of the people using the internet speak English as a first language. Interesting, right? There are billions of people who use and browse the English web, but are not native speakers.

Asking for fully translated and localized sites is a mammoth task, one only large international conglomerates can afford. Instead, we can take some other simple steps to make our sites accessible for non-native speakers. We can focus on clear language, interfaces, and prompts, to help users as they navigate a largely English-speaking web.

Readability

A few years back, my coworkers and I were planning the design and launch of a marketing site for one of our new English language courses for adults. We started to gather copy and content. The majority of it described the features of the course and the resources available to teachers. We needed to keep in mind that many of the teachers for this course were not native speakers of English.

In order to get an objective idea of how complex our copy was, we ran it through the Flesch-Kincaid Readability Test. The test measures how difficult a passage in English is to understand, and assigns a score or US-reading level. You can do this with the “Show readability statistics” tool in Word, or by copy and pasting your content into an online tool. Our marketing copy was topping out around the 13th grade level, meaning you needed at least a year of college to understand what we were saying about our product! We should have been sticking to a level of 6th-8th grade to make sure our content was clear and accessible to our customers. No one wants to stumble through dense text just to get info on a new product!

In order to remedy this we needed to take a few basic steps, focusing on our copy, and our UI. First, we ran Flesch-Kincaid scores for all the content. We compared the passages that had lower scores with those that came in very high. Based on that, and what our marketing team needed, we decided to go for a reading level of around 9th-10th grade—clear, but not dumbed down for English teachers. We then created a content map, basically a spreadsheet with all the copy, its location in the site, the reading level, and a few other bits of information. For every place the readability was poor, we edited it down and ran it through the test again, until we were satisfied.

Standardized interface language

Another area where sites and web apps can trip up non-native speakers is in the interface language. Users with varying levels of comprehension employ all kinds of strategies to understand what they are reading. While there are many standard commands like “save” and “help,” other processes, like “upload image from computer” when written poorly, can be confusing for non-native speakers. We should aim to provide them with simple, standardized commands that they can easily read and remember, wherever they are on the site.

So how can we do this? I have found that creating a spreadsheet or list of all your interface language and sharing that with your design team is a great way to maintain a sitewide standard.

This strategy is not only relevant for non-native speakers. All users, regardless of their comprehension levels, need consistent messaging and instructions on your sites and web apps. By focusing first on those with the most pressing needs, you make your site usable for a much wider variety of users.

Support tools

Sometimes though, simplified language is not enough. When we pair icons and text, we increase the speed at which recognition happens. It is an attempt to build a common language, one that is less dependent on English comprehension. But this is easier said than done. Look at these icons in Chinese mobile apps, and try to figure out how many you recognize.

Perhaps we need to offer an additional layer of context in these situations. Let’s start with onboarding. As non-native speakers download and enter your app or site for the first time, it is a great idea to provide small popups or a series of screens with animations to show the functionality. This handholding at the beginning of the experience can provide a sense of clarity and comfort even without a full understanding of the language you are using.

Tooltips next to key actions can also be helpful. At first glance you may think, “If it were designed correctly, you wouldn’t need tooltips!” which is true for native English speakers. But if, like me, your customers are not always native English speakers, then small, unobtrusive explanations next to key actions can provide that continued layer of help that your users need. Some web apps like LayerVault even use progressive reduction, where increased use means less explicit help is displayed, but if a user returns after a long period away, this contextual support is added back into the UI.

Non-native speakers of English often need a little extra help to get through English web interfaces. That is OK. If they are a significant part of your customer base, these are some simple ways to support them, making a more powerful online experience possible. Aligning your readability level with your users’ reading comprehension level, standardizing your interface, and expanding the range of help options available to users are all things you can do now—you don’t need to wait until the future when you have the time and money for a complete overhaul of your content. By planning and delivering these discrete steps, you can do a lot right now to help all your users, whether they are native speakers or not.

from A List Apart: The Full Feed http://ift.tt/1IJ1574
via IFTTT