UI/UX design · UAE, Saudi Arabia and the Gulf

Interfaces People Actually Understand

Research-led user experience and interface design for Gulf businesses. We find the screens that lose people, fix those, and leave the rest alone.

2–3 wks

a UX audit, end to end

From the day access arrives, not the day you sign

4–5

screens is usually the job

A few screens corrected, not a redesign

2 directions, drawn together

Arabic and English side by side, not mirrored at the end

Istanbul

where we actually sit

No Gulf office, no local landline, and we say so

What this page argues

Key takeaways

A change not tied to a number, a recording or an observed failure is a preference, not an improvement.
Most products do not need a redesign. Four or five screens carry the problem; rebuilding the rest destroys what already works.
An audit is worth buying when you have traffic and a specific complaint. With neither, it produces opinions you can get free.
Arabic is not a translation layer. Navigation, icons, progress and alignment mirror; retrofitting that breaks bilingual products.
Research sometimes contradicts a decision already taken. We put that in writing, then build what you decide.
Your own developers are the audience: files, specifications, a component list, no dependency on us.

What is on this page

Good design is measured, not admired

Most design pages in this region open with awards and a sentence about craft. None of it tells you whether the product works.

We treat an interface as a machine with measurable outputs. A form is completed or abandoned. A search returns something people click, or it does not. A checkout holds people to the end, or loses them at one step that has a name. When we propose a change we can say which number it should move; when we cannot, it goes to the bottom of the list rather than into the invoice.

Measurement usually concludes the visual design is fine and the real problem is a label, a required field, a price three screens too late, or an error arriving after the user has lost everything they typed. Those fixes photograph badly. They move enquiry volume.

The same logic decides what we leave alone: if a page converts and we cannot explain why, we do not touch it. The first question on a call is not what the site should look like, but what it should do and how you will know. If the platform is the problem rather than the experience, that is web design work.

What UI/UX design covers here

Six kinds of work. Most engagements use two or three.

UX audit

The two or three journeys carrying your revenue, reviewed against evidence. Findings ranked by cost, each with its recording or number attached.

Interface design

Screens with every state: empty, loading, error, success, and an Arabic string longer than the English one.

Bilingual interface design

Arabic and English in one file at one time. Mirrored navigation and icons, typography legible in both scripts, a written specification.

Usability testing

Task-based sessions with people who resemble your customers. Five people failing the same task tells you more than a survey of five hundred.

Conversion work on live pages

Forms, pricing steps, enquiry routes, search. Narrow, cheap and measurable, and where we start when the complaint is specific.

Design system and handover

Component inventory, named tokens and interaction notes, so the next twenty screens your team builds match ours.

What a UX audit actually produces

An audit is a set of documents, not a meeting. If an agency will not give you this list before you pay, ask what you are buying.

Deliverable	What is in it	Who uses it
Ranked findings list	Each issue on an annotated screen, with its evidence, severity, effort and the number it moves	You and whoever signs off budget
Flow maps, drop-off marked	The journeys that matter, step by step, with the step where sessions stop	Product owner and marketing
Session recording clips	Cut to the moment of failure, so findings are watched rather than argued about	Anyone who doubts a finding
Redesigned priority screens	The four or five we recommend changing, both languages, all states	Developers
Copy and label corrections	Wording for buttons, labels, errors and empty states, both languages	Developers and content owner
Measurement plan	Which events to fire, their names, and what the numbers should show after	Analytics owner, and you at review
List of things not to change	Parts that test well and should be left alone, with the reason	Whoever inherits the project

The last row is the one clients remember. An audit recommending changes everywhere has not been done properly, because no real product is uniformly broken, and naming what works protects it from the next person with an opinion. Nor do we issue a score out of ten: it hides the only useful information, which is what to do next.

When an audit is not worth buying

An audit is a diagnostic, and diagnostics need symptoms and data. Five situations where we tell people not to buy one.

Very little traffic. Below a few hundred relevant sessions a month, recordings show three people rather than a pattern. You would be buying our opinion dressed as research.
You already know what is broken. If every caller asks the same question because the answer is nowhere on the site, fix that page first.
The budget only covers the audit. A report you cannot afford to act on is the most expensive document in marketing.
You are replatforming soon. Audit the new product before it ships, while changes are cheap.
The decision is already made. If the redesign is approved and dated, an audit only justifies it. We would rather not be paid for that.

The same reasoning applies to paid search, where too little budget means building content first. The inverse repays the fee several times over: real traffic, a repeated complaint, and money left to act. If that is you, tell us the complaint.

Where a flow loses people

A worked example, not a client’s data. The step where sessions stop is a fact you can locate.

The fall between reading a price and sending an enquiry is where most Gulf lead-generation sites lose money.

Most sites cannot draw this diagram, because only the submission fires an event and everything before it is a black box. Fixing that is often the first thing we deliver, and it is cheap. Once each step reports, you stop debating whether the page looks trustworthy and see which field people stop on.

Symptom, cause, what to check

The failures we find most often in Gulf products, and what to look at. You can run most of the right-hand column yourself.

Symptom	Likely cause	What to check
Forms started, then abandoned	Too many required fields, or one nobody can answer honestly: trade licence number, full address	Field-level drop-off, and which field has focus when the recording ends
Site search barely used, or abandoned	Hidden behind an icon on mobile; or zero results for Arabic spelling variants, plurals and the brand names customers type	Search events against page views, and the zero-result query log in both languages
People leave at the price step	Price arrives later than expected, is shown without VAT, or is in the wrong currency	Where price first appears, whether VAT is stated, currency against visitor country
Arabic pages read less than English	Machine-translated Arabic, or a layout never mirrored, so it reads as translated English	Engagement time and scroll depth per language, and whether hreflang points both ways
Mobile traffic, few mobile enquiries	Small tap targets, a phone field rejecting the +971 or +966 prefix, a form needing two hands	Conversion and form errors by device, and the form on a real phone
Enquiries arrive unqualified	The form asks nothing that qualifies, or the page attracts the wrong search intent	The first question on the form, and which queries those enquiries came from

Notice how few of these are visual. In six rows, one is about layout. The rest are information, wording, instrumentation and assumptions carried over from a Western template, which is why a redesign brief often ends as a content and forms project. Where hreflang is the cause, the answer is SEO work first.

The research we actually do

Research is the word agencies use most loosely. Here is exactly what we do, so you can judge whether it is enough for your problem.

Analytics review. Flows, step-level drop-off, device and language splits, and whether the existing events answer the question. Often they cannot, and that is finding number one.
Session recordings. The fastest way to see what no chart shows, such as someone tapping a heading that looks like a button.
Task-based testing. A few people, each given one job: find the price, book an appointment, finish the checkout in Arabic. We watch, we do not help, we record where they stop.
Support messages and WhatsApp threads. The most underused source in the Gulf. Every repeated question is a missing page or a misread label.
Stakeholder interviews. Sales, and whoever answers the phone. They know which objections come up in what order, which is the content hierarchy you need.
Competitor teardown, to answer a question. Useful for what your market treats as standard, useless as a source of ideas, because their design is not evidence either.

What we do not do: eye-tracking labs, recruited panels, or studies needing a statistician. We are a small studio in Istanbul and pretending otherwise would be a lie you could check. Nor is research presented as neutral: every finding carries a confidence level, because some can be watched and others only inferred.

One screen, two directions

The same screen in English and Arabic. Four things flip; the ones teams forget are the arrows and the progress indicator.

Mirroring is structural. A right-to-left stylesheet bolted on at the end reverses the text and leaves the layout in English.

We draw both versions in one file, on adjacent frames, from the first screen. It costs very little then and a great deal later, once components carry hard-coded left and right values.

Designing for two directions at once

Almost every Gulf product we look at is bilingual, and almost every one was designed in English and translated afterwards. That order causes most of what goes wrong.

What mirrors: the navigation bar and its menu order, breadcrumbs, back and next controls, progress indicators and step numbers, carousel direction, table column order, label alignment, the side a sidebar sits on, and any directional icon.

What does not mirror, and gets broken by teams who mirror everything: digits, prices, numeric dates, telephone numbers, email addresses, URLs, code, media controls and logos.

Then typography, where bilingual products look cheap even when the layout is right. Arabic needs more line height than Latin text at the same size, and usually a slightly larger size to read as comfortably. It has no capital letters, so all-caps labels have no Arabic equivalent, and a button sized to its English label will break.

The failure in the code is specific. If the stylesheet sets direction: rtl but components use margin-left, text-align: left and left-positioned absolutes, the text reverses and the layout does not. The fix is logical properties: margin-inline-start, padding-inline-end, text-align: start. Given early, that prevents most right-to-left bugs we are called in to diagnose.

Two more details. Icons containing text or numerals need separate Arabic assets rather than a transform, because a mirrored glyph is unreadable. And the two versions must reference each other correctly: Google’s guidance on localised versions sets out the reciprocal annotations, and getting them wrong is why one language is invisible in search on half the sites we audit. The same principles at scale, on a multilingual property platform.

How an engagement runs

01 Scoping call and access

Half an hour: the complaint, the buyer, and what a good month looks like in numbers. Then read-only analytics, session recording, and a staging URL.

02 Audit

Two to three weeks from the day access works. We watch sessions, read support messages, run the tasks in both languages, and test on real devices.

03 Findings and argument

One meeting. We present the ranked list and argue for a short one. You decide. Where we disagree, that goes into the document with its evidence.

04 Design of the priority screens

English and Arabic drawn together, every state included, real copy rather than placeholder text. One screen approved before we draw the rest.

05 Handover and re-measurement

Files, specification, component list and measurement plan go to whoever is building. We fix a date six to eight weeks after launch to read the numbers.

What we hand over

Design work your developers cannot implement is decoration. If you are commissioning design separately from build, take this table to them and ask if it is enough.

Format	What it contains	What your developers do with it
Figma file, one page per screen	Every screen with all its states, and a long Arabic string in each slot	Inspect spacing, type and colour in the file. It is the source of truth, not a PDF
Component inventory	Every button, input, card, table and modal used, named, with variants	Map each to an existing component, then build the missing ones once
Design tokens list	Colours, type scale, spacing and radii as named values, not scattered hex codes	Put them in CSS custom properties, or your framework theme file
Interaction notes per screen	What happens on tap, on validation failure, on a slow connection, on back	Implement behaviour without guessing. Unstated states cause most bug reports
Right-to-left specification	Which properties must be logical, which assets mirror, which must not, Arabic type settings	Swap left and right for inline-start and inline-end, then check icons and media controls
Copy sheet, English and Arabic	Final strings for labels, buttons, errors, empty states and confirmations	Paste into the translation files. Never retype Arabic; it adds invisible errors
Measurement plan	The events to fire, their names and parameters, and which question each answers	Add them before launch, so the review in two months has data to read
Accessibility notes	Contrast results, focus order, target sizes, how each field is labelled	Fix in the markup; most are attributes, not visual changes

The handover is written for a developer who has never spoken to us: specifications in text, decisions recorded rather than remembered. If you would rather we built it too, our published prices cover that route and store builds follow the same pattern.

Why we will not redesign everything

The easiest proposal to write is a full redesign: largest number, cleanest story, least accountable outcome, because when everything changes nobody can say what helped.

A live product contains knowledge nobody documented. Odd arrangements are often the residue of a real problem someone solved years ago. A clean sheet rediscovers them one support ticket at a time.

It destroys your baseline. Change forty screens at once and the numbers afterwards mean nothing. Change four and you know which worked.

The risk is not confined to design. A rebuild means new bugs, staff retraining, and search damage if URLs move without a redirect map. Recovery takes weeks even when handled well.

There are real cases for a rebuild and we say so when we see one: the platform caps what you can do, the codebase cannot render Arabic, the information architecture is wrong at the root, or nobody employed can maintain the site. Those are structural, and patching costs more than replacing. The starting point is then a new build with the audit findings as its brief, and the cost pages for Dubai and Saudi Arabia give the ranges.

We have talked clients out of redesigns they arrived asking for. It is a smaller invoice, and the main reason they come back.

What we measure, and what we ignore

The measurement plan, both halves

Measured: task completion rate, step-level drop-off, error rate per field, zero-result search rate, conversion by language and device, and enquiry quality as your sales team counts it.
Ignored: time on page, because longer often means confused; bounce rate alone, because a visitor who found the phone number and left has succeeded; composite engagement scores, which cannot be acted on; and heatmaps as evidence, because they fit any story.
No uplift percentage is promised before the work. Any figure offered at proposal stage is invented, whatever competitors quote.
Speed is the exception, because public thresholds exist: Google publishes them for largest contentful paint and interaction responsiveness.
Where measurement crosses into channels it belongs with the wider marketing work, on one definition of a conversion.

“If a design change cannot name the number it is meant to move, it is a preference. Preferences are free. We charge for evidence.”
How we decide what goes in a proposal

Design questions

What is the difference between UI and UX?

UX decides what the screens are, what order they come in and what each asks for. UI is how they look and behave: type, colour, spacing, states, components. Good UI with bad UX is the common case: a beautiful form nobody completes.

Can you design native Arabic interfaces?

Yes, designed alongside English from the first screen rather than mirrored at the end. Navigation, icons, progress direction, alignment and Arabic typography are settled in the original file, and the handover includes a right-to-left specification. Interface copy is never machine translated.

Can you work with our existing developers?

That is most of our design work. You get a Figma file with every state drawn, a component inventory, named tokens, interaction notes, a bilingual copy sheet and a measurement plan, all written for a developer who has never met us.

Do you redesign existing products?

Yes, and it almost always starts as an audit, because we cannot know which screens deserve the budget until we have looked. The work is staged: priority screens first, measured, then the next set.

How long does a UX audit take?

Two to three weeks, counted from the day analytics and product access actually work rather than the day the contract is signed. Access is the step that slips; arrange it early and the schedule holds.

Do you need access to our analytics?

It makes the work far sharper: read-only analytics plus session recording turns opinions into observations and lets us rank findings by cost. We can work without it, using task-based testing, but the findings are weaker and the report says so.

Will you redesign everything?

Usually not. Most products gain more from correcting four or five screens, and a full redesign destroys the baseline you need to tell whether anything improved. We recommend a rebuild only when the platform caps you, the codebase cannot handle Arabic, or the architecture is wrong at the root.

When is a UX audit not worth buying?

When traffic is very low, because a few hundred sessions a month show three people rather than a pattern. When you already know what is broken, in which case fix it. When the budget covers the audit but not the changes, because an unactioned report is the most expensive document you can own. When you are replatforming. And when the decision is already taken.

What happens if the research contradicts what we have already decided?

We tell you in writing, with the evidence attached, before design work starts. Then you decide, because it is your business and your money, and we build what you decide. What we will not do is quietly produce the thing we believe is wrong and let the numbers make the argument later. Fundamental disagreements go on record.

Do you hand over design files or working code?

Either. If you have developers, we hand over the files and specification above and stay available during the build. If not, we design and build, and the documents still exist as your record.

What does UI/UX work cost?

A fixed fee, quoted in writing once we know the screen count and whether both languages are included. As part of a full build it sits inside our published packages, from AED 4,700 in the UAE, SAR 4,800 in Saudi Arabia, QAR 4,700 in Qatar and KWD 395 in Kuwait. We do not bill hourly.

Do you have an office in the UAE or Saudi Arabia?

No. We are a studio in Istanbul with no Gulf office, address or landline, and will not pretend otherwise on a page arguing for honest measurement. We work Gulf hours, run calls and testing remotely, and everything stays in your name.

Can you test with Gulf users, or is it all desk research?

We run remote task-based sessions with participants in the market, in Arabic or English. We do not operate a lab or a recruited panel, so samples are small: five or six per task, chosen to resemble your buyers. They find failures reliably but produce no percentages.

Who owns the design files afterwards?

You do, from the start. The Figma file, tokens, copy sheet and specification are yours, transferred to your account at handover, and you can take them elsewhere. We have inherited too many projects where the last agency held the files hostage.

Let us look at your experience

Tell us what people are failing to do on your site. We will say whether there is anything worth auditing, and if not, we will say that instead.