A new app gets about three seconds to feel like it belongs on a UAE phone, next to Careem, Noon, and Emirates. Designing for that bar is what this page is about. Plexi works in Figma, builds every screen in Arabic and English in parallel from the first wireframe, and hands engineering a specification precise enough to build from without a single clarifying question. The focus here is the design phase on its own — the flows, the visual system, and the platform craft — not the full build, which the mobile app development pillar covers end to end.
Why app design is its own discipline
Give a web designer a mobile app brief and the screens usually look fine and behave wrong: primary actions parked out of thumb reach, navigation that fights the OS back gesture, tap targets below the platform minimum, and contrast that fails accessibility on a phone held outdoors in UAE sun. App design runs on conventions that differ from web, differ again between iOS and Android, and are complicated further here by designing for two reading directions at once.
The split people underestimate is UI versus UX. UX is the skeleton — the flows, the screen order, the state a user is in and what they can do next. UI is the skin — type, colour, spacing, iconography, motion. A gorgeous UI laid over a broken flow still fails, and a clean flow rendered with a careless UI still forfeits trust in the first three seconds. For the fintech and government-adjacent apps that are common in Dubai, those three seconds decide whether a user believes their money and identity are safe. Both layers have to be right, and they have to be designed in that order.
iOS and Android speak different design languages
The single most common tell of an outsourced or web-first design is one layout stretched identically across both platforms. iOS users and Android users have been trained by their operating systems to expect different things in the same situations, and honouring those expectations is most of what “feels native” actually means. We design platform variants wherever the convention diverges meaningfully, and keep them unified where it does not. The table below is the working reference we design against.
| Design element | iOS — Human Interface Guidelines | Android — Material Design 3 |
|---|---|---|
| Primary navigation | Tab bar pinned to the bottom edge | Navigation bar (bottom); navigation rail on tablets |
| Top bar | Large title that collapses to inline on scroll | Top app bar with small / medium / large variants |
| Minimum touch target | 44 × 44 pt | 48 × 48 dp |
| System icons | SF Symbols, weight-matched to adjacent text | Material Symbols, adjustable weight and fill |
| Secondary actions | Action sheet or bottom sheet | Bottom sheet with a drag handle |
| Back navigation | In-app back button plus edge-swipe; no system bar | System/gesture back always present — don’t duplicate it |
| Type system | San Francisco with Dynamic Type sizes | Material type scale on Roboto or your brand font |
| Asset densities | @1x / @2x / @3x | mdpi through xxxhdpi |
| Depth model | Translucent materials and subtle shadow | Tonal elevation layered with shadow |
None of this means designing two disconnected apps. It means one product identity — your colour, type, and voice — expressed through each platform’s native grammar. Where you ship a single Flutter codebase to both stores, these conventions still apply; the framework renders one design, so the design itself has to make deliberate calls about which platform’s patterns to honour. Our iOS design and build and Android pages go deeper on each platform’s engineering side.
Inside a Plexi app design engagement
User research and competitive audit
Before any wireframe, we map the journey against a real UAE audience — the mix of nationalities, languages, and digital-literacy levels, the dominant devices, and the polish bar set by the country’s most-used apps. We audit the two or three leading competitor apps in your category screen by screen and document what they get right and where they leave a gap you can take.
Information architecture and user flows
We define every screen, every state, and every navigation path before visual design starts. The output is a flow diagram that forces the awkward questions early — what happens when the user taps back here, what does this screen show with zero data, where does a failed payment land them. Answering these on a diagram costs minutes; discovering them mid-development costs a sprint.
Bilingual wireframes, designed twice rather than mirrored
Wireframes are produced in English (LTR) and Arabic (RTL) together. This is not a flip operation. Because the Arabic reading eye starts on the right, visual hierarchy has to be re-evaluated: an element that anchors comfortably on the left in English often needs to genuinely move, not merely mirror. Numbers, Latin brand names, and inline English inside Arabic text create bidirectional runs that we resolve at the wireframe stage, not after the UI is painted.
High-fidelity UI on a token-based design system
Visual design happens in Figma across every target screen size. Rather than styling screens one by one, we build a design system: primitive tokens (raw colour, spacing, radius, and shadow values), semantic tokens that map them to roles (surface, on-surface, primary, danger), and component variants assembled from those tokens. Change a brand colour once and it cascades through every screen and both light and dark modes. This is what keeps a fifty-screen app visually consistent and what makes future screens cheap to add. If you also run a website, these tokens travel — our web and UI/UX design team shares the same source of truth so the two products look like one brand.
Arabic typography and RTL, done properly
Selecting an Arabic typeface for a phone screen is not the print exercise. The face has to hold its shape and counters at small sizes on high-DPI displays, carry an optical weight that balances the Latin typeface used in the English build, and cover the full character set your content needs. Screen-optimised families such as IBM Plex Sans Arabic, Cairo, Tajawal, Almarai, and Noto Sans Arabic behave very differently from decorative or print faces, and we specify against real content, not lorem ipsum. Arabic text also runs longer or shorter than its English equivalent, so containers, buttons, and truncation rules are tested in both languages on real devices throughout — not only in Figma’s preview.
Every screen state, not just the happy path
Most weak app design shows only the populated, everything-worked screen. We design the full set: empty and zero-data states, loading (skeleton placeholders over spinners wherever the layout is known), error and validation states, offline and no-connection states, permission-request moments, and success confirmations. These states are where real users spend a surprising share of their time, and designing them upfront is what stops engineering from improvising them badly under deadline.
Motion and microinteractions
Motion is specified, not left to chance — tap feedback, screen transitions, sheet and modal presentation, pull-to-refresh, and loading choreography. Good microinteraction design does two jobs: it confirms the app heard the tap, and it masks latency so a network wait feels intentional rather than broken. We document timing, easing, and trigger for each so the built app moves the way the prototype promised.
Accessibility designed in, not audited after
Accessibility is a design input here, not a compliance pass bolted on at the end. We hold text contrast to WCAG’s 4.5:1 for body copy and 3:1 for large text and interactive components, respect platform Dynamic Type and font-scaling so layouts survive a user who bumps the system font size, keep every interactive element at or above the platform touch minimum, and label controls so VoiceOver and TalkBack read the screen sensibly. An app that only works at default settings for users with perfect eyesight is an app that quietly excludes paying customers.
Interactive prototype and usability review
We assemble the high-fidelity screens into a clickable Figma prototype and put it in front of representative users on real tasks. This surfaces the problems that no amount of internal review catches — the action people cannot find, the flow they abandon, the label that reads clearly to us and confuses them. Fixing it here is a design edit. Fixing it after the code exists is a change request with a cost attached.
Developer handoff that removes guesswork
The delivered file is structured for build: named layers, auto-layout components, shared style tokens, and a handoff frame per screen carrying spacing values, colour tokens, and type specs. Assets are exported at every density each platform needs — @1x/@2x/@3x for iOS, mdpi through xxxhdpi for Android, and SVG or vector drawables where the artwork should scale losslessly. Icons, illustrations, and imagery arrive named and organised. Developers implement the design; they do not reverse-engineer it. When design feeds our own Flutter build, the tokens map straight into the code, so nothing is lost in translation.
Store screenshots and launch artwork
The same design system produces the App Store and Google Play screenshot set — the framed, captioned marketing images at each required device size that carry a real share of a listing’s install conversion. Designing them from the actual UI, in both languages, keeps the store presence honest to the product a user opens.
What moves the cost of app design in Dubai
App design is priced against effort, and a handful of factors set that effort long before any figure is discussed. Understanding them lets you shape scope deliberately instead of being surprised by a quote:
- Screen count and state depth — a screen with six real states is six times the design work of a static mockup, and totals matter less than how many states each screen carries.
- Platform variance — a single shared layout is one effort; distinct iOS and Android variants where the conventions diverge is more.
- Bilingual parity — genuine Arabic RTL design, not a mechanical mirror, adds real design time because it is close to a second design pass rather than a translation of the first.
- Design-system depth — a full token-based system with dark mode and documented components costs more upfront than one-off screens, and pays it back on every screen you add later.
- Research and testing — user research, usability sessions, and iteration are scope, and skipping them is the usual reason a cheaper design costs more once it ships and underperforms.
Dubai design studios and freelancers price this in different bands, and the honest read is that a quote far below the market usually signals a mechanical mirror for Arabic and a skipped testing stage rather than a bargain. We scope design as a defined set of deliverables so you can see exactly what your budget buys. Our pricing overview explains how we structure engagements, and the fastest way to a real number is to tell us your screen list and platforms.
Who this service is for
App design as a standalone engagement fits teams who already have developers — in-house or external — and need the design phase run by specialists who will hand over a spec, not a mood board. It also fits founders who want a high-fidelity, testable prototype to validate the idea and raise against before committing development budget.
For teams who want one accountable partner across the whole product, the design phase is simply stage one of a full mobile app development engagement — the Figma files flow straight into our iOS, Android, or Flutter streams with no handoff loss, because the people who designed it sit beside the people who build it. Either way, the next step is the same: share your project and we will scope the design phase screen by screen.