Arabic type, tone and layout
Start the design in Arabic. An English layout flipped at the end rarely survives real content, because Arabic is shaped differently from Latin text. Our Arabic and RTL design work starts from these rules.
- Type. Pick an Arabic typeface with several weights and test it at your smallest size. Arabic often needs a slightly larger size and a taller line height than Latin text.
- No tracking, italics or capitals. Letter spacing breaks the joins between Arabic letters, and Arabic has no true italic and no capitals. Emphasise with weight or colour.
- Numerals. Western and Arabic-Indic digits are both understood. Pick one rule per product and keep one style within a screen.
- Gender and plurals. Arabic verbs change with the user's gender, and counts take different forms for one, two, a few and many. Build plural rules into the message system.
Fix these choices once in a design system: an Arabic type scale, mirrored components and a message library that every screen reuses.
Mixed Arabic and English content
Saudi products rarely hold one language. Product names, codes, email addresses and English terms sit inside Arabic sentences, and a person's name may be saved in Arabic and in Latin letters. The guide to bilingual Arabic and English products gives the method; these are the design decisions.
- Decide what stays English. Brand names, codes, email and web addresses usually stay as they are, while labels and instructions are translated. Write the rule down for editors.
- Keep runs readable. A Latin word or number inside an Arabic sentence can push punctuation to the wrong side, so the design needs spacing that keeps each run clear. See RTL design.
- Store both name forms. Let people give a name in Arabic and in Latin letters, search both and show the one that matches the interface language.
- Keep the user's place. A language switch should keep the page, the filled form and the scroll position. See localization.
Designing for the phone first
Many Saudi users will meet a product on a phone first, so design the small Arabic screen before the desktop one, and test it on a mid-range Android phone as well as a recent iPhone.
- Reach and mirroring. In a right-to-left layout the start edge is the right. Keep the main actions within easy reach and put back and menu controls at the start.
- Keyboards. Open the right keyboard for each field: Latin for email and web addresses, numeric for codes and phone numbers, Arabic for names. A form that forces a keyboard switch on every field loses people.
- Weak signal and shared links. Show what is loading, keep what the user typed and keep images light. Links are often shared in chat apps, so give every page a clear title and make sure a shared link opens a useful screen.
Forms, identity and payment flows
Identity and payment steps ask for the most and tolerate the least, so forms are where Saudi products win or lose users.
Names, numbers and addresses
- Names. Do not force a first and last name. Allow several parts and both Arabic and Latin spellings.
- Phone numbers. Use the +966 country code, accept a number typed with or without the leading zero and store one international format.
- National ID and residence numbers. Ask only when the service needs them, accept Western and Arabic-Indic digits, mask the number after entry and keep it out of links.
- Addresses. Offer a map pin, a free-text line for landmarks and, where needed, the National Address. Check its current format with the provider you use.
Signing in with Nafath
Nafath hands the user from your screen to the identity app and back. Design the states that cause drop-offs: waiting (say what to do in the app and show a timeout), declined or expired (offer a retry and another way in) and no app on the device (explain the next step). Access is set by the issuing authority, so ask early what approval you need. The web development page covers the technical side.
Payment screens
Show the total, the delivery details and the payment choices on one screen, with the methods your audience expects, such as mada, Apple Pay and cards. Many banks send the user to their own app to approve a payment, so design the return: a pending state, a clear result in Arabic and a way to resume without paying twice.
Calendars and dates in the interface
The Hijri calendar (Umm al-Qura) is used for many official purposes and Gregorian dates for much of commercial life. The design question is which one the user sees where.
- Choose per field. Bookings, deliveries and invoices usually read best in Gregorian dates, while official and personal documents are often expected in Hijri. Where both matter, show both and label them.
- Date pickers. Start the week grid on Sunday, mark Friday and Saturday as the weekend and test the picker in Arabic with real dates, because many components assume Gregorian dates.
- Moving dates. The start of Ramadan and the dates of Eid depend on moon sighting, so copy that promises a Hijri date far ahead needs a note that it may move by a day.
Accessibility from the first sketch
Government and enterprise buyers often ask for WCAG conformance, commonly at level AA, so ask which version and level your client expects before design starts. Fixing it at the sketch stage is cheaper.
- Check text contrast at the smallest size, because thin Arabic strokes lose contrast faster than large headings suggest.
- Make focus and reading order follow the right-to-left layout, including mirrored carousels and tables.
- Mark the language on inline English words so screen readers switch voice, and test with an Arabic screen reader.
- Keep text out of images, and keep it readable at 200 percent zoom.
Research with Saudi users, done remotely
Design decisions for Saudi users should be tested with Saudi users, and that works well remotely, with moderated video sessions or unmoderated prototype tests in tools such as Figma and Maze.
- Recruit by behaviour. Define the audience by what people do, such as having paid a bill online, and include different regions and levels of English.
- Run sessions in Arabic. The guide, the prototype and the notes should exist in Arabic. The synthesis can be written in English or Arabic, depending on who reads it.
- Book around the day. Sessions fall inside the Sunday to Thursday week. Check prayer times when booking live calls, and expect different availability in Ramadan.
- Test the hard flows. Nafath, payment, a form with an Arabic name and a screen with mixed-language content.
Awareness, not legal advice. A recorded session holds personal data. Ask for consent in Arabic, say what is recorded and for how long, and confirm the rules that apply with qualified local counsel.
Working-week planning and what to ask a provider
We work remotely and plan calls around your working day, so design reviews and the weekly demo land inside your Sunday to Thursday week. Saudi Arabia is on UTC+3 all year, so slots do not shift with the seasons. Briefs, critiques and reviews can run in Arabic or English.
Plan for the seasons too. Ramadan shortens working hours and shifts usage to the evening, and Eid and national days bring campaigns. Build banners and promotions as content in the design system, so a seasonal change is an edit, not a redesign. When you compare design providers, ask:
- Is Arabic designed first, or translated from an English layout at the end?
- Who writes and reviews the Arabic copy?
- Will the prototype use real Arabic content, with long names, mixed text and large font settings?
- How are Nafath, payment and form flows tested with real users?
- What do I receive: a design system with Arabic type and mirrored components, or only screens?
See UI/UX design for the whole service, web development for the build, how we work for the rhythm and Saudi Arabia for the wider picture.