Dubai Municipality: Civic UX for 3.5 Million Residents

The Problem

Dubai Municipality manages a large and varied portfolio of civic services for a city of 3.5 million residents — building permit applications, environmental complaints, public facility bookings, waste management requests, and more. Residents interact with these services in Arabic and English, with different mental models, different reading directions, and different expectations of how a government platform should behave.

The previous design submissions for the platform had been rejected by Dubai Municipality's senior leadership. We were coming into a project where the client had already been disappointed, trust was low, and expectations of what design could deliver were appropriately sceptical. The brief wasn't just to design a better platform. It was to design one that would actually get approved.

On top of this, the designs would be implemented by the client's own development team in Mendix, a low-code enterprise platform with specific layout and interaction constraints. Whatever we designed had to be buildable within those constraints, not just impressive in Figma.

My Role

Lead UX Designer, working onsite in Dubai for the full engagement. I was the primary designer on the project and the person presenting directly to senior Dubai Municipality stakeholders at each milestone. Every significant design decision required formal sign-off before moving to the next phase.

I worked closely with the client's technical team to understand Mendix's capabilities and constraints, ensuring that every design decision was buildable and not just visually coherent. The engagement was structured as a series of milestone deliverables with binary outcomes: approved to proceed, or rework required.

Key Decisions

Decision 1: Information architecture before any visual design

The temptation in government platform design is to start with the visual layer, to show clients something that looks like a finished product quickly. This is usually a mistake. Dubai Municipality's service portfolio is large, complex, and internally inconsistent: different services have different eligibility criteria, different document requirements, different approval chains, and different expected completion times.

We spent the first phase purely on IA, mapping every service category, every decision branch, and every document dependency, before touching a single layout. This meant that when we did present visual designs, the structure underneath them was grounded in how the services actually worked, not how we assumed they worked. This was also the factor that distinguished our approach from the previous submissions, which had been rejected partly because the structure felt arbitrary to the client's operational team.

Decision 2: Bilingual parity from the first wireframe, not retrofitted RTL

Most bilingual design projects treat Arabic as a translation layer applied to an English design. You design in English, hand it to a translator, then "flip" the layout. This produces subtle but consistent failures: icons placed on the wrong side, form fields that don't align, navigation that feels backwards, numbers formatted incorrectly.

We designed every screen in both directions simultaneously from the first wireframe. LTR English and RTL Arabic were treated as equal first-class layouts, not a primary and a derivative. This caught layout failures early, when they were cheap to fix, rather than in development, when they're expensive. It also meant the Arabic experience felt designed rather than translated, which was immediately apparent to the client's Arabic-speaking stakeholders during presentations.

Decision 3: Milestone sign-off structure, not open-ended reviews

UAE government engagements have a specific stakeholder dynamic. Decisions happen at a senior level, multiple people need to align, and ambiguity in a review meeting tends to produce delay rather than direction. Open-ended review sessions ("what do you think?") are the wrong format for this environment.

We structured the engagement as a series of formal milestones, each with a specific scope and a binary outcome: approved to proceed, or specific changes required. Presentations were structured as decision briefings, not design showcases. This gave senior stakeholders a clear role in each session. They were being asked to make a decision, not form an opinion, which accelerated sign-off and kept the project moving.

Decision 4: Designing within Mendix constraints from the start

The client's development team would implement the designs in Mendix. Mendix has specific constraints: limited custom layout options, a defined component set, particular behaviour patterns for forms and navigation. Designing without accounting for this would produce beautiful Figma files that couldn't be built without significant custom development work, which the client's team neither had the budget nor the capability for.

Every design decision was validated against Mendix's capabilities. Where we wanted something that Mendix couldn't easily do, we found an equivalent solution within its constraints rather than specifying something the client couldn't build. The handoff was usable, not aspirational.

Results

• Designs formally approved by senior Dubai Municipality stakeholders, after previous design submissions from the project had been rejected
• Platform serves 3.5 million Dubai residents across the full portfolio of municipal services
• Bilingual platform approved by Arabic-speaking stakeholders with no RTL rework required in development
• Information architecture mapped for the complete service portfolio before any visual work began, establishing a structural foundation the client's operational team could validate
• Designs handed off directly for Mendix implementation. The client development team built from Figma specifications without requiring custom engineering workarounds
• Milestone-based delivery structure enabled formal stakeholder sign-off at each phase, preventing scope drift in a high-accountability government environment

What I'd do differently

I'd invest more time in the usability research phase before finalising service flows. We had strong structural foundations from the IA work, and the client's stakeholders approved the designs, but we had limited access to actual residents during the design process. Government procurement timelines rarely allow for extended user research, and this project was no exception. In retrospect, even two rounds of lightweight usability testing with Arabic-speaking residents would have stress-tested assumptions about task comprehension that we validated only through stakeholder review.

I'd also document the RTL design decisions more systematically: which layout rules we established, which exceptions we found, how we handled edge cases like numeric strings in Arabic text. That knowledge existed in the design files but wasn't captured as reusable guidelines, which means the next team to work on an RTL product starts from zero instead of building on what we learned.