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.
UI UX design · UAE
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 teardownWhat UI and UX design is
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.
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.
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 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
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 taste | DesignedResearched, tested, specified | |
|---|---|---|
| Where it starts | A reference the team liked, redrawn for your brand. | A recorded session with somebody who has the job to do. |
| What a screen is | The success state, drawn once and drawn well. | A set of states, including every one that fails. |
| How it is validated | A 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 gets | Images, and a conversation about what happens next. | A spec that states behaviour, not only measurements. |
| What it is judged on | How the screens look in the review. | Whether the person finished, and where they hesitated. |
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
Webzenia has worked with Gulf clients since 2018. Three things decide completion on a UAE product, and none of them is visual.
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.
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.
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.
How we design
Three stages, each ending in something the next one cannot start without.
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.
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.
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.
What you walk away with
Every engagement hands over a working component library and the evidence behind it.
What the engagement includes
Six pieces of work, each ending in an artefact your team can review and build from.
Moderated sessions with people who genuinely match your user, run in Arabic or English
a brief that names the job and the point where it breaks
What sits where, and the route from intent to done, including the steps another party owns
a flow map with every handoff marked
Low-fidelity screens that settle the structure while changing it still costs an afternoon
wireframes signed off before any styling
Pixel-final design for every state a component can be in, rejected, pending and expired included
production-ready UI with nothing left implied
A clickable flow put in front of participants who match your user, recorded
a validated prototype and the sessions behind it
Components, variants, and the rules that decide which state shows, documented for the people who will build them
a component library
Ways to work with us
The price is scoped on the call. These three are the relationships we run; pick the one that matches your question.
Best for a defined product or flow with a date already attached to it.
Best for continuous product work that needs a designer inside the team.
Best for steady iteration on a product that is already live.
Our stack
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 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.
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.
Before you commit
Send us one flow people drop out of. We will record where it loses them and the three fixes we would make first.
2 business days · no obligation
A **free UX teardown** of one live flow
Our commitment
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
Keep exploring
A design system drawn for both reading directions, not screens.
Builds sequenced around the approvals the launch date waits on.
Stores wired for the payment set, the courier and the invoice.
The plan decides more than the theme. We settle that first.
A store you own outright, with the running cost priced first.
Built for the two people who have to publish it, in both scripts.
For content that has to reach more than one surface.
The origin, the scripts and the consent layer, not the network.
Diagnosis first, and a test only where the traffic carries one.
Next step
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.