How Dubai teams can test bilingual product journeys
A bilingual product test should follow complete tasks across language, direction, forms, errors, and support. Use this matrix to find breaks that a translated screen review misses.
Mobile and consumer UX
Published Updated 5 min read
Test Arabic and English as complete product journeys, not as two sets of translated screens. Recruit people who use each language for the task in question, then watch them move through discovery, entry, confirmation, errors, and support on the devices the product serves. The same person may choose different languages for different tasks, so let participants choose rather than treating language as a fixed customer trait.
For a Dubai product team, this approach keeps the work locally relevant without assuming every customer prefers Arabic, English, or the same mix. W3C guidance also makes a useful distinction: language and text direction are separate properties. Arabic text needs right-to-left direction, while embedded Latin text and numbers may still run left-to-right. W3C’s guidance for right-to-left scripts recommends explicit direction markup where needed and direction-aware handling of mixed text.
What belongs in a bilingual journey test?
Start with one important task, such as finding an account setting, comparing an offer, or asking for help. Write down the user’s goal and the product state at the beginning and end. Then make a matrix that pairs each journey moment with the language and behavior to inspect.
| Journey moment | Arabic run | English run | Evidence to record |
|---|---|---|---|
| Entry and language choice | Find and change language without losing the task | Find and change language without losing the task | Choice, reset behavior, retained state |
| Browse and compare | Read labels, prices, dates, and mixed-script names | Read the same information and compare items | Misread content, layout shifts, missing detail |
| Enter information | Type Arabic and Latin text, numbers, and identifiers | Type English text and identifiers | Cursor position, validation, saved value |
| Recover from a problem | Understand an error and return to the task | Understand the same error and return | Cause, next action, preserved work |
| Contact or get help | Explain the issue and continue in a chosen channel | Explain the issue and continue in a chosen channel | Context passed, language choice, response path |
This is a proposed worksheet, not a claim about how Dubai residents behave. Add the product’s actual task, terminology, and support route before recruiting. Include a change of language mid-task if the product allows it. Check whether the user returns to the same item, entered data, and scroll position after switching.
How should teams test right-to-left behavior?
Review the rendered product, not just the source strings. Check Arabic paragraphs, navigation order, back and next actions, icons with directional meaning, tables, date ranges, phone numbers, account identifiers, and Arabic text beside Latin names. In a form, type Arabic into a field that also accepts an email address or reference number. Observe where the cursor starts, how punctuation appears, and whether the submitted value survives review and editing.
W3C recommends using the HTML dir attribute to express direction and logical CSS properties such as “start” and “end” for layout that should adapt. It also documents the automatic direction setting for text inputs, where direction follows what a person types. These are implementation choices for the engineering team; the research task is to identify where actual content becomes hard to enter, read, or verify. W3C’s HTML directionality overview explains the distinction between language declarations and direction markup.
Record the precise state that breaks. “Arabic layout is confusing” is hard to act on. “The confirmation number moves next to the wrong label after switching language, and the participant cannot tell which number to share” gives design and engineering a reproducible issue.
Who should take part in the test?
Recruit around the product decision, not a broad demographic label. Ask how participants use this product, which language they prefer for this task, what device they brought, and whether they use accessibility settings or assistive technology. If a product serves people with different levels of familiarity, include both new and returning customers. Treat those as research dimensions, then report what the sample did and did not include.
Do not ask one participant to stand in for everyone who reads Arabic. Arabic content can vary by product vocabulary and audience, and a research session should not pretend to settle every regional language question. Have the product owner identify approved terminology and invite the relevant content reviewer to observe or review clips, with participants’ consent.
Accessibility checks belong in both language runs. The W3C Web Content Accessibility Guidelines require the language of a page to be programmatically determinable and, at Level AA, require the language of passages to be determinable where applicable. Test labels, focus order, error descriptions, zoom, and screen-reader output alongside visual layout.
How can teams turn findings into a release plan?
For each issue, record the language, screen, device, task step, participant evidence, impact on task completion, and the team that can resolve it. Mark whether the defect sits in content, interface behavior, a shared component, or a service response. That distinction helps teams avoid assigning every bilingual problem to translation.
Then rerun the affected journey after the change. The acceptance check should describe a visible behavior: a participant can enter the value, review it, switch language, and continue without losing context. A screenshot of a corrected label is not enough when the original failure occurred during form submission.
For a wider regional product brief, Humbleteam’s Dubai page describes its product-design services, and the Arabic and English AI search guide covers search-specific content and retrieval questions. This guide focuses on testing a full product task across states and handoffs, including where no search feature is involved.
