Designing and prototyping an iOS app for Arabic users
At Zomato, we wanted to explore how much effort will go into the product to add support for Arabic.
(Note — Screenshots/prototypes from the Zomato in Arabic product are not added here since things are not released yet.)
Zomato caters to millions of users every week. Our second biggest market is in UAE in the Middle East. Most people who are primary-English speakers are already using Zomato. In order to capture more of the market, we wanted to start targeting Arabic speakers.
What moving to Arabic entails
Unlike other languages, Arabic is a right-to-left language. This means that our entire UI layout will change with the move. Before starting the project, we wanted to explore how much effort is needed to add Arabic support.
When it comes to the UI, everything that moves in a horizontal direction gets flipped. Everything. This includes text, icons, switches, sliders, and the entire page layout. And when you start trying to design a mirrored version of an element, it can get confusing pretty fast!
We had to gauge the localization effort for the app as well. It involves getting all the strings in the app translated to Arabic.
This can be split into two tasks:  translate all of the copy in the app (common phrases, labels, and titles we use), and  translate all of the proper nouns you see in the app (restaurant names and addresses).
Task 1 is manageable. But Task 2 will require a massive effort from the UAE content team and it is an ongoing task to translate every piece of restaurant data into Arabic.
We would need to change the date, time, and number system to the Arabic format. This needs to happen on the consumer-facing side and the merchant-facing side.
In order for the app to be relevant and useful for the local Arabic market, we need to include cultural context in the app. This includes their national holidays and festivals, removing the mention of alcohol, shifting the weekend to Friday-Saturday, and adding a “halal” tag to restaurants.
What we did
Got into the shoes of our users
In order to get into the shoes of an Arabic app user, we started by downloading and trying out several popular Arabic apps. We played around with the UI to understand how flipped icons, switches, sliders, and layouts actually feel.
Personally, I changed my phone’s language for a week to Arabic to get a feel for the UI in my daily life. It also got really confusing after a while!
I also spoke to some Zomato colleagues in Dubai who knew how to read and write Arabic. They provided context of common UI patterns used in Arabic apps (i.e. buttons and layouts). They mentioned the pitfalls of literal translations from English to Arabic and advised us to hire proper translators for internationalization.
Planned the design of the prototype
Designing for an RTL language required thinking from scratch. I had to plan which components would flip, how usability would change, and how it would affect the code.
I started by making a copy of the Zomato app and changing the language to Arabic. It was quite a mess at the start!
Slowly, I worked through all of the app screens and fixed the UI components that didn’t adjust to the RTL language layout. UI Components that were positioned by hard-coded math (for example: 5px padding from the right) didn’t switch over. Any components that were based on relative spacing changed automatically.
After this project, it inspired us to rewrite our new UI for the app from scratch and move the whole thing to Auto Layout. There were some fundamental changes to UI Kit elements with this change. For example, developers had to think in terms of leading and trailing that earlier was Left and Right. We started using layout constraints in code and things like NSNaturalAlignment to future-proof for RTL languages.
One component that I had to rethink during this experiment was the horizontal UI tab bar. Since the tab bar’s behavior had flipped, the tabs at the end were showing content for the tabs at the beginning. For the tab bar to be usable, the items on the tab bar also had to be flipped and shown in reverse order.
Finally, I mirrored all of the app assets and transformed the math of all the custom animations. This required some of the math to be redone. On top of that, it was generally very easy to get confused if I didn’t picture the animation properly in my head.
When it came to strings in the app, for prototyping purposes I extracted all the strings and translated them through Google Translate. If this app was really to get built, we will get proper translations done. And think about it, this would be just the start. On the backend, everything would need custom translations — including the very text-heavy online ordering menus.
These days many UI frameworks have built-in support for RTL languages. The best is to push your programming team to include practices for supporting these layouts in your product since day 1. Also, if you’re an engineer/designer working on a right-to-left language, be prepared to feel flipped. Everything goes in the opposite direction, and your mental models get trained to work in the opposite way. It definitely took me a few days to get into the hang of RTL usability, and it took me a few days to get out of it too. Good luck, be patient, and hang in there!