UI/UX Design for Arabic and RTL Products in the Gulf

Why RTL is not a CSS flag

Most teams discover the problem the same way. Someone sets dir="rtl" on the root element, the layout mirrors, and for about thirty seconds it looks like the job is done. Then the details surface: the play button points the wrong way, the logo has been flipped, Arabic text falls back to a Latin font that renders letterforms incorrectly, line height that looked generous in English now clips descenders, a phone number inside Arabic prose appears jumbled, and a translated button label has grown by a third and broken its container.

None of these are CSS bugs in the ordinary sense. They are the consequence of design decisions that assumed a left-to-right, Latin-script world and never made that assumption explicit. The direction property changes the layout axis; it cannot make editorial judgements for you.

The platform handles this well if you let it. CSS logical properties — margin-inline-start rather than margin-left, text-align: start rather than left — express intent instead of geography. A component built on logical properties mirrors correctly without a second stylesheet; one built on margin-left needs parallel overrides that drift out of sync within two sprints. The cost difference is near zero on day one and substantial by month six, which makes this a design system decision rather than a bug ticket.

Mirroring: what flips and what never does

The most common RTL mistake is mirroring indiscriminately. Our rule of thumb: mirror what derives meaning from reading direction; leave alone what derives meaning from the physical world or an established convention.

A back arrow means "go to the previous thing", and "previous" in Arabic is to the right, so it mirrors. A play button does not mean "go forward in reading order" — it is a picture of a tape head moving along a tape, and that tape runs the same way everywhere. Flipping it makes it read as rewind. Likewise a clock runs clockwise everywhere, and a logo is trademarked artwork rather than a directional signal.

The chart row is genuinely contested: some teams mirror time-series axes for RTL locales and some do not. Settle it with your own users rather than by rule, particularly in business intelligence and analytics dashboards where a misread trend line has consequences. Whatever you choose, be consistent.

Arabic typography and line height

Arabic is a connected script. Letters change shape according to their position in a word, they sit on a baseline with pronounced ascenders and descenders, and diacritics extend above and below. Three consequences that Latin-script instincts get wrong:

Line height. Vertical rhythm tuned for a Latin typeface usually feels cramped in Arabic, and descenders can collide with the line below. In our experience Arabic generally needs noticeably more leading than the equivalent English at the same optical size — a value worth setting per language rather than inheriting one global figure.

Optical size. Arabic and Latin faces at the same nominal point size rarely look the same weight or scale, because x-height conventions differ. A heading that reads as confident in English can read as timid in Arabic at identical values. Define the type scale per script rather than sharing it.

Font selection, the most consequential. Not every typeface with an Arabic character set is a well-designed Arabic typeface; some are Latin fonts with a bolted-on Arabic range that joins letterforms incorrectly. Choosing a face designed for Arabic by someone who reads Arabic is the difference between a product that feels native and one that feels translated — and the Arabic and Latin faces you pair must sit comfortably together, since bilingual products show both on the same screen constantly.

Eastern and Western Arabic numerals

Two numeral systems are in use across the Arabic-speaking world. Western Arabic numerals are the digits used across Europe and much of the Gulf's commercial life; Eastern Arabic numerals are the alternative forms found in more formal and traditional contexts. Both are correct Arabic. The question is which your users expect.

The wrong way to answer is by accident — inheriting the choice from a framework default or a locale library nobody configured. Decide deliberately per market and context, then apply it consistently. Some products use Western digits throughout because their users work with prices and part numbers; some use Eastern digits in editorial content and Western digits in tables. Both are defensible. Mixing them arbitrarily within a screen is not.

Two technical points hold regardless. Numbers always run left to right, even inside right-to-left prose — the digits of "2026" are in the same order in Arabic as in English. And bidirectional text algorithms handle mixed content most of the time, but the exceptions are ugly: phone numbers, IP addresses and anything with punctuation between digits can render in a confusing order without explicit isolation. Expect to write deliberate markup here rather than trusting the browser.

Regulated documents add a constraint. If your product generates output matching a published format — the structured invoice required by a regime such as ZATCA e-invoicing in Saudi Arabia — the numeral system and field presentation are dictated by the specification, not your design preference. The interface and the artefact it produces can legitimately differ.

Bilingual content models

Most Gulf products are bilingual rather than Arabic-only, and this is where architecture and design meet. Decide early what "bilingual" means in your data model, because it is expensive to change later.

The naive approach stores one field per piece of content and translates at display time. It breaks the moment content is user-generated or needs different structure per language. The durable approach gives every translatable string and record a language dimension from the outset, with an explicit answer to what happens when a translation is missing: fall back, hide the item, or show it flagged. Each is right in different products; having no answer means the choice gets made inconsistently by whichever developer touches it next.

Text expansion is the design-side consequence. Translated strings change length in both directions, and the same English label can be shorter in Arabic in one place and longer in another. Designs built around fixed-width buttons and single-line labels will break. Reviewing designs in Arabic — not lorem ipsum, not machine translation, but the real strings — is the cheapest quality intervention available on a bilingual project.

These decisions reach far. A CRM or ERP platform where records are entered in one language and reported in another needs the language dimension in the schema, not in a view — as does an e-commerce catalogue where merchandising, search and product data must work in both.

Form and data entry design

Forms concentrate every RTL problem in one place, which makes them a good stress test for the design.

• Field alignment follows the language of the input, not the page. An email address or URL typed into an otherwise Arabic form is left-to-right content and should be treated as such, or cursor behaviour and punctuation placement will confuse users.
• Name fields are a design decision, not a default. The Latin first-name/last-name split fits Arabic naming conventions poorly. A single full-name field is often the more honest structure.
• Addresses vary by market. UAE and Saudi address structures differ from each other and from a generic Western template. Model the fields you actually need per country.
• Phone numbers need explicit direction handling. A country code, separator and subscriber number inside Arabic text is exactly the mixed-direction case the bidi algorithm handles worst.
• Validation messages must read naturally. Machine-translated error text is where bilingual products most often reveal Arabic was an afterthought — errors appear at the moment a user is already frustrated.
• Dates and calendars need a stated position. Hijri and Gregorian both appear across the Gulf; decide which your product shows, whether it shows both, and what it stores.

Testing with Arabic speakers

You cannot review an Arabic interface you cannot read. That sounds obvious and is routinely ignored, because it is uncomfortable to admit the team shipping the product has nobody on it who can judge whether it reads well.

Translation quality and interface quality are different things. An agency returns accurate strings. It will not tell you the register is too formal for a consumer app, that a label is technically correct but not the word anyone in Riyadh would use, or that the layout makes a form harder to scan than its English counterpart. Those findings come from native speakers in your target market performing real tasks in the actual build — and usage and register vary across the region, so test in the market you are selling into. If Arabic is a first-class language, it deserves a first-class place in the test plan rather than a localisation check at the end.

What good RTL design earns you

The business case is not sentimental. It is about the cost of the alternative.

• Credibility with Arabic-speaking users. An interface that reads as translated signals that the Arabic-speaking customer is a secondary audience — and that affects trust at exactly the moments, payment and personal data, where trust matters most.
• A larger addressable market without a second product. Bilingual by design means one codebase, one release train and one design system serving both audiences, rather than a fork that diverges.
• Lower long-term cost. Logical properties, a language-aware content model and per-script type scales cost little up front. Retrofitting them into a mature product is a substantial rebuild.
• Fewer late-stage surprises. The RTL bugs that derail launches are deferred decisions, not defects that were introduced.
• Compliance-adjacent readiness. Products that already treat language, numerals and document output as explicit concerns are better placed when a regulated format enters the picture.

How Inovsion helps

We build software for the UAE, Saudi Arabia and India, so bilingual Arabic and English products are ordinary work for us rather than a special case. That shapes how we approach a design engagement.

We design in both languages from the first screen. Arabic is not a localisation pass applied after sign-off; layouts are reviewed with real Arabic strings before build, which is when text expansion, type scale and mirroring questions are cheap to resolve. Where we build the front end, we work in logical properties and a locale-aware component library by default, so mirroring is a property of the system rather than overrides someone has to maintain.

We are also honest about the starting point. If you have an existing English-only product, we audit it first — the hard-coded directional values, the embedded strings, the fixed-width containers, the assumptions in the data model — and tell you what the work actually is. Sometimes that is a contained refactor; sometimes the presentation layer needs rebuilding, and it is better to hear that before the budget is committed.

Real examples from our portfolio include Rising Walls, a property portal for buying, selling and renting homes and commercial space; FameKeeda, an app connecting fans with celebrities; HiCare, an e-commerce portal; and OneTuch, a logistics, carpooling and medical emergency platform. We have also built an ERP-integrated ZATCA e-invoice solution covering EGS onboarding and integration — the kind of engagement where interface language and regulated document output must be reasoned about separately.

The same team covers build as well as design — Flutter, Android and iOS for mobile, and custom application development for web — so RTL decisions made in design survive into the shipped product rather than being reinterpreted at handover. See more on our portfolio or read our other guides.