Zenowebzenweb

Dubai · Web Design

UI/UX design services in Dubai — drawn to be built, not admired.

Research and a signed-off sitemap come first; the interface follows from what they settle. What you hold at the end is a Figma library with every state drawn, a clickable prototype of the key journeys, and the type, spacing and colour tokens behind both.

  • Components with every state
  • Editable source, not exports
  • Arabic drawn, not translated

What's included

Six things a UI/UX engagement actually produces.

Not a list of activities — a list of artefacts you can open, review and hand to someone else.

  • User and stakeholder research

    Interviews with the people who will use the product and the people who will maintain it, plus a read of whatever analytics and support history already exist. Short, and aimed at the two or three decisions that would be expensive to get wrong.

  • Information architecture

    The sitemap, the navigation model and the content structure, agreed before layout. It is what defines a page on your site — which sections it can hold, which of them are optional, and what the CMS has to store for each one.

  • Wireframes

    Greyscale layouts for every key template, drawn with real content rather than lorem — the longest product name, the eight-word heading, the list with nothing in it yet. A layout that only holds at ideal content lengths is not finished.

  • Interface design in Figma

    The visual design, drawn as reusable components with their states — hover, focus, empty, loading, error. Any one screen shows only one of those, which is why the states live on the component rather than in a note beside it.

  • A clickable prototype

    The key journeys wired together — not every screen, but every path somebody has to finish. It is where a flow that reads well on a static screen turns out not to work, which is worth knowing while it is still a file.

  • Accessibility decided in the file

    Contrast measured against the colour tokens themselves rather than checked on a finished page, focus order annotated on the frames it applies to, and target sizes set inside the components so they hold everywhere the component is used.

Who it's for

Three situations this fits — and one it doesn't.

If none of these describe you, the honest answer is usually a smaller piece of work, and we would rather say so before a proposal than after one.

  • A product that grew without a plan

    Features were added one at a time and the navigation now reflects the order they shipped rather than how anyone uses them. The interface is not the problem; the structure underneath it is, and that is what the architecture phase exists to fix.

    Your own team hesitates when asked where something lives.

  • A build that needs a design system

    Developers are being handed static screens and inventing the gaps — spacing, states, breakpoints, what an empty table looks like. A component library removes the guessing, and removes the arguments in code review that follow from it.

    The same component looks different on three pages.

  • A design team without capacity

    You have an in-house designer who cannot cover a full product, and you need a phase resourced without hiring for it. What comes back is one library rather than a second set of screens to reconcile — components, tokens and states your designer carries on working in.

    You need the file, not the build.

How we deliver it

Five stages, from a sitemap to a signed-off library.

Every stage ends in something reviewable. Nothing runs longer than it can be checked.

  1. 01

    Research and audit

    Interviews, an analytics read and a walkthrough of the current product or its closest competitor. Ends with the two or three problems worth designing around, written down and agreed.

  2. 02

    Architecture

    Sitemap, navigation model and content structure, taken far enough that every page has a named purpose and a list of what somebody has to write for it. On a typical marketing site this lands in week one.

  3. 03

    Wireframes

    Greyscale templates reviewed in one pass rather than page by page, because a navigation decision only reads properly when you can see every page it has to serve. What is signed off here is the skeleton the visual design is drawn onto.

  4. 04

    Interface design

    Visual design in Figma, built as components with their states rather than as screens. Runs roughly week two to week four on a six-week marketing site.

  5. 05

    Prototype and handover

    Key journeys wired into a clickable prototype, then a recorded walkthrough with whoever will write the code — components first, then the tokens, then the states a screenshot never shows.

Deliverables

What you receive, and what you can do with it.

Everything below is yours from day one rather than at final invoice, and it is all in your account rather than ours.

  • A Figma file organised as a component library, with states and every breakpoint that matters
  • A clickable prototype of the key journeys
  • The sitemap and content structure, as a document rather than a diagram nobody can edit
  • Wireframes for every key template, kept alongside the final design
  • Design tokens — type scale, spacing scale, colour with measured contrast ratios
  • A recorded build walkthrough for the engineers who will implement it
  • Editable source files, not exports

The file is written to be picked up by a developer who has never spoken to us: components named the way they will be named in code, states drawn rather than described in a comment, and nothing that only makes sense if you sat in the review. That is the only real test of whether a design system is finished.

Pricing

What a UI/UX engagement costs.

Quoted per engagement

fixed price

Design on its own sits outside the published tiers on purpose: the price follows how many screens and how many states have to be drawn, and a page count predicts neither. Empty, loading and error states are a large share of the drawing on a product and a small one on a brochure site, and Arabic drawn as a second layout rather than a translated one is a further pass through the same file. So it is quoted per engagement and fixed before anything starts. The tiers are the reference point for design and build together — AED 16,000 for a five-to-eight page site, moving to the Growth tier from AED 48,000 once the screen set, the state count or a second language outgrows it. Prices exclude 5% VAT.

What changes the price

What that covers

  • Research and stakeholder interviews
  • Sitemap and content structure
  • Wireframes for every key template
  • Interface design as a Figma component library
  • A clickable prototype
  • Accessibility decided in the file, not after the build
  • Hospitality and F&B

    The whole interface is judged one-handed, on a phone, by someone standing up. Menu structure, booking flow and photography weight matter more than anything that happens at desktop width, and the design has to hold up in a bright room.

  • Professional services

    The interface carries credibility rather than transactions. Structure does most of the work — how a service is explained, how a case study is reached, how quickly someone can tell whether they are in the right place before they ever look at a contact form.

Questions

Asked before a UI/UX engagement starts.

UX is the structure — what exists, where it sits, and what order someone moves through it. UI is the surface that structure is expressed in: type, colour, spacing, states. They are separate phases here because deciding both at once is how projects end up arguing about a button colour when the real problem is that a step is in the wrong place.

Design on its own is quoted per engagement rather than off the tier list, because the price follows the screen count and the state count rather than the page count. A brochure site and a product can share a page count and be very different amounts of drawing once every state is counted. The tiers are the reference point for design and build together: AED 16,000 for a five-to-eight page site, and from AED 48,000 once the screen set or a second language outgrows it. All prices exclude 5% VAT.

Figma, and yes — the file sits in your account from day one rather than being handed over at final invoice. That matters more than it sounds: a design file you do not control is a dependency on the agency that drew it, and it is one of the quieter reasons a company cannot move to another developer without starting again.

Key templates in full, and then the components everything else is assembled from. A product with sixty screens does not need sixty drawings; it needs the templates drawn properly and a library complete enough that the sixty-first is assembled rather than commissioned. Anything genuinely one-off — an onboarding step, an unusual empty state — is drawn on its own. What is never left out is the state coverage, because that is where a screen count and a drawing count stop matching.

The number of states, not the number of pages. A marketing page needs a default and its breakpoints; one dashboard table needs empty, loading, error, filtered, one row and two thousand rows — and each of those is a drawing somebody has to make and somebody has to review. Arabic means drawing the same components again, mirrored and on a second type scale, rather than adding a translation pass over the first set. Page count predicts almost none of it.

Research, but proportionate. On a marketing site that means stakeholder interviews, an analytics read and a competitor walkthrough — enough to settle the two or three decisions that would be expensive to get wrong. On a product it extends to interviews with actual users. What we do not do is run a research phase whose findings nobody intends to act on.

As three decisions inside the file rather than as a language setting laid over it. The type scale is set on an Arabic face chosen for the work, so line height and optical size are read off real Arabic rather than off a fallback standing in for it. Mirroring is a component property, so a component ships in both directions and stays one component. And the wireframes are reviewed in both directions, because a layout that only reads correctly in English is a structural problem rather than a styling one.

No fixed number: the file is reviewed in three passes, and each catches a different kind of change. Wireframes are reviewed as a set, where a change means moving a block. Components are reviewed one at a time, and one is only signed off once its states are drawn — which is why a comment on a screen becomes one change to one component rather than five edits across five pages. The prototype is the last pass, and it catches what only appears in sequence.

Ready to build something that lasts?

Tell us what you need. You will get a scoped response with an indicative price — from an engineer, not a salesperson.

No obligation. We reply within one working day, Monday to Friday.