Learnings from designing for multi-language user interfaces
Designing for multiple languages has had an impact on the way I approach design decisions, regardless of the product being in one or several languages. The points covered in this story are based on some of the issues I encountered when designing for an existing and functioning product that was translated to accommodate new languages (and regions).
The stage of the product can play a major role in design. Designing with an already existing product comes with its own set of unique challenges and constraints (constraints are not necessarily a bad thing) that really help to think about what is important.
Regardless of the stage of the product - design is about solving problems. Pseudo localization at Netflix is a great read on how Netflix approached designing their UI for multiple languages.
There are a lot of factors that can play a role in a design choice, and there is probably no right or wrong approach, but some can be better and some worse than others. The points covered in this story may seem very common, but they can easily go unnoticed or ignored until something goes wrong.
Learning from mistakes.
Broken UI — a starting point
Everything was going smoothly until a new language well-known for lengthy words was implemented to the English-only product. The language was German and it broke the UI. An eye-opener that made me start to approach design choices with a new mindset.
Due to a broken UI, we had to rethink how to approach the layout, elements, and copy in the design to keep it consistent for all languages. Changing font sizes just to accommodate a new language is not really a good approach. We had time and resource constraints that didn’t allow for bigger design changes either, and changes in the layout had to be minimal - a domino-effect: when you alter one it affects another. This incident set in motion a larger plan to re-evaluate the information architecture for future iterations as well.
The goal was to have a single product instead of several language-specific solutions. These fixes were about hierarchy, context, decluttering, language, and specifications.
Hierarchy — determining priorities
Utilizing a design system when creating UIs can help to maintain consistency and speed up workflow, but these systems are not always available. In such cases, establishing hierarchy and determining priorities of elements on a given screen can act as a guideline. Ideally, these choices should take into consideration how they all fit together in the bigger picture.
What is the purpose of this screen and what do you want the user to do? Why? This does not mean taking away certain elements or hiding them on purpose to reach your desired goal, but more about creating visual hierarchy between all elements inside a screen to guide the user towards their desired goal.
Thinking in terms of content, primary, secondary and tertiary actions can help to narrow down design choices. What we were lacking at the time were tertiary actions — we were too focused on trying to maintain a consistent look and feel — too focused on aesthetically maintaining a “balance” when the two actionable items actually didn't belong to the same hierarchy.
A simple example could be "cancel" and submit" on an application form. If "cancel" and "submit" are communicated in an almost similar way, it will likely confuse the user. If the goal is to submit a form - why promote cancelling the form? It will not help to guide the user to the desired action. If this form would have a "save for later" - that might be a game-changer. Would then "submit" be a primary action, "save for later" a secondary action and "cancel" a tertiary action? It all depends on goals and priorities.
The broken UI made us realize that the design wasn’t actually considering priorities or communicating hierarchy. It was time to rethink the design and position elements in the layout with a goal of establishing hierarchy. We changed the two main actions into a primary action and a tertiary action. The UI for the screen didn’t break with the new design and was a lot more flexible than before. A new tertiary style was appended to the design system as well. A design system is always evolving and such cases help building them into a comprehensive system.
Language is as equally important as a visual style.
Decluttering — importance of context
Icons can help to create a mood and feel to an UI, as well as help to guide the user to accomplish their desired task. Deciding to use only an icon, only text or a combination of both depends a lot on the user group, the action and the context of a screen and the product.
We had a button that included an icon and text to communicate the action. The reasoning for choosing a combination of both was that this icon was linked with action and it appeared on other parts of the product as well. We wanted to create associations. However, do users know to make such connections as easily when the action is not as straightforward as for example liking an item? Perhaps sometimes aiming for too much clarity can also result in a communication overload, and too minimal of an approach can leave the action untouched.
In our case, having an extra icon would cause the layout to break for the German version. Because of this discovery, we dug a bit deeper and found that adding the icon didn’t actually benefit the user that much (it was clear without an icon). Text was enough to communicate the action, which further justified decluttering. Icon alone would have not worked in our case.
In another case, we had an icon that we thought was clear as is, but when conducting user testing and interviews actually found that the icon was perceived in different ways by the users (wrong ways), so the result was to remove the icon and replace it with text. The results in metrics were very different, in a positive way. The new text-only option wasn’t as "cool" as the previous aesthetically slick icon but served a better purpose for the user and the business.
Context and clarity are important.
A lot of people are not familiar with the low tire pressure icon on cars (TPMS - Tire Pressure Management System). These icons are usually universal and used across brands and countries, they also have specific coloring. Even though a lot of users (drivers) are not 100% sure on the meaning of the icon, a mechanic should be able to know the problem when glancing the icon.
It could be possible to notify the driver inside the car system in addition to showing the icon above (via Voice UI for example and perhaps "low tire pressure" somewhere that doesn't disturb driving), but creating a custom icon for such an important safety measure could be dangerous and irresponsible just for the sake of being original or consistent to one’s style. It could create even more problems — imagine a stop sign that is green — would it be clear or confusing? (Although it seems they do exist). Again, context is important.
Language — differences in meaning
Getting a product translated can be exciting. There is a sense of growth and development, but also possible issues can come up. A lot of these obstacles can come down to how the translation is created. Time and resources can have an impact on the quality of translation. Usually, there are two possible routes, or a combination of both: Human or computer translation.
Computer and AI-powered translations have improved a lot and can provide a quick and affordable solution for getting a product translated. Although, the accuracy of an AI translation can vary for each language. No matter which route, the translation should be checked by another person (a native in the language).
Finding a translator does not come without possible issues either. A lot of the times I’ve seen translations being direct translations and this can cause problems. For example in Finnish, one word can have several meanings:
Kuusi palaa = Six pieces
Kuusi palaa = Six returns
Kuusi palaa = Spruce is on fire
Kuusi palaa = Spruce returns
Kuusi palaa = Your moon is returning
etc.
The translator would need to know the industry and context to provide an ideal translation. It would be good to involve the translator in the design process as much and as early as possible. One word might work fine in one language, but it might not resonate well in others. If you deliver the translation just as cells in an excel file and email it out, the above case might happen easily.
You can also look what words big players are using. They’ve usually had a lot of work in finding the most ideal option. This is not to say copying as is, but in terms of generic language in an UI. If you copy “zazaam thou in my bin” word by word - that is very personalized/branded and considered copying. “Add to cart” is still pretty generic.
“Add to Cart” according to a quick Google Translate in German is “in den Warenkorb legen”, it has been verified by contributors. I did a quick research on a few German-based retailers to see what they were using:
- Zara Germany: “Hinzufügen”
- Tommy Hilfiger Germany: “Artikel Hinzufügen”
- Amazon Germany: “In den Einkaufswagen”
- Ikea Germany: “In den Warenkorb”
Ikea’s language choice was the closest to the quick Google Translate query. Which one would you use? The industry you are in might have an impact on this.
Miscommunication in translation happened quite a few times in our case and was solved by having a more thorough discussion with the translator and the product owner on language usage.
Language also communicates a personality. Other languages have honorifics that may not appear in English. Furthermore, capitalization rules are different in German and English — what may seem as a mistake in English, can be actually correct in German. MAYBE ALL CAPS IS SAFER? CAPITALIZATION? SHOUTING?
In some cases it is also worth thinking whether using just an icon is universal enough to communicate the action (i.e next and previous arrow indicators). Not forgetting to mention that besides language, there are also differences in units of measurements between countries.
Language is a very important part of any UI.
Specifications — flexibility in layouts
Grids and layouts are a big topic. There is a lot of discussion on using grids and breaking the grid. Although, besides grids, I haven't seen that many threads on details such as line-height, fixed elements, maximum and minimum widths and agreed limitations, which can help a lot if added as part of the specification for hand-over.
There is always a danger of information overload, but these details do not have to be for every screen and every instance — usually, the screens should have a certain consistency where similar parts share same specifications or are part of the general specification. You can inspect UI designs in tools such as Zeplin, but not everything will be available in the Zeplin inspector mode.
What we encountered was that product item titles were not taking into consideration longer character strings. It was a sizing and spacing issue. We had to rethink the maximum widths of elements on the screen and decide on character limits, or what would happen if a text element was too long. There was no space to wrap to a second line, so the line had to be cut after a certain character number. Giving guidelines on an ideal character length beforehand can work wonders as well.
Alterations based on hierarchy, context, decluttering, language and specifications helped to solve a lot of the problems brought on by the broken UI, but it didn't mean it was finished - the work continues.
Have you encountered problems when designing for different languages?
