A collection of representative B2B lead discovery scenarios, showing how AI identifies qualified sales opportunities from real-world business conversations.
RTL Is Not a Mirror Flip: What Happens When Your SaaS UI Meets Arabic
A SaaS product UI must support right-to-left languages and local date/number formats while the existing design system was not built for it. This scenario shows what a product design lead can evaluate before committing to refactoring.
This is an illustrative scenario designed to explain the product’s judgement logic. It is not a real customer case, testimonial, contract, revenue result, or conversion claim.
01Situation
02Signal judgement
03Confidence vs priority
04Human next step
Signals considered
- RTL language market demand confirmed
- current design system lacks RTL support
- i18n framework evaluation initiated
- UI refactoring schedule pressure
Illustrative scenario. This article explains business-signal judgement and human verification. It does not represent a real customer, conversation, contract, revenue result or conversion claim.
A Dashboard That Was Never Designed to Read Right-to-Left
Your SaaS product is an analytics dashboard serving middle managers in enterprise customers. The interface works well in English and European languages — all text flows left-to-right, numbers use comma thousands separators, dates are month/day/year.
The company has now signed its first Middle Eastern customer in Dubai. The contract includes a clause: “The interface must support Arabic, including full RTL layout.” This is not cosmetic. A significant portion of the customer’s operations team works exclusively in Arabic.
You open Figma and mirror-flip the main interface. The layout does reverse — but problems surface immediately. The trend chart’s X-axis timeline defaults to left-to-right. In RTL mode, should it reverse? The data table’s numeric columns — numbers themselves read left-to-right, but column order should flow right-to-left — what is the alignment rule for mixed numeric and text content? Several icons contain directional arrows and back symbols — should they mirror too? Or do non-directional icons remain unchanged?
None of these questions were asked when the design system was built. And now every single one needs an answer before the Arabic version can ship.
Why Adding a dir Attribute Is Not Enough
RTL and localization UX projects encounter three common misjudgments:
“Just add dir=‘rtl’ and you are done.” Adding dir="rtl" to the HTML root element does let the browser handle part of the layout flip — but only the CSS layer. The design system’s icon direction semantics, animation direction, slider and progress bar visual flow, form validation message placement — the browser cannot auto-handle these.
Underestimating mixed-content complexity. A user’s dashboard simultaneously displays Arabic labels and English numbers or code snippets. When a table cell contains “12,345 transactions,” Arabic reading order gives “transaction 12,345,” but the number “12,345” itself reads left-to-right. The typesetting rules for this mixed content are not solvable with a global toggle.
Confusing “built it” with “built it right.” Engineering may complete RTL adaptation of core pages in three weeks and ship. But if the design system’s component library is not simultaneously upgraded with native bidirectional text support, every subsequent feature development will recreate RTL bugs. The fix cost shifts from one-time to continuous.
Evidence to Verify Before You Commit
Before any development begins, complete this assessment:
First: i18n framework baseline capability check. Does your current frontend framework or component library natively support RTL? Is there a built-in DirectionProvider or equivalent? If not, which layer does the refactoring start from? Framework-level changes alter the layout-logic abstraction; component-level changes alter individual component visual appearance. These are different engineering tasks.
Second: design system affected-scope mapping. Audit every component in the design system: (1) which components have direction dependency — arrows, breadcrumbs, pagination, steppers, timelines; (2) which have no direction dependency — avatars, badges, tags; (3) which fall into a gray zone — icon buttons where the icon itself may or may not carry directional semantics. This classification determines which components need dual-mode design.
Third: number, date, and currency localization format inventory. What date format, thousands separator, decimal symbol, currency symbol position, and phone number format does the target market use? These are i18n issues, not RTL issues, but they are intertwined with the RTL effort. A date displayed as “July 27, 2026” may need to render as a Hijri date in Arabic — that requires backend data-layer format support.
Fourth: critical user journey prioritization. List the highest-frequency pages and workflows users touch daily. Dashboard homepage, data filter, report export, settings — sort by daily-active-user path, not by page count. The pages that matter most to daily usage go first.
Fifth: testing strategy and automation coverage assessment. Do your current end-to-end tests support multi-language runs? Can visual regression testing cover RTL mode? If the test infrastructure does not support this, what guarantees quality post-refactoring — manual walkthroughs? Manual walkthroughs are viable for the first release but unsustainable across frequent iteration cycles.
The Human Next Step
Once assessment is complete, proceed in this order:
First, adopt an incremental refactoring strategy with batched releases. Pick three of the highest-traffic pages as batch one — perhaps the dashboard homepage, data filter, and report viewer. These three cover core browsing, input interaction, and data export modes. After batch one ships, collect internal and customer feedback before deciding batch two’s scope and cadence. A full-site single cutover carries too much risk — one component error and the entire product’s first impression is damaged.
Second, upgrade the design system component library in parallel, not just fix pages. While refactoring batch-one pages, upgrade the underlying components to native bidirectional text support. This means subsequent page refactoring can reuse these components instead of adapting each page from scratch. Component-library upgrade velocity determines batch-two and batch-three page refactoring velocity.
Third, establish an RTL-specific design and code review checklist. For any new or modified UI component, the review checklist must include two items: (1) does this component render correctly in RTL layout; (2) if it contains mixed numeric/text content, does the typesetting follow the target language’s convention. The checklist starts long but, as team experience accumulates, most items become development habit.
Fourth, confirm localized terminology and format preferences with the customer. The Arab world is not a single-language market. Word-choice conventions, date-format preferences, even color-culture associations vary across regions. Before the formal launch, have the customer’s end-user representatives walk through critical workflows and provide feedback — not just on whether it functions correctly but whether the wording feels natural and the format matches local expectations.
What Community Messages Cannot Prove
Common suggestions in technical groups — “replace physical properties with CSS logical properties,” “just enable antd’s RTL theme,” “use library X for i18n” — provide valuable technical direction but cannot substitute for the following judgments:
- The directional semantics of each component in your specific design system — a product designer must assess each one individually
- Whether an icon’s directional meaning is culturally recognized in RTL — the “forward” arrow points right in English culture; in Arabic culture, does it also point right? The answer depends on whether the arrow represents “forward in time” or “physically to the right”
- Refactoring time estimates — until the component-level audit is done, any time estimate is a guess
- The user’s actual pain-point priority — data comes from user interviews and usage analytics, not technical discussions
The core of UX localization refactoring is not finding an automation toolkit that “makes it RTL by itself.” It is understanding what your product’s experience feels like in another reading direction, another visual culture. That understanding — only a human can provide.
This is an illustrative business scenario describing the typical evaluation and decision sequence in SaaS UX localization and design system refactoring. It does not involve specific customers, project data, community-message transcripts, or outcome claims. Actual decisions should be based on design system documentation, i18n framework assessment and user testing results.
Frequently asked questions
Does this scenario describe a real customer?
No. This is an illustrative scenario built from common industry patterns. No customer, quotation, revenue figure, or conversion metric is real or claimed.
What is the most underestimated cost in an RTL project?
Not development effort — design consistency verification. Every component needs paired LTR and RTL screenshot review. Icon directionality, arrow semantics, text alignment, mixed-script number/text rendering — these do not become correct automatically after a global CSS flip. Each one needs a human to look at it.