Aadhib

Case study · Active

Designing an Arabic-first visitor management experience

What it takes to build software Arabic-speaking staff actually want to use, rather than an English product with a language toggle.

Role
Founder · Product · Engineering
Published
Reading time
1 min
Arabic / RTLBilingual UX
01

Context

Most enterprise software sold into this region is an English product with Arabic added. It usually shows: mixed direction, English technical terms left untranslated because nobody knew the Arabic equivalent, and layouts that were mirrored mechanically rather than designed.

02

Problem

Front-desk and security staff frequently work primarily in Arabic. If the Arabic interface is visibly the second-class one, they either work in English at a disadvantage or work around the software. Either way the data suffers, which defeats the point of the system.

03

Constraints

01
Direction is structural
RTL is not a stylesheet flip. Reading order, field order, icon direction and navigation position all change, and getting one of them wrong makes the whole interface feel foreign.
02
Terminology has to be right
Security and reception vocabulary is specific. A dictionary-accurate translation that nobody in the industry uses is worse than useless.
03
Both languages are first-class
The same organisation may have Arabic-speaking guards and English-speaking administrators using the system simultaneously.
04

Approach

I designed bilingually from the beginning rather than translating at the end. I considered every screen in both directions as I designed it, which surfaces layout assumptions early — while they are still cheap to change — instead of at the point where a translation pass reveals them.

05

Architecture

Bilingual design passEvery layout considered in both directions during design, not after.
Terminology decisionsDomain vocabulary chosen for what practitioners actually say.
Directional layoutStructural RTL rather than a mirrored stylesheet.
06

Solution

Full RTL support with Arabic treated as a primary interface language across reception, security and administrative screens. Terminology chosen for the working vocabulary of the people using it rather than for literal accuracy. Language is a property of the user, not a setting buried in an admin page.

The test that matters

Not whether the Arabic is grammatically correct. Whether an Arabic-speaking receptionist, under pressure, reaches for the software rather than the notebook. That is a much harder standard, and it is the only one that predicts whether the data will be any good six months later.

What "designed bilingually" means in practice

It means I reviewed the layout of every screen twice, in both directions, before building it — not that I added a translation file at the end. The second direction is where you discover that your form flows left to right for reasons nobody wrote down.

07

Lessons

  1. 01Retrofitting Arabic is more expensive than designing for it. The cost is not translation, it is the layout assumptions that only reveal themselves under RTL.
  2. 02Terminology is a domain problem, not a language problem. The right word is the one the people doing the job already use.
  3. 03If the Arabic interface feels like a translation, staff will tell you by not using it — and they will not file a bug about it.

Stack

What it runs on

Arabic / RTLBilingual UX

The project

01Aahlan
ARTICLEWhy Arabic-first software is more than translating an English UIOPINIONSaudi Arabia is an interesting place to build enterprise AISYSTEM NOTEBuilding software for receptionists, guards, hosts and admins at the same time
All case studies