Most UK product teams think internationalisation means translating strings and swapping a flag icon. Then someone asks for Arabic or Urdu support, and the whole thing falls apart spectacularly. Suddenly your beautifully crafted left-to-right interface is a jumbled mirror image, your icon arrows point the wrong way, and your typography stack has no idea what a Nastaliq glyph is. Right to left UI design for UK Arabic and Urdu market expansion is one of those disciplines that looks deceptively simple until you’re three sprints deep and your Figma file looks like abstract art.
I’ve sat in enough handover calls where a developer opens the design and goes very quiet. That silence is never good. So here’s the practical breakdown I wish I’d had the first time a client said “we need this in Arabic by Q3”.
Why RTL is not just a text direction toggle
The most dangerous assumption you can make is that flipping the CSS direction: rtl property is the finish line. It’s barely the start. Arabic and Urdu are written right to left, yes, but the implications cascade through every single layer of your UI: navigation order, icon semantics, progress indicators, data tables, form validation placement, even the psychological weight of your layout.
Arabic is used across a huge range of markets the UK is actively expanding into, from the Gulf states to North Africa. Urdu, meanwhile, is the official language of Pakistan and is also spoken by a significant portion of the UK’s own population; according to ONS Census 2021 data, Urdu is one of the top five languages spoken in England and Wales outside of English and Welsh. Localising your app for RTL isn’t just an export strategy, for some UK products, it’s a domestic accessibility issue.
Getting your Figma setup right before you write a single line of CSS
Figma doesn’t natively handle RTL the way a browser does, and that gap trips up more teams than any coding error. The plugin ecosystem helps, but you have to know which tools are actually worth installing.
Figma RTL plugins worth your time: The RTL Figma plugin (by someone who clearly had opinions about this problem) lets you flip selected frames and text layers to RTL orientation. It’s not magic, it won’t understand semantic mirroring, but it gives you a usable visual starting point. Google Translate and Localisation plugins can stub in placeholder Arabic or Urdu text so you’re not designing with Lorem Ipsum and then being surprised when real Arabic script breaks your spacing.
The typographic side deserves its own paragraph. Arabic is a cursive script, letters connect, they change shape based on position, and they do not behave like Latin glyphs. Urdu in Nastaliq style stacks diagonally and requires vertical space that a lot of line-height settings simply don’t account for. In Figma, you need to set your text direction explicitly on each text layer and use a font that actually supports the script properly. Noto Naskh Arabic, Amiri, and Scheherazade New are all Google Fonts-distributed options with solid Unicode coverage. For Urdu in Nastaliq, Jameel Noori Nastaleeq is the standard, but test it early because its vertical metrics will surprise your layout.
CSS logical properties: the right way to handle RTL in code
If your codebase is full of margin-left, padding-right, and border-left, you’ve built a directional debt problem. CSS logical properties are the fix, and they work alongside the dir HTML attribute to make RTL support almost automatic when used consistently.
The swap is straightforward in principle. Replace margin-left with margin-inline-start. Replace padding-right with padding-inline-end. Replace text-align: left with text-align: start. Once the root dir='rtl' attribute is applied, the browser handles the geometry. No separate RTL stylesheet. No duplicated rules. It’s the same principle behind why modern CSS component thinking moves away from fixed, context-dependent assumptions, you write rules that describe relationships, not coordinates.
Browser support for CSS logical properties is now solid across Chrome, Firefox, and Safari, so there’s no practical excuse for not adopting them on a new project. The harder work is refactoring an existing codebase. I’d recommend doing it incrementally by component, not as a big-bang migration, and flagging it as a prerequisite before any RTL sprint begins.
The mirroring rules most Western teams get wrong
Not everything mirrors. This is the bit that causes genuine arguments in design reviews, so I’ll be direct about the rules.
Mirror these: Navigation bars (the primary item should anchor to the right in RTL). Breadcrumbs and progress steppers. Back/forward arrows. Lists and menus. Form field layouts. Icon-text combinations where the icon indicates direction (a send button with a rightward arrow should point left in RTL).
Do not mirror these: Clocks and clock faces (time doesn’t reverse). Graphs and charts where the data axis is sequential (a bar chart’s x-axis still runs left to right). Logos and brand assets. Video playback controls (by convention, these stay LTR globally). Telephone numbers and numeric strings.
The hardest case is icons. An arrow that means “go forward” should flip. An arrow that means “play media” should not. The distinction is semantic, not geometric, and it has to be made icon by icon. Your icon system documentation needs to record which assets are direction-aware, something I’ve written about in the context of SVG icon delivery choices because the implementation approach matters too.
Typographic considerations specific to Arabic and Urdu
Arabic numerals (the ones you’re already using: 0-9) are actually called Hindu-Arabic numerals globally. But in many Arabic-language contexts, Eastern Arabic numerals (٠١٢٣٤٥٦٧٨٩) are preferred or expected. Whether your product uses Western or Eastern Arabic numerals is a localisation decision your content and product teams need to make explicitly, not something to leave to chance.
Line height is almost always wrong on first attempt. Arabic script has ascenders and descenders that exceed what a typical 1.5 line-height setting accommodates. Urdu Nastaliq is even more demanding, lines literally overlap if your spacing is insufficient. Set line-height to at least 2 for Arabic and test Urdu Nastaliq at 2.5 or above. These are not aesthetic choices; they are legibility requirements.
Font size also behaves differently. Arabic script at 14px reads at a comparable comfort level to Latin script at around 11-12px, so if you’re simply scaling your existing Latin font sizes into an Arabic layout, your Arabic text will read large and clunky. Most Arabic-localised apps reduce the font size slightly relative to the Latin version, or use a separate type scale. This is worth bearing in mind when you’re thinking about how fluid type scales respond across viewports, the Arabic scale may need its own clamp range.
Testing: you cannot eyeball RTL correctness
No matter how confident your team feels, RTL UI design needs native-speaker review. Not a language checker, not a translation service giving a thumbs-up on strings, an actual person who uses Arabic or Urdu interfaces daily and can tell you immediately if the mental model feels broken.
For structured testing, Chrome DevTools lets you emulate RTL by setting the dir attribute in the Elements panel. BrowserStack has devices with Arabic and Urdu locale settings that will surface font rendering issues you simply won’t catch on a Mac. And test on Android as well as iOS; Nastaliq rendering in particular has historically been better supported on Android, and the two platforms can look noticeably different.
Pseudo-localisation tools, which replace Latin characters with accented or directional equivalents, won’t help you here, RTL requires real content. Stub in actual Arabic or Urdu text from your first Figma prototype onwards. The layout surprises come from real text, not placeholders.
Getting RTL right is genuinely complex work. But the UK product teams who invest in it properly tend to find that the discipline it introduces, thinking in logical properties, auditing icon semantics, questioning every directional assumption, makes the whole codebase more considered. That’s a side effect worth having.