Arabic + English Websites: UX Rules That Prevent Two Brands

Tags:
Web Design
.
Brand Consistency
.
RTL LTR design system,
.
Arabic English web design KSA
.
Arabic website design Riyadh
.
Written By
Astra Trio Labs
Research & Development
March 5, 2026
Share

The most common failure mode in Saudi bilingual web design is not a technical error. It is a coherence failure  the Arabic and English versions of the same website feel like they were built by different companies, for different audiences, in different eras. Saudi buyers notice. And when they notice, they discount both.

Here is what this looks like in practice. A Saudi company invests in a professional English website  clean layout, strong typography, credible case studies, fast load time. Then the Arabic version is produced by translating the English content, mirroring the layout, and swapping the font. The result is a site where the English experience is deliberate and the Arabic experience is mechanical. The spacing feels wrong. The type is cramped. The navigation labels read like they were translated rather than written. The imagery that works cinematically in the LTR layout becomes compositionally awkward when mirrored for RTL.

The Arabic audience  71% of Saudi internet users who prefer Arabic-language content  receives a second-class digital experience from a company that is ostensibly trying to serve them. The credibility damage is immediate and largely invisible to the team that built the site.

This article covers the specific UX architecture, design system rules, and content decisions that prevent this outcome  building a bilingual website where Arabic and English audiences each receive an experience that feels native to their language, coherent with the same brand, and optimized for their specific reading and navigation behavior. This is not a design philosophy piece. It is a technical and strategic rulebook with implementation-level specificity.

Why Bilingual Coherence Is a Commercial Problem, Not Just a Design Problem

Before the technical framework, the commercial stakes are worth establishing precisely.

A Saudi B2B buyer evaluating a vendor will frequently switch between the Arabic and English versions of the same site during their research process. They may read the Arabic service description and then switch to English to check the case studies, or navigate the English blog and then switch to Arabic to read the about page in their operational language. Every time they switch and experience a jarring discontinuity  different visual weight, different content depth, different information architecture  they are receiving a signal that the company does not have coherent internal operations.

In a market where organizational credibility is a primary procurement criterion, incoherence is expensive. A bilingual site that looks like two separate brands is communicating, however unintentionally, that the Arabic experience was an afterthought. For Saudi buyers, an afterthought Arabic experience is a proxy signal for an afterthought commitment to the Saudi market.

The inverse is equally true. A bilingual site where both language experiences are visually coherent, typographically native, and informationally equivalent communicates organizational sophistication and genuine market commitment  two of the most valuable trust signals in Saudi B2B procurement. The UX investment in bilingual coherence pays back in deal quality, not just aesthetics.

The Root Cause: Why Most Saudi Bilingual Sites Break Down

Understanding the failure mechanism makes the solutions significantly easier to implement correctly.

Most Saudi bilingual sites fail at coherence for one of three structural reasons, and often all three simultaneously.

The first is that the Arabic version is produced after the English version is complete, as a translation and mirroring exercise rather than as a parallel design system. This production sequence guarantees that Arabic is a derivative of English rather than an independent expression of the same brand. Every design decision was made in an LTR context and then adapted  which means Arabic receives the adapted version of every decision rather than the original.

The second is that the design system was never defined as a bilingual system. The English type scale, spacing logic, grid structure, and component library were designed for Latin script and then applied to Arabic with minimal modification. Arabic script has fundamentally different characteristics from Latin  different stroke weight distribution, different word-length patterns, different line density at equivalent font sizes, different reading rhythm. A design system that does not account for these differences produces an Arabic experience that is visually inconsistent with the English experience even when the components are nominally identical.

The third is that content strategy was treated as a translation problem rather than a localization problem. The Arabic pages contain the same information as the English pages, in the same structure, organized around the same hierarchy. But Arabic-speaking Saudi buyers do not necessarily prioritize the same information in the same order as English-speaking buyers. The decision-making context, the trust signals that matter most, and the questions that need answering before engagement are partially different. A bilingual site that treats content as language-swappable units rather than audience-specific communication misses the commercial opportunity that genuine localization creates.

Rule 1: Build the Design System Bilingual From the Start

The single most impactful structural decision in bilingual UX architecture is making the design system bilingual at its foundation  not adapting a monolingual system after the fact.

A bilingual design system defines every design token  spacing units, type scales, line heights, component dimensions, grid configurations  with explicit Arabic and English values where those values differ. It does not assume that the English value is the default and Arabic is a variant. It treats both languages as primary expressions of the same visual language.

In practice this means the type scale has two tracks. The English track uses the selected Latin typeface at the sizes, weights, and line heights optimized for that face. The Arabic track uses the selected Arabic typeface  Tajawal, Cairo, IBM Plex Arabic, or equivalent  at sizes, weights, and line heights optimized for Arabic script characteristics. These two tracks will not be identical numbers. Arabic body text typically requires 20 to 30% more line height than equivalent Latin text to achieve comfortable reading density. Arabic display text often requires different size relationships to achieve equivalent visual weight. A design system that forces Arabic text into the Latin type scale produces Arabic that is either too tight or too loose  both of which read as unpolished to native Arabic readers.

Component design requires the same bilingual treatment. Every interactive component  navigation menus, buttons, form fields, cards, accordions, tabs  needs to be validated in both language contexts before it is considered complete. A button that reads correctly at its English label length may break at an Arabic label length because Arabic words for the same concept are frequently longer in character count. A navigation menu that fits cleanly in LTR may overflow or collapse incorrectly in RTL. The validation step is not a QA check at the end of the project  it is a design step that runs in parallel throughout.

Rule 2: Treat RTL as a Layout Logic, Not a CSS Override

The most common technical mistake in bilingual Saudi websites is implementing RTL as a single CSS declaration  direction: rtl applied globally  and expecting this to produce a correct Arabic layout. It does not, and the result is an Arabic experience full of micro-incorrections that individually seem minor but collectively signal amateur execution to Arabic-native users.

RTL is not a mirror of LTR. It is a different layout logic that applies to some elements and not others, in ways that require explicit design decisions rather than algorithmic mirroring.

The elements that should mirror for RTL are: page flow direction, navigation order, text alignment, icon directionality where the icon has inherent directional meaning (arrows, chevrons, progress indicators, breadcrumb separators), form field layout, and the directional flow of sequential content like numbered steps, timelines, and process diagrams.

The elements that should not mirror for RTL are: logos (which remain in their original orientation regardless of page direction), circular or symmetrical icons with no directional meaning, data visualizations where the data has a universal directionality (time series charts reading left to right are universally understood), and embedded media where the content itself has a fixed orientation.

The implementation approach that produces correct results is an explicit [dir="rtl"] CSS architecture  a separate set of directional overrides applied at the document level that address each element category with explicit intent. This is architecturally more work than a global direction declaration, and it produces a qualitatively different result. Every layout decision in the RTL context was made deliberately rather than assumed.

Flexbox and CSS Grid require particular attention in bilingual implementations. Flexbox row direction reverses automatically under RTL for flex-direction: row, which is the correct behavior for most layouts. However, some flex implementations use explicit margin-left and margin-right values, padding-left and padding-right values, or left and right positioning that do not reverse automatically and require explicit RTL overrides. A bilingual codebase needs to use logical CSS properties  margin-inline-start instead of margin-left, padding-inline-end instead of padding-right  wherever directionality is relevant. Logical CSS properties respond correctly to document direction automatically, eliminating entire categories of RTL override requirements.

Rule 3: Typography Must Be Culturally Native, Not Visually Matched

Typography is where most bilingual Saudi websites make their most visible and most damaging error. The error takes a specific form: selecting an Arabic typeface that visually resembles the English typeface  similar weight, similar geometric construction, similar feel  rather than one that is technically appropriate and culturally credible for the Saudi professional audience.

This matters because Arabic typography has a cultural register that Arabic-native readers perceive immediately and intuitively. An Arabic typeface that is geometrically modern but feels thin or informal to Gulf professional eyes undermines the brand authority the rest of the design is working to establish. An Arabic typeface that has been designed specifically for screen rendering at small sizes, with appropriate hinting and weight distribution, produces a reading experience that feels native rather than imported.

The practical typographic rules for bilingual Saudi professional websites:

Arabic and English typefaces do not need to be from the same type family, but they need to share a tonal register. A geometric sans-serif English typeface pairs correctly with a clean modern Arabic sans-serif  Tajawal, Cairo, or Almarai. A humanist or transitional serif English typeface requires an Arabic counterpart with more organic stroke characteristics. The pairing test is not whether they look similar  it is whether a page that contains both feels like a single typographic system rather than two systems in proximity.

Arabic body text should be set at a minimum of 16px on desktop and 15px on mobile  one to two points larger than the equivalent Latin body size  because Arabic script at small sizes loses the letter differentiation that makes it readable. This is not a preference. It is a legibility standard that Arabic-first typographers apply consistently.

Line height for Arabic body text should be set between 1.8 and 2.0  significantly more generous than the 1.5 to 1.6 standard for Latin body text. Arabic script's vertical extenders and the visual density of connected letterforms require more interline space to maintain comfortable reading rhythm.

Mixing Arabic and Latin text within the same paragraph  which happens frequently in Saudi professional content where English product names, brand names, and technical terms appear within Arabic sentences  requires the unicode-bidi property to be handled explicitly. Without proper bidirectional text handling, mixed-script lines break in ways that are visually confusing and grammatically misleading. The CSS properties unicode-bidi: embed or isolate applied at the inline span level, combined with the appropriate dir attribute, produce correct bidirectional rendering for mixed-script content.

Rule 4: Information Architecture Needs Localization, Not Just Translation

Information architecture  the structure and sequence of information across a page and across the site  is the layer of bilingual UX that receives the least attention and produces some of the most significant commercial impact differences between Arabic and English audiences.

The starting assumption to discard is that the English information hierarchy is the neutral default and Arabic content should follow the same structure. Both are audience-specific communication designs, and the audiences have partially different information priorities.

In the context of Saudi B2B web content, the differences that matter most are the following:

Arabic-speaking Saudi buyers weight social proof earlier in the content sequence than equivalent English-speaking buyers. Where an English service page might lead with problem definition, then solution description, then social proof, an Arabic service page that leads with prominent Saudi client logos and Arabic-language testimonials before the solution description will often convert better  because trust establishment precedes solution evaluation in the Gulf buying process. The information is the same. The sequence is different.

Arabic content benefits from more direct, declarative opening statements. English professional writing often uses a warm-up structure  context, then problem, then claim. Arabic professional writing in Gulf business register tends to lead with the core claim and then support it. Homepage headlines, section introductions, and service descriptions that follow this structure in Arabic feel more native and more authoritative to Saudi readers than content that mirrors the slower English warm-up approach.

Service descriptions in Arabic need to address the Gulf context explicitly. An Arabic service page that describes a web design service without referencing Saudi market specifics  Vision 2030 alignment, Arabic RTL expertise, local client track record  is leaving the most commercially relevant trust signal out of the most commercially important language version. English service descriptions for a Saudi company can reference global best practice credibly. Arabic service descriptions need to demonstrate Saudi-specific market knowledge to be credible to the audience reading them.

Rule 5: Imagery and Visual Content Must Work in Both Directions

Imagery is the bilingual UX failure point that most agencies address last and most clients notice first. A photographic or illustrative image that was composed for LTR reading flow  where the visual subject faces right, where text overlay sits on the left, where eye movement is guided left to right across the frame  reads incorrectly in an RTL layout. The subject faces into the edge of the screen. The text overlay is on the wrong side relative to the reading direction. The compositional tension the image was designed to create works against the layout rather than with it.

The correct approach is not to mirror images  mirroring a photograph of a person produces an uncanny result that is often more jarring than the original compositional tension. The correct approach is to shoot or select imagery with bilingual layout in mind from the start, and to art-direct hero images, feature photography, and illustration with compositionally neutral or symmetrical framing wherever the same image will be used in both LTR and RTL contexts.

Where images will differ between language versions  which is often the correct choice for culturally specific photography  the Arabic version should use imagery that reflects Saudi context and faces. This is not a diversity initiative. It is a commercial decision. Saudi B2B buyers respond to imagery that reflects their professional context, and the gap between a stock image of a Western office and a genuinely Saudi professional environment is a subtle but consistent credibility differentiator.

Illustration and iconography need to be audited for directional assumptions. Common UI metaphors have directional defaults: a "back" arrow points left in LTR and right in RTL. A "next" arrow points right in LTR and left in RTL. A reading or document metaphor opens from the right in Arabic. A timeline flows from right to left in Arabic. Any illustration or icon set that was designed for LTR without explicit RTL variants needs either custom RTL variants or replacement with a system that was designed directionality-neutral from the start.

Rule 6: Navigation and Wayfinding Must Mirror Completely

Navigation is the highest-stakes UX component in bilingual coherence because it is the element users interact with most frequently and the one where disorientation is most immediately felt.

A correctly implemented bilingual navigation in RTL does not simply flip the menu items to right-alignment. It mirrors the entire wayfinding logic. The primary navigation items flow from right to left. The logo sits on the right. The CTA button sits on the left. Dropdown menus open to the left. The mobile hamburger menu, if used, sits on the left. Breadcrumbs read from right to left. The language toggle  the mechanism through which users switch between Arabic and English  should be positioned consistently in both language versions so that a user switching languages always knows where to find it.

Sub-navigation and secondary wayfinding elements need the same treatment. Sidebar navigation, which is common on services pages and resource sections, should be positioned on the right in RTL  mirroring its standard left position in LTR. Pagination controls should reverse direction. "Previous" and "Next" labels should not only be translated but should have their directional arrows swapped.

The language toggle itself deserves specific design attention because it is a unique UI element in bilingual sites with no monolingual equivalent. The toggle should display the language option in that language  "العربية" for Arabic, "English" for English  not in the current language. A user reading Arabic who wants to switch to English needs to see "English" as the toggle label, not "الإنجليزية." This seems obvious but is incorrectly implemented on a significant proportion of Saudi bilingual sites.

Rule 7: Performance Must Be Validated Separately for Each Language Version

This rule is technical rather than design-oriented, but it is included here because bilingual performance parity is a UX requirement as much as a technical one. An Arabic version that loads significantly slower than the English version delivers a structurally inferior experience to Arabic-language users  the majority of Saudi internet users  regardless of how well the design executes everything else.

The performance risks specific to Arabic language versions are three. Arabic web fonts are typically larger in file size than Latin equivalents because they contain a larger character set. Without proper font subsetting  loading only the Unicode ranges required for the content being displayed  Arabic font files add significant page weight. Font subsetting for Arabic web fonts should be implemented as a standard step in every bilingual website build, targeting the Arabic Unicode ranges (U+0600 to U+06FF for basic Arabic, with additional ranges for extended Arabic script) rather than loading the full font file.

Arabic text rendering can trigger layout shift if fonts are not preloaded correctly. The Arabic type system uses more complex glyph shaping than Latin script  letters change form based on their position within a word  and the browser rendering process for Arabic text can cause visible content reflow if the font loads after the layout has been calculated. Preloading Arabic fonts using <link rel="preload"> in the document head, combined with font-display: swap in the CSS font face declaration, prevents the most severe layout shift events on Arabic pages.

Right-to-left layout calculations add a small but measurable overhead to browser rendering compared to LTR. On low-end Android devices common among certain Saudi mobile user segments, this overhead can affect Interaction to Next Paint scores on Arabic pages relative to English. Running Core Web Vitals testing separately on the Arabic version  not assuming the English scores apply equally  is a standard quality step that most bilingual site projects skip and that the Astra Trio website redesign checklist includes as a pre-launch validation requirement.

The Quality Test: How to Audit a Bilingual Saudi Website for Coherence

Before launch, and periodically after launch as content evolves, a bilingual coherence audit should be run against the following criteria.

Switch between the Arabic and English homepage versions on a mobile device. The visual weight, the spacing generosity, and the typographic confidence should feel equivalent  not identical, but equivalent. If one feels more polished than the other, the design system has a bilingual inconsistency that needs to be addressed.

Read the Arabic service descriptions as a native Arabic speaker or with a native Arabic speaker present. Assess whether the content reads as originally written in Arabic or as translated from English. The register, the sentence construction, and the information hierarchy should feel native. If the content reads as translated, it needs to be rewritten.

Test every interactive component  navigation, buttons, forms, accordions, modals  in RTL. Every directional element should be correctly mirrored. Every label should be correctly translated in context, not just linguistically  "Submit" on a form should be "إرسال" not a literal translation that reads awkwardly in the form context.

Check every image in the Arabic layout. No photographic subject should be facing out of the frame in a way that was not intended. No text overlay should be sitting on the compositionally incorrect side. No illustration should have directionality that contradicts the RTL reading flow.

Run Google PageSpeed Insights on the Arabic version of the homepage and the highest-traffic Arabic service page independently. Scores should be within five points of the equivalent English pages on mobile. Larger gaps indicate Arabic-specific performance issues that need to be diagnosed and resolved.

This audit, run against a live bilingual site in Saudi Arabia, will surface the specific coherence gaps that are currently reducing commercial credibility with Arabic-language users. As covered in the analysis of why Saudi company websites lose business, the Arabic UX gap is one of the most consistent sources of commercial underperformance for Saudi market websites  and one of the most consistently overlooked.

What Astra Trio Builds for Bilingual Saudi Websites

Astra Trio builds bilingual Arabic and English websites for companies operating in Saudi Arabia as integrated design systems  not as English sites with Arabic versions appended.

Every bilingual project we deliver is built against the seven rules above. The design system is bilingual from token level. The RTL architecture uses logical CSS properties and explicit directional overrides rather than global direction declarations. The Arabic typeface is selected for cultural credibility and screen performance, not visual similarity to the English face. The Arabic content is written natively by Gulf business register specialists. The information architecture is localized for each language audience rather than translated. And performance is validated independently for both language versions before handover.

If your current bilingual website feels like two brands sharing a domain, or if you are planning a bilingual build for the Saudi market and want to do it correctly from the start, speak to our team about what a coherent bilingual design system would look like for your specific brand and sector.

Frequently Asked Questions

Why does my Arabic website look different from my English website even though we used the same template?

Because most website templates  including premium ones  are designed as LTR systems and adapted for RTL rather than built bilingual from the foundation. The adaptation process produces an Arabic experience that is technically functional but visually inconsistent in the specific ways described in this article: typography that does not account for Arabic script characteristics, spacing that was calculated for Latin word shapes, and components that were designed for LTR reading rhythm. Resolving this requires rebuilding the design system with explicit bilingual values, not applying additional patches to an LTR template.

Should the Arabic and English versions of a Saudi website have exactly the same content?

Informationally equivalent, yes. Structurally identical, no. The content should cover the same ground in both languages, but the information hierarchy, opening statements, and emphasis on trust signals should be localized for each audience's decision-making process. Arabic service pages for Saudi audiences should lead with local credibility signals earlier and more prominently than the equivalent English pages. This is audience localization, not content divergence.

How do I ensure my bilingual website scores well on Google.com.sa for Arabic searches?

Arabic SEO requires the same technical foundation as English SEO  correct hreflang implementation, mobile performance, schema markup  plus Arabic-specific elements: content written natively in Gulf Arabic register rather than translated, keyword research conducted specifically in Arabic using Google.com.sa geo-targeting, Arabic alt text on images, and Arabic metadata (title tags and meta descriptions) written for the specific Arabic queries your Saudi audience uses. These are covered in detail in the Astra Trio website redesign checklist.

What is the best Arabic font for a professional Saudi B2B website?

There is no single correct answer, but the most reliable choices for Saudi professional B2B contexts are Tajawal (clean, modern, excellent screen rendering at small sizes), IBM Plex Arabic (technically rigorous, strong at both display and body sizes, carries a credible enterprise register), and Cairo (slightly warmer than Tajawal, well-suited to service and consulting businesses). The selection should be made in the context of the English typeface pairing and the brand register  formal, approachable, technical, or premium  rather than purely on aesthetic preference.

How should a language toggle be designed on a Saudi bilingual website?

The toggle label should always display the alternative language in that language  "English" when in Arabic mode, "العربية" when in English mode. It should be consistently positioned in both language versions so users switching languages always know where to find it. It should not require a page reload  a client-side language switch that updates the URL and content without a full page load provides a significantly better user experience. The toggle should be visible in the primary navigation on both desktop and mobile without requiring the user to open a menu.

Is it more expensive to build a bilingual website correctly than to add Arabic as an afterthought?

The correct bilingual build costs more upfront  typically 30 to 50% more than an English-only site of equivalent complexity. Adding Arabic as an afterthought to an already-built English site costs 40 to 70% of the original build cost and produces a structurally inferior result because the design system, codebase, and content architecture were not designed to accommodate it. The correct bilingual build is both cheaper and better than the sequential approach over a two-year horizon, which is the relevant evaluation window for a website that will be the primary commercial touchpoint for a Saudi market company.

Astra Trio builds bilingual Arabic and English websites for companies competing in Saudi Arabia and the Gulf. If your current site is delivering two different brand experiences to two different audiences, speak to our team about what a coherent bilingual system would look like.