Building a Design System That Scales Across Europe and the GCC

Most design systems break when they hit a second language or a second region. Components designed for left-to-right English layouts collapse in Arabic. Spacing rules optimised for Latin scripts produce awkward Arabic. Colour systems that worked in Paris feel cold in Riyadh.

Building a system that works across both markets from day one is harder upfront and infinitely cheaper later.

The cost difference is substantial. A design system built monolingual then retrofitted for Arabic and RTL typically costs 40-60% of the original build — and the patched result is rarely as clean as a system designed bilingual from day one. Studios that have shipped both approaches consistently recommend the second.

Foundations that work bilingual

Typography: choose Latin and Arabic typefaces designed to coexist. Match x-height, weight balance, optical sizing.

Spacing: use ratio-based rather than absolute spacing. 8/16/24/32 grids work better in RTL than fixed pixel values.

Color: define colours by role (surface, text, action) not by visual appearance. This lets the system adapt to dark mode and accessibility variations cleanly.

Tokens and the case for design primitives

Modern design systems rely on tokens — abstract design values referenced by name rather than by hardcoded value. Token names like color.surface.primary, space.layout.lg, or typography.heading.xl mean the system can shift across themes, languages, and platforms without rewriting every component.

For Europe + GCC systems specifically, tokens unlock three things: dark mode without redesign, accessibility variations (high contrast, larger text) without forking, and language-aware spacing where Arabic might need slightly more vertical breathing room than English at the same font size.

The studios building the strongest GCC enterprise design systems in 2026 — including the in-house teams at e&, Talabat, and a handful of PIF-backed Saudi ventures — have moved fully to token-based primitives. Anyone still hardcoding hex values is now a generation behind.

RTL components from the start

Every component needs to mirror cleanly in RTL. Buttons with leading icons reverse to trailing icons. Navigation that flows left-to-right reverses. Cards with image-then-text reverse to text-then-image.

Build this in from day one. Retrofitting RTL into a system designed LTR-only typically costs 30-50% of the original system build.

Typography pairing in practice

The hardest design system decision for European + GCC work is the Latin/Arabic typeface pair. A poor pair undermines every screen, every print application, every motion piece. A great pair becomes invisible — the brand reads consistently whether the audience sees French, English, or Arabic.

Proven combinations include: Adelle Sans + Adelle Sans Arabic (TypeTogether), Greta Sans + Greta Sans Arabic (Schick Toikka), Aktiv Grotesk + Aktiv Grotesk Arabic (Dalton Maag), Söhne + a custom Arabic counterpart. For luxury brands, consider 29LT Bukra (29 Letters) paired with a custom Latin serif designed at matched x-height.

Avoid: any "Arabic version" of a Latin font that was generated rather than designed, system Arabic fallbacks (the proportions are always wrong), and free Google Fonts Arabic that wasn't built by an Arabic typographer.

Component documentation that scales

Each component needs: visual examples in both directions, do/don't usage rules, code examples in HTML/CSS or React, accessibility notes, and translation notes for sensitive copy.

Skip these and the system becomes inconsistent within 6 months as multiple teams interpret it differently.

Localisation as a system property

Date formats, number formats, currency display — these vary across markets. Build them into the system as configurable rather than hardcoded.

Saudi vs UAE vs French vs UK conventions differ. A system that handles all four cleanly is worth 10x one that hardcodes one.

Versioning and developer handoff

A design system without a versioning model becomes unusable within 18 months. Every component, every token, every guideline needs a version number. Breaking changes get major bumps. Additions get minor. Bug fixes get patches. This is the same discipline applied to software, applied to design.

For multi-region systems, versioning matters even more because regional applications often need different release cadences. A French e-commerce site might adopt v3.2 while the GCC retail rollout stays on v3.0 until quarterly review. Without explicit versioning, both teams diverge in incompatible directions.

The developer handoff is where most design systems break in practice. Designers ship Figma; developers consume code. The gap is wider in multi-region work because the developers writing the React or Vue components need to understand RTL behaviour, locale-aware date formatting, and bidirectional text rendering. Documentation that assumes monolingual readers will fail.

Maintenance and governance

A design system without active maintenance becomes a wishlist. Assign at least 0.5 FTE to system maintenance for any company over 50 people.

Quarterly system reviews. Annual major revisions. Continuous component updates. The system is a product, not a project.