UI UX design · UAE

UI and UX design people can use first time.

Most products here lose people at a state nobody designed: a rejected document, a pending review, a name the field will not take. Webzenia designs every state on the path, then tests it.

Get a free UX teardown

What UI and UX design is

What UI and UX design settles first.

UX is the path and what the product does at every point on it; UI is how that path is drawn. Both are settled in grey boxes, before styling.

Continue01Understand02Flow03Feel

The job to be done.

The task the person opened the product to finish, established from recorded sessions rather than agreed in a workshop. Most abandoned flows answer a slightly different job from the one the person arrived with, and styling never closes that gap.

The path and its states.

Every step, and what the product shows at each one: empty, loading, partial, rejected, expired, done. The states nobody briefs are where completion is lost, so they are drawn in grey boxes before anything is styled.

The handoffs.

The points where your product stops and something else takes over: an identity check, a compliance review, a payment, a second script. A handoff is an interface too, and it is the part a screen inventory always misses.

Two ways a product gets designed

Designed to be used.

Both arrive as a design file and a set of screens. What separates them is where the decisions came from, and who tried them.

DecoratedSettled on tasteDesignedResearched, tested, specified
Where it startsA reference the team liked, redrawn for your brand.A recorded session with somebody who has the job to do.
What a screen isThe success state, drawn once and drawn well.A set of states, including every one that fails.
How it is validatedA review meeting, where the most senior view wins.Five moderated sessions with people who match the buyer. A panel of 200 is unrecruitable here.
What engineering getsImages, and a conversation about what happens next.A spec that states behaviour, not only measurements.
What it is judged onHow the screens look in the review.Whether the person finished, and where they hesitated.
Which one you are buying.

Many products here started as a marketing site that grew a login, so the first question is which of the two you are designing. Where it is the public site, the work sits at website design, and the build behind it on website design and development. Where it is a phone-first product, the same sessions run against mobile app development. Where the product is live and losing people, we would rather record a session than argue a layout.

The UAE context

What decides whether people finish.

Webzenia has worked with Gulf clients since 2018. Three things decide completion on a UAE product, and none of them is visual.

  1. 01of 03
    The states nobody briefsWhere completion is lost

    Most steps end rejected or pending.

    An uploaded trade licence comes back unreadable, a review sits at pending for two days, a one-time code expires while the person hunts for their phone. A Business Bay brokerage on a DET mainland licence never designed those screens, so the product falls back to a blank panel and the person leaves.

    Our methodEvery step on the path is specified in its empty, loading, partial, rejected and success states before any of it is styled.
  2. 02of 03
    The screens you do not ownIdentity, compliance, payment

    Some screens belong to UAE PASS.

    On a DIFC-registered fund's investor portal, several onboarding screens are written by compliance rather than by product, and UAE PASS hands the person back mid-flow with a session to restore. Those seams are where people drop, and redrawing the screens on either side does not move them.

    Our methodThe flow is mapped end to end, including the steps another party owns, what returns from each one, and how long it takes.
  3. 03of 03
    A sample you can recruitThe method this market allows

    Your real users number a few hundred.

    That rules out the panel study and rules in five moderated sessions with the right five people, run in Arabic or English as the participant prefers. A Hub71 SaaS company on an ADGM licence buys the five, because a panel this market cannot supply becomes a document.

    Our methodSample size, recruitment source and language are written into the scope before the research starts.

How we design

From a recording to a spec.

Three stages, each ending in something the next one cannot start without.

01 / 03Stage 01 · Research and structure

Run the sessions.

We watch people attempt the job on whatever exists today, in Arabic or English, then map the path and every state on it. The structure is agreed in low fidelity, where changing it costs an afternoon rather than a sprint.

5peoplemoderated before any screen is styled
02 / 03Stage 02 · Interface and prototype

Draw every state.

Screens are drawn for the whole state set rather than the success path alone, then assembled into a prototype people can operate. The handoffs to identity, compliance and payment are prototyped as part of the flow, not left as a gap.

0linesof code until the prototype has been tested
03 / 03Stage 03 · Specification and handover

Write the behaviour down.

The spec states what each component does in each state, what happens when a step fails, and what returns from a party you do not control. The working file and the component library go across with it.

1component library your team owns and builds on

What you walk away with

Files engineering can build from.

Every engagement hands over a working component library and the evidence behind it.

flows-and-a-state-map.fig
123USER FLOW3 screens · 1 happy pathAanyaAudience+ InviteAACTIVE USERS18,204+12.4%CONVERSION3.8%+0.6ptCHURN1.2%−0.3ptSignupsLast 30 daysGoal reachedSignups +18% this weekContinueFlow · LiveDesign systemv2.0128 tokensCOLOUR#3D7EFF#2D63E6Ink/50SuccessWarningTYPE SCALEAaDisplay / 32 · 500Lumen + Rawi ArabicAaHeading / 18AaBody / 14COMPONENTSBook a callBook a callyou@company.comShippedButton / Primaryradius 8 · pad 16color brand/60074r:14DevButton.tsxCopy CSS

What the engagement includes

The UX scope.

Six pieces of work, each ending in an artefact your team can review and build from.

Usability testing8 usersTask success92%Time on task48sError rate4%Issues foundFilter hidden below the foldhighPrimary CTA reads as secondarymeda research brief that points the design, from real testing

Research sized to this market.

Moderated sessions with people who genuinely match your user, run in Arabic or English

Output

a brief that names the job and the point where it breaks

ModeratedArabic or English
User flowmappedBrowseLogged in?CheckoutyesSign upnowhat goes where, and how a user gets from intent to done

Flows and structure.

What sits where, and the route from intent to done, including the steps another party owns

Output

a flow map with every handoff marked

FlowsHandoffs
WireframesapprovedScreen 1Screen 2Screen 3agree the structure cheaply, before any visual design

Wireframes.

Low-fidelity screens that settle the structure while changing it still costs an afternoon

Output

wireframes signed off before any styling

Lo-fi
UI statesevery stateButtonActionDefaultActionHoverActionFocusActionDisabledInputEmailDefaultInvalid emailErrorevery screen and every state, pixel-final and on-brand

UI, with every state drawn.

Pixel-final design for every state a component can be in, rejected, pending and expired included

Output

production-ready UI with nothing left implied

States
PrototypevalidatedTested with 8 users92%decisions proven with real users, not guessed

Prototypes tested on people.

A clickable flow put in front of participants who match your user, recorded

Output

a validated prototype and the sessions behind it

PrototypeSessions
Component librarydocumentedComponents · variantsButton4 variantsInput3 variantsCard2 variantsModal2 variantsNav3 variantsTable2 variantstokens, components and docs your team builds and scales from

A design system.

Components, variants, and the rules that decide which state shows, documented for the people who will build them

Output

a component library

ComponentsDocumented

Ways to work with us

Three shapes, and which fits.

The price is scoped on the call. These three are the relationships we run; pick the one that matches your question.

Project

Best for a defined product or flow with a date already attached to it.

Fixed scope, fixed price
A named designer and a lead
Research, wireframes, UI, prototype
Component library and spec at handover
Most chosen

Embedded designer

Best for continuous product work that needs a designer inside the team.

One designer, full time on your product
In your standups and your tools
Shipping continuously rather than in phases
Monthly, on a Monday to Friday week

Design retainer

Best for steady iteration on a product that is already live.

A block of design hours each month
Flexible across web, app and internal tools
Research and interface work in the same block
Unused hours roll within the month

Our stack

The tools we research with.

The kit behind a flow a first-time user can finish. Select one to see what we do with it that most do not.

Figma
Why Figma

Figma holds variants and interactive components, which is the only practical way to draw a screen as a set of states rather than as one picture of the good outcome.

How we excel

We build every component with its empty, loading, rejected and success variants in one library, so a state nobody designed shows up as a gap instead of being discovered by a developer at build time.

Component statesPrototype logicHandoff
FigmaDev mode
SketchInspect
Adobe XDShare link
PenpotInspect

Before you commit

A free UX teardown of one live flow

Send us one flow people drop out of. We will record where it loses them and the three fixes we would make first.

A recorded walkthrough of your real screens, not a sample
The steps and states where people stop, ranked
Three fixes we would ship first, yours to keep

2 business days · no obligation

A **free UX teardown** of one live flow

+971

Our commitment

Our promises on the research.

Design is the easiest deliverable to accept on taste. These four are what we ask to be held to.

  • Every screen gets its failure state.

    Every component is delivered with what it does when an upload is rejected, a review is pending and a session returns from somewhere else. A flow that only draws success is not finished.

  • The sample is named up front.

    You are told how many participants, recruited from where, in which language, before anything starts. Where people who genuinely match your user cannot be recruited, we change the method rather than the label on it.

  • Tested before it is engineered.

    The prototype goes in front of participants who match your user while changing it still costs an afternoon, and you get the recordings rather than a summary of them.

  • Reported on who finished.

    Work is measured against task completion and the step people stopped at, on the flow we changed. That is a number your own analytics can check without us.

A flow is finished when a stranger completes it without help.

Common questions

UI and UX design in the UAE, answered

Next step

See where people stop.

Send us one live flow. We will record a walkthrough of where it loses people and the three fixes we would make first.

Tell us what you need.

+971
Chat on WhatsApp