Arabic and English Product Design: What to Localise First

A UAE startup can translate its home page and still leave customers unable to complete a booking, understand a charge or recover from an error. Start with a complete customer task. Follow it from the first promise through payment or submission to the confirmation and any help the user might need. Then decide which language work must be finished before release and which material can follow.

Consider a hypothetical Dubai startup offering paid bookings for workshop sessions. A customer finds a session, chooses a date, checks what is included, pays and receives a booking reference. If the venue moves the session, the customer has to understand the notice and know how to change the booking. That path crosses marketing, the product interface, payment, email and support. The people who own those systems may work separately. To the customer, it is one service.

Start with the task and its consequences

Map the steps customers actually take, including entry points outside the home page. One person might arrive through an Arabic advertisement and land directly on a workshop page. Another might receive a booking link from a colleague and switch languages midway. A third might come back through a reminder after the session time changes. Identify the language choices available at those points and what state the user could lose by switching.

Prioritise by what happens if a user misunderstands or cannot complete a step. A poorly translated biography may create a bad impression. An unclear rescheduling deadline can change what a customer pays or whether they attend. A broken payment error can leave the customer unsure whether to retry. Record which steps are frequent and which are consequential. A rare refund failure may still deserve attention ahead of a widely read but low-risk page.

Make a separate inventory of legally relevant customer material. UAE Federal Law No. 15 of 2020 on Consumer Protection requires Arabic for consumer-related data, advertising and contracts within its scope, with other languages permitted alongside it. Article 8 addresses Arabic invoices, and Article 25 addresses information supplied in Arabic by UAE-registered e-commerce providers within scope. The executive regulations add detail. Have the actual product and material reviewed before launch. The work required by applicable rules belongs in the release plan regardless of the order in which teams prefer to translate the interface. UAE Consumer Protection Law, Articles 8, 25 and 26 · Consumer Protection Executive Regulations

Translate the meaning of each choice

Write a short glossary based on what users need to decide. For the workshop example, distinguish a booking request from a confirmed booking and a cancellation request from a completed refund. Define each status for both language teams. When the product sends a message, it should describe the state the system actually recorded. A translation that turns an acknowledgement into a confirmation can make the customer act before a place is reserved.

Give translators context and the constraints of the screen. Show where each sentence appears, which variable values may be inserted and what action follows. A button labelled with a generic verb may need a more specific action once it appears next to a payment total. Have a reviewer check the wording in the actual flow. Reviewing a spreadsheet alone makes it easy to miss that a warning comes after a commitment or that a subject line contradicts the message it opens.

Keep quantities, money and time consistent. Make sure both versions identify the same currency, taxes or fees as applicable, total and cancellation period. For dates, display enough context to distinguish the day and month, and check the time shown in reminders against the booking record. Test the exact text when a workshop moves to a new slot. A pair of individually clear translations can still create different promises if one keeps an outdated deadline.

Build right-to-left behaviour into the product

The UAE Design System's guidance for government projects calls for Arabic and English support and describes page language and direction declarations, mirrored navigation and suitable fonts. The W3C explains how to set base direction in HTML and handle text whose direction differs from the surrounding content. Use those principles to build layouts that can follow the reading direction while preserving the meaning of the data. UAE Design System technical guidance · W3C structural direction guidance

Check mixed-direction content rather than relying on a translated screen that contains only Arabic. A booking may include an English venue name, an email address, a booking reference and Arabic instructions in the same sentence. Put examples of those values through the interface, emails and generated documents. The W3C's inline guidance explains markup for isolating bidirectional text. Check that punctuation appears where readers expect it and that selecting or copying an identifier still gives the correct value. W3C inline bidirectional text guidance

Review each visual element for meaning. A back arrow may need to follow the navigation direction. A logo or a label printed on the image of a ticket should keep the intended form. Test keyboard navigation, focus and screen reader behaviour as well as appearance. A layout can look correctly mirrored while the focus order takes a keyboard user through fields in an unexpected sequence. Test on a narrow phone screen with long, realistic strings and on the device staff use to verify a booking.

Keep a language switch visible and give it a predictable destination. A customer reviewing a selected workshop should land on the same selection after switching where the flow supports that. If a step cannot preserve input safely, explain what will happen before the switch and test recovery. Check that switching after an error does not generate a duplicate submission or payment attempt. Preserve a booking reference and transaction state independently of translated interface strings.

Carry the language choice past the checkout

Follow the task through email, text messages, payment provider screens, downloadable receipts and staff interfaces. For each handoff, identify who controls the content and what the user sees when the preferred language is unavailable. If the customer has to continue elsewhere, tell them which step is coming and what to check when they return. A successful booking page is only one part of a service that has to confirm payment and deliver a usable record.

A Dubai Consumer Rights reel shows a bilingual complaint follow-up graphic. It is a historical example of how a service communicates about recovery. In the workshop product, the equivalent task is finding the booking, understanding the current status and requesting a change. Make the same reference and update available to the support team so the customer can continue the case after switching channels or languages.

Test support against the product's terms. Give an agent a booking with a time change and ask them to explain the available actions in both languages. Check that they can see the same price, status and deadline as the customer. If an agent has to interpret an English-only internal status, give the team an agreed explanation and update it with the product. This work can prevent an inconsistency that a screen review would never reveal.

Measure completion and recovery in both languages

Recruit people who ordinarily use each language for the type of task under test. Ask them to complete the same scenario and explain what they believe will happen. For a payment scenario, check that they can identify the total and whether the system has charged them. For a rescheduling scenario, ask what changes, whether there is a cost and where they would look for confirmation. Observe their actions before offering hints.

Suppose an illustrative test gives 12 Arabic users and 12 English users the same booking task. Nine in the Arabic group and ten in the English group complete it without help. The completion rates are 75% and about 83%. One result changes either rate by about eight percentage points. The stronger evidence for a fix could be that two participants in one group cannot read the same booking reference after an error. Watch those cases, repair the display or recovery step and repeat the task. Small groups can reveal defects without providing a reliable language-wide conversion estimate.

Separate language preference from browser settings and acquisition channel when reading product data. A user may open a link in one language and switch before paying. A campaign might send mobile users directly to an offer while another group arrives through search. Report the language of the actual task and the relevant conditions when possible. For metrics such as error recovery, count people who encountered the error and had a chance to recover. Counting every visitor can hide problems among those who needed help.

Include staff in the same exercise. Have a venue employee scan or enter the reference from an Arabic confirmation and find the corresponding booking in whatever language the staff console uses. Then ask the employee to record a change and check the message the customer receives. A mismatch could come from a translated status, a truncated reference or a separate system that formats the date differently. Fix the underlying handoff when possible. Otherwise, document the workaround and test it with the people who will use it on a busy day.

Release a path the team can keep current

Assign owners for interface strings, customer terms, message templates, receipts and support material. Decide which changes must be released together. If the booking deadline changes, identify every place that displays it and confirm both language versions use the same underlying rule. Keep translations attached to the product version they describe. A content review should catch a stale sentence before a pricing or policy change reaches customers.

Use a short release checklist based on the task. Start with the offer, continue through a normal booking and then deliberately test a failed payment and a change. Review Arabic and English on the same build, including the records sent outside the interface. Document the defects that block a decision, charge or recovery. Defer cosmetic changes with an owner and a reason where the affected path is still usable and meets applicable requirements.

For the Dubai workshop team, the first localisation milestone is a customer who can choose a session, understand the price, book it, find the confirmation and handle a change in the language they are using. That gives the founders a clear way to order the work and a task they can test again whenever the product or its terms change.