Dubai Police AIX

Shown as method, not material

This project was delivered under a signed non-disclosure agreement with Dubai Police. Out of respect for that agreement, this page carries no screens, no components, and no detail of how the system works. What follows is how I worked, not what the product does.

A government AI service, mid-flight

Dubai Police were building a conversational AI service for citizens, and it already had a design system in place. I was brought in as Senior UX/UI to strengthen the foundation the product was being built on, to Dubai Government Design (DDA) and WCAG accessibility standards, in Arabic and English.

I did not start this system from a blank file. I started from one that existed and had grown inconsistent, which is a harder and more common problem than a clean start.

Read it before rebuilding it

The first deliverable was not a design. It was a written evaluation of the existing system, followed by a solutions and recommendations report, each structured across ten areas:

• Colours and colour token naming
• Libraries and platforms
• Typography
• Figma structure
• Design strategy and governance
• Components, patterns, and reusability
• Handover and versioning
• Project and sprint alignment
• Spacing and layout tokens

Naming the problems in writing, before touching a single screen, is what let the rebuild be a decision instead of a preference.

A system, from tokens up

From that evaluation I rebuilt the system to a new version, structured so that every layer feeds the one above it:

• Tokens: primitive values, then semantic tokens on top, with light and dark themes and a JSON export for developer handover
• Foundations: usage rules for colour, type, spacing and radius, plus layout, grid, and RTL / LTR handling
• Components: controls, containers, navigation, feedback, and media
• Component tokens: radius, spacing, typography, and elevation mapped per component
• Patterns: forms, content, and layout patterns
• Platform adaptation: web, iOS, and Android, with full Arabic RTL
• Documentation: do and don't, accessibility, token change process, versioning

Referenced, not copied

The system was built against established references rather than invented in isolation: Apple's Human Interface Guidelines for hierarchy and accessibility, Material for scalable state-driven design, IBM Carbon for enterprise-scale token architecture and governance, and Radix and shadcn for component state modelling and token-driven implementation. References as guiding principles, with every decision adapted to the client's brand, content, and context.

A system earns its keep in a real product

A design system is worth nothing as documentation on a shelf. So I built a working proof of concept on the new system, assembling real product screens from its components and tokens, to validate responsiveness and the experience end to end before handover. The system was tested by being used, not by being described.

Held to a government bar

Everything was held to Dubai Government Design standards and WCAG accessibility, Arabic-first with full RTL, across web and mobile. On a public service, accessibility and clarity are not polish. They are the product.