Copywriting · UX writing
The words inside your product: buttons, form labels, error messages and empty screens. Written in English and Arabic for users in the UAE, with right to left layouts and accessibility treated as requirements.
Words inside the product
“Submit” on a booking form. “Invalid input” under a phone number field. A blank screen with no hint of what to do next. UX writing fixes the small pieces of text that decide whether someone in Dubai finishes a task or gives up. It sits alongside UI UX design: the designer shapes the screen, and we write what it says, in English and Arabic.
Microcopy
In UX writing for Dubai products, microcopy is any short piece of interface text. Each type has a different job, and a consistent pattern for each one makes the whole product easier to learn.
A verb plus the thing it acts on: “Book viewing”, “Pay invoice”, “Save address”. The label should predict exactly what happens after the tap.
The screen before there is any data. It explains what will appear here and offers the first action, rather than just saying “No results”.
What just happened and what happens next: “Your viewing is booked for Tuesday. We have sent the details to your email.”
A short hint under a field, shown before the user makes a mistake, for example the format expected for a date of birth.
Push and in app messages that make sense on a lock screen, without the surrounding app to explain them.
Why the app wants location, camera or contacts, written before the system prompt appears so the request is not a surprise.
Error messages
In UX writing for Dubai apps, WCAG 2.2, the W3C accessibility standard, has two success criteria that apply directly. Error Identification (3.3.1, level A) requires that when an input error is detected automatically, the item in error is identified and the error is described to the user in text. Error Suggestion (3.3.3, level AA) requires that known suggestions for correction are provided, unless that would jeopardise security or purpose.
| Field | Unhelpful message | Rewritten message |
|---|---|---|
| Mobile number | Invalid input | Enter a UAE mobile number, for example 050 123 4567 or +971 50 123 4567 |
| Date of birth | Error | Enter the date as day, month, year, for example 04 09 1990 |
| Password | Password does not meet requirements | Add at least one number. Your password has the other characters it needs |
| Card payment | Transaction failed | Your bank declined this payment. Try another card or contact your bank |
| Required field | This field is required | Enter your building name so the courier can find you |
Error text must not rely on colour alone, and must be connected to its field in code so screen readers announce it. That is development work, and we note it beside each string.
Forms
Forms are a common place for users to give up on a Dubai app or website, and UX writing is where a lot of that friction gets fixed in the wording. WCAG 2.2 sets several requirements that UX writing directly supports. Labels or Instructions (3.3.2, level A) requires labels or instructions when content needs user input. Redundant Entry (3.3.7, level A) says information the user already entered in the same process should be filled in automatically or offered for selection. Error Prevention (3.3.4, level AA) applies to legal commitments and financial transactions, where submissions must be reversible, checked, or reviewable before they are final.
Label in Name (2.5.3, level A) matters for people who use voice control: the accessible name of a button must contain its visible text, so a button that reads “Book now” is not announced as “Submit form”.
Right to left
Arabic UX writing for Dubai products is not a translation job done at the end. Arabic text changes length, direction and grammar, and the interface has to allow for all three.
If a string only works in English, it is not finished.
Deliverable
In UX writing for Dubai products, words are only useful if developers can find, place and maintain them.
How the product talks, plus a glossary so “booking”, “reservation” and “appointment” are not used for the same thing.
Every string with a key, English and Arabic text, plural forms, limits and a context note.
Screenshots or prototype frames showing where each string appears.
We read the strings in a test build, in both directions, and log anything truncated or reordered.
For building the app itself, see mobile app development. Marketing pages around the product are covered by website content writing, and store listing text by product description writing. All writing services are on the copywriting services hub.
From the blog
Straight answers
Design decides the flow, layout and components. UX writing decides the words inside them. The two work best together, so we write against wireframes or prototypes rather than after screens are finished.
Yes. We start with an audit of the current screens and strings, list the problems by severity, and rewrite in priority order. Screenshots or a test build are more useful than a spreadsheet of strings alone, because context changes what a word means.
In a shared spreadsheet or the format your team uses, with a key for each string, English and Arabic columns, a character limit where the layout has one, and a context note. That note is what stops a translator or developer guessing.
No. Words are one part of accessibility; colour contrast, focus order, screen reader behaviour and many other factors are design and development work. Clear labels, instructions and error messages fix real barriers, but they need a full accessibility review to go with them.
Sources
Fixed price, in writing
Got it. Your quote is being written now.
In business hours you will have it within 45 minutes. Check your inbox for the confirmation.
