Arabic & RTL UX Design: A Practical Review Guide

1. Start with the task, before mirroring the screen

Write down what the user is trying to finish: linking a bank, comparing clothing sizes, or managing a workshop. Identify the terms they already know and the information they need before committing. A correctly mirrored page can still ask an unfamiliar question too early. Review the sequence of decisions alongside the visual layout, especially when a journey crosses into an English-language third-party service.

2. Treat language and direction as separate decisions

Language identifies the content; direction controls its reading flow. Set both explicitly for Arabic documents and override direction only where the content needs it. For spacing and alignment, prefer logical start/end properties over physical left/right rules. That gives the same component a clearer path between Arabic and English without maintaining two unrelated implementations.

<html lang="ar" dir="rtl">

.card {
  padding-inline: 1.5rem;
  border-inline-start: 2px solid currentColor;
  text-align: start;
}

3. Test complete sentences containing both scripts

Names, order references and punctuation often share a line with Arabic text. Test the entire sentence rather than the identifier in isolation. Wrap known left-to-right identifiers with an explicit direction; isolate unknown user-supplied text with bdi or an appropriate auto direction. Never reverse the stored string to make one screenshot look correct: copying, searching and assistive technology still need the original content.

<p dir="rtl">
  رقم الطلب: <bdi dir="ltr">SB-2048</bdi>
</p>

4. Design forms around the information being entered

A person's name, an email address and a monetary amount have different input needs. Keep a visible label, choose the right input type and keyboard, and explain formatting before an error occurs. Test autofill, paste, invalid values and server failures. An error should explain how to recover while preserving the user's work. A placeholder alone is not a replacement for a label.

5. Review numbers as decisions, not decoration

Agree how the product displays currency, dates, units and decimal precision for the actual market. A clothing size is not the same thing as a body measurement; a percentage lift is not a percentage-point change. Put the unit close to the value, retain meaningful precision and test a realistic long value. For localization, use formatting APIs with an explicit locale and options rather than assembling every number as a string.

6. Specify what changes direction and what keeps its meaning

Document navigation order, back/next controls, gestures and icon behavior rather than applying a global visual flip. Brand marks, media controls and data visualizations need decisions based on meaning. Keep the visual sequence consistent with the document and focus order. Then complete the whole task with a keyboard and on a narrow screen; reviewing a static frame will not reveal every transition or focus problem.

7. Test real Arabic content and actual states

Use realistic names, multi-line labels, empty results, loading states and failures in the prototype. Avoid writing tiny labels just to preserve a convenient layout. Check legibility with the actual Arabic font and weight, including zoom and text expansion. Important controls should be comfortably usable; if you evaluate WCAG conformance, check the exact criterion and its exceptions rather than treating a single button size as proof of accessibility.

8. Hand off rules and verify the shipped journey

A bilingual handoff should explain direction changes, content limits, component states and the expected behavior of mixed text. Review the implemented product with the same examples used in design, then observe where real users hesitate. Record what was observed separately from what you infer. A checklist helps make review repeatable; it does not replace usability testing or prove that a release improved conversion.

Examples from my work

These published projects show the context behind design decisions. They are not controlled experiments establishing the effect of each checklist item.

• Repair-shop management: an Arabic-first B2B workflow
• Maqasi: measurement and content decisions for clothing size selection
• Tarabut: clarity and trust in a bilingual banking journey

Pre-launch review checklist

Tick the items you reviewed in this session. Selections are not sent to the server or saved after a page reload.

• The primary task and completion state are clear in both languages.
• Document language and base direction are explicitly defined.
• Spacing and alignment work in both reading directions.
• Mixed Arabic, Latin text and punctuation have been tested together.
• Names, identifiers and email addresses copy without corruption.
• Fields have visible labels, appropriate keyboards and clear examples.
• Errors preserve input and explain the next action.
• Currency, dates, units and precision match the market and task.
• Navigation, gestures and icon direction are documented by meaning.
• Long Arabic content, zoom and narrow screens remain usable.
• Keyboard focus follows a meaningful and visible sequence.
• The implemented journey was reviewed, not only the design file.

Implementation references

• W3C: Structural markup and right-to-left text
• W3C: Inline markup and bidirectional text
• W3C: WCAG 2.2 target size (minimum)

Need a review of an Arabic journey or a bilingual product design partner? Product design & UI/UX · UX audit