Imagine that you’ve just arrived in Tokyo. Full of impatience and excitement, you are just about to hit the road, yet there it comes: an urgent warning from your mobile provider, nudging you to top up your dwindling balance. With some justified concern, you go to the website, just to be redirected to the Japanese version of the site. You can’t read Japanese just yet, yet there is no obvious option to change the location, and there is no option to change the language either.
As the data keeps dwindling, you juggle between auto-translation and your limited VPN options — just to run out of data in the middle of the session. The language selector is somewhere there, yet it’s disguised between cryptic symbols and mysterious icons, nowhere to be found on the spot.
Chances are high that at some point you had a similar experience as well. As designers, we can of course make language selectors more obvious and noticeable, yet most of the time, the appearance of a component is only a part of the problem.
Too often, when we design interfaces, we subconsciously embed our personal assumptions, biases and expectations into our work. Of course, we can’t possibly consider all exceptions and all edge cases, along with all happy or unhappy coincidences. So we focus on the most common situations, eventually breaking a beautifully orchestrated user experience entirely for some of our disgruntled users.
Can we fix it? Absolutely! We just need to decouple presets, allow for overrides and allow users to specify their intent. But before we dive in, let’s explore what options we have in front of us.
The Fine Little Details Of A Language Selector
Usually, we know when we need a language selector. Every multi-lingual website will need one, and this definitely holds true for public services and companies residing in countries with multiple national languages. It is also necessary for global brands, organizations and the hospitality industry — as well as eCommerce where goods might be paid in various currencies and shipped to various destinations around the world.
Where do we place a language selector? Well, users have their usual suspects of course. In my experience, when asked to change a country or language, a vast majority of users will immediately head to the header of the page first, and if they can’t find it there, they’ll jump all the way to the bottom of the page and scout the footer next.
As for indicators of country selection, flags actually do work fairly well, and if users can’t spot them, they seek other icons that might represent a language in one way or the other — such as the globe icon or a “translation” icon. Obviously, when it comes to translations of articles or specific pages, users rely on the laws of locality and search for a selection of language next to the title of the article. So far so good.
Design-wise, however, there are plenty of intricate details that we need to account for. Surely the selector on its own will live somewhere in the footer of the page, and it is also very likely to make its appearance in the header as well. However, we could also auto-redirect users based on their location and auto-detect language based on the browser’s preferences, or prompt a modal window and ask users to select a region first. We could be using text labels or abbreviations, icons or flags, native or custom dropdowns, preferences panes or sidebars, toggles, or standalone pages.
As we will see, many of these solutions have usability issues on their own; and if we want to maximize clarity and reduce ambiguity, we need to come up with a proper strategy of how to label and group languages, how to present them, and how to make the language selector obvious to users — without running into a wild mixture of accessibility and auto-translation problems down the line.
Let’s start with something that is probably obvious, but worth stating nevertheless — auto-redirects might be helpful, but they often cause more frustration and annoyance than a help.
More after jump! Continue reading below ↓
Many websites rely on redirects based on user’s location (IP) or browser’s language. However, if a person is located in Tokyo, it doesn’t necessarily imply that they fluently read Japanese. And if their preferred locale is Dutch, it doesn’t mean that they want to deliver physical items to the Netherlands. In the same way, if the preferred locale is French, yet it isn’t available on the site, a user might encounter a fallback language that isn’t necessarily the language that they are most comfortable with.
We can’t confidently infer users’ preferences without asking them first. That doesn’t mean that we should avoid redirects at all costs though. If a user happens to be connecting to a US website from Germany, it‘s perfectly reasonable to nudge them towards a German website. But if they happen to be connecting to a German website with an English locale preferred, it would be confusing to redirect them to the UK or US version of the site — even though it might very well be the user’s intent in some rare cases.
In general, redirects based on location are probably more instructive than redirects based on the browser’s language, but they are error-prone, too.
On the very first visit, Dyson.com nudges visitors to select the preferred region and language in the header on the page. Users can dismiss the bar and locate the language selector in the footer of the page again.
Backcountry, a US company for outdoor gear and clothing, automatically redirects its users to another site. Since 2018, the website is no longer available outside the U.S. as an answer to the GDPR regulations. Without a VPN, it’s impossible to reach the website, for example, to purchase and deliver a gift for a friend located in the U.S.
Audi automatically redirects users to a country deemed as a best fit. However, users can choose their country by clicking on the language selector in the right upper corner. On click, a modal shows up with autocomplete and a disabled “Continue” button.
A global BMW website doesn’t automatically redirect users to any website. Instead, you can locate the “BMW in your country” option in the right upper corner of the header. It opens a modal with all the options listed, along with the prominent button at the top “BMW in your country”, which, on click, redirects users to the website considered to be the best fit for them.
IKEA, without an automatic redirect, but with a very large country selector that understands domains, endonyms and languages of the largest countries in the world. The “Go shopping” button might be the biggest button in the world and might deserve a spot in the World Guinness Records Book. Unfortunately, on the site, you can change the country, but not always the language.
While polite nudging is reasonable, automatic redirects are not. Once we start moving users from one site to another without asking them at all, we start baking our assumptions into the design, and that’s usually a red flag. We shouldn’t be surprised by increased levels of frustration and abandonment as a result. Ironically, this data is rarely tracked or known as the abandonment is happening on the “other” website, with different departments and teams on the other side of the globe.
Either way, whether we want to nudge users towards a different website, or we absolutely need to use an auto-redirect, it’s definitely a good idea to always allow users to override redirects with manual preferences. This requires us to tame our assumptions and decouple our presets.
Decouple Location and Language Presets
Many websites rely on an assumption that location, language and currency are usually tightly coupled. After all, if a user chooses a location in Germany, they are very likely to prefer the German language and see prices in Euro. However, this is based on assumptions that work for many people, but break the experience entirely for others.
For example, if you want to purchase sneakers on Adidas from Germany but deliver them to your friend in Poland, you need to be able to make sense of the Polish language when checking out. You can either choose the German language with delivery to Germany or the Polish language with delivery to Poland. It’s impossible to select the English language with delivery options to Poland, for example. In other words, both language and location are tightly coupled.
As it turns out, there are plenty of scenarios where this assumption doesn’t work:
A person is using a German VPN, but not be located in Germany nor understands German;
A person is connecting from Germany, but be visiting for a few days, and they might not speak nor read German at all;
A person is living in Germany, access a website in German, but prefers to pay with a company’s credit card in USD, rather than in EUR;
A person is living in Germany might want to deliver an item from an American store to an American friend, but keeps getting redirected to a German website;
A person is connecting from the USA but needs to be able to provide a VAT number because the product will be purchased by a German office with a German credit card.
Of course, we might consider all these situations to be very rare edge cases and dismiss them. But first, we need to track how many people actually experience such issues and end up leaving as a result. In practice, especially for global brands, these numbers might be more significant than one might think.
These problems appear because we frame common situations in tightly coupled and rather inflexible presets. Surely presets are useful as default options, but they break down when defaults aren’t good enough. That’s why it’s usually a good idea to decouple all presets, and allow users to make standalone choices.
On Mondraker, users select location and language separately. All countries are grouped into tabs, and at the bottom users can choose the language of their preference. A very similar design, but a quite different approach. A downside: labeling all countries in a selected language is probably not as effective as using corresponding native labels instead.
Monese shows two tabs in the right upper corner of the header. Users can switch between language and country, defining preferences for each separately.
User preferences don’t have to be limited by country and language alone. We can allow users to customize further parts of the UI, from currency and auto-translation to units of measurement and date formatting.
Allow Users To Set Custom Preferences
For many sites, language and location are just the first important attributes that convey what website might be a good fit for a customer. However, to deliver value to users, we might want to go a little bit beyond that.
Revolve.com uses language, country and currency presets based on the user’s IP and their browser’s locale. However, users can override these presets with custom preferences. They can choose a country for shipping, the language on the site and the currency. The hint for preferences is located in the header, with a combination of a language abbreviation, flag and a currency indicator.
These details are enough to show all products with the final price that includes delivery costs to their country and in the currency that’s most familiar to them. That’s what the perfect decoupling of location, language and currency is.
AirBnB suggests languages and regions in groups, but also allows users to adjust their preferences and choose a language and region of their choice. Additionally, users can opt-in to automatically translate descriptions and reviews to English. The modal is prompted by a tap on the globe icon in the right upper corner of the header.
Once the settings are set, users can jump from one location to another, compare prices in the same currency and see reviews automatically translate to a language that they might understand better. That’s undoubtedly a win for the users.
iHerb goes the extra mile by providing a whole range of additional preferences for their users. Not only can users choose their language, preferred currency and shipping destination (and specify it with ZIP code for US destinations) — they can also choose preferred units of measure and check available payment methods and available shipping methods. Bonus points for smart autocomplete input rather than a not-so-good old-fashioned <select>-dropdown.
Some slightly different preferences can be defined on the State Street of Global Advisors. On the first visit, a modal window appears explaining to users some of the assumptions that the interface is making about the location and their interests. Within the modal window, users can change a location, specify their role and choose a preferred type of site for their visit.
In general, these are some of the useful adjustments that we could allow users to specify to customize the entire experience for them:
Units of measure
Time zones preferences
Level of experience
The question, of course, is how to surface all these settings to the user — in a separate settings page, as a sidebar, in the header, or the footer? One disputable option is to show the settings in a modal or non-modal window upon entry to the site.
A Case For Non-Modal Dialogs
Admittedly, modal windows are rarely a good idea. They are disruptive and annoying as they require immediate attention. However, they are appropriate when we need to draw the user’s attention to important details — be it loss of data, mutually exclusive preferences or critical errors.
Some of the websites listed above prompt a modal window on the very first visit, asking users to specify their intent and their preferences before using the site. On others, default presets are silently applied, with an option to adjust them if needed — sometimes in a modal, and sometimes on a dedicated page.