Designing Arabic-First AI Assistants: Beyond Flipping the Chat Bubble

Most writing about Arabic chatbots is about the language model: dialect support, tokenization, accuracy. Much less is about the interface. Teams take an English chat UI, set it to right-to-left, flip the bubbles, and ship. It works until the assistant streams a reply that mixes Arabic, English product names, numbers and a code snippet. Then the text jumps around while it's being written, and users stop trusting what they read.

NN/g argued recently that an assistant's value comes from personal context and knowing its limits, not from raw intelligence. For Arabic-first products, I'd add a third thing: an interface that handles the language properly. Here's what to design differently.

Why "add RTL support" isn't enough for AI chat

A static Arabic screen is designed once and checked once. A chat reply is generated on the fly, can contain any mix of scripts, and arrives word by word. Every RTL edge case you'd normally fix in design review now happens live, in front of the user, in content you didn't write.

So the design work moves from screens to rules: how the interface handles any reply the model might produce.

Bidirectional text in streamed replies

These are the cases to design and test:

• English words inside Arabic sentences. Brand names, product names and technical terms. Without isolation, punctuation and neighboring words can jump to the wrong side.
• Numbers, prices and dates. "Your order #A-2041 costs 350 EGP" in an Arabic sentence can reorder while it streams.
• Code and URLs. These are always left-to-right and should be shown in their own LTR blocks, not inline in Arabic text.
• Lists and tables. Markdown lists in an Arabic reply need RTL bullets and alignment. Tables with mixed columns need a clear direction per column.
• Replies that change language. A user asks in Arabic, the answer quotes an English source. Each paragraph should get its direction from its own content (dir="auto"), not from the page.

For developers, the key tools are dir="auto" per paragraph, <bdi> or unicode-bidi: isolate around embedded LTR runs, and rendering code blocks as LTR. For designers, the job is to show these cases in the specs so they get built.

[Waleed: add a screen recording or before/after of a streamed mixed-direction reply.]

Dialect, formality, and letting users choose

Arabic speakers switch between Modern Standard Arabic and their own dialect depending on context. An assistant that always answers in formal MSA can feel stiff. One that guesses the wrong dialect can feel odd or even disrespectful.

• Offer a simple setting: formal Arabic or a dialect such as Egyptian, Gulf or Levantine.
• Default to matching the user's own writing, and say so in the settings.
• Keep sensitive content, like legal, medical or financial terms, clear and precise regardless of dialect.
• Decide how the assistant addresses users (gendered or neutral forms) and keep it consistent.

Trust signals and sources in RTL

Citations, source chips and confidence indicators were mostly designed for English layouts. In RTL:

• Source chips follow the reading direction and sit at the end of the sentence or paragraph they support.
• English source titles inside Arabic replies are isolated so they don't reorder the surrounding text.
• Show the source's language. An Arabic answer based on English sources should say so.
• When the assistant isn't sure, say it plainly in the user's language. Knowing its limits is part of what makes an assistant trustworthy.

Context and memory in a regional setting

Personal context is what makes an assistant useful, and in the region it comes with specific expectations. Users expect the assistant to know their city, currency, calendar (including Hijri dates and Ramadan hours where relevant) and preferred language. They're also often cautious about what it remembers, especially on shared family devices.

• Show what the assistant remembers, in a place users can find.
• Make forgetting easy and confirm it clearly.
• Ask before using sensitive personal context.

Voice input

Many users in the region prefer voice notes to typing, especially in dialect. Design voice as a first-class input: show the live transcript in Arabic, let users correct it before sending, and handle replies that mix dialect and English words.

Pattern sheet for Arabic AI chat UIs

• Layout mirrored: user and assistant bubbles, input bar, send icon.
• Each paragraph uses dir="auto"; embedded LTR runs are isolated.
• Code, URLs and commands are rendered as LTR blocks.
• Numerals and currency follow the market's rule.
• Arabic typography with line height around 1.6–1.8 and no letter-spacing.
• Dialect and formality setting, remembered per user.
• Source chips at the end of the supported text, with the source language shown.
• Visible, editable memory.
• Voice input with an editable Arabic transcript.

See it in real projects

For the RTL foundations behind these patterns, read my Arabic RTL app design checklist, and see Arabic-first products like Qarib food delivery and Waddini ride hailing.

Sources: The New Siri's Biggest Strength Is Not Intelligence (NN/g), Beyond the Canvas: What Config India 2026 revealed (UX Collective), A Bilingual Arabic/English UX Checklist for Web Teams (DEV).

FAQs