Building the Visual Language for the City of the Future

Impact

• Unified UI/UX across NEOM's urban mobility ecosystem

• Reduced design onboarding time for new vendors and partners

• Future-proof scalability through tokenized component architecture

• Directly influenced MVP funding — scaling design resources by 40%

My Role

Lead Design System Designer — responsible for the full scope from visual language definition through tokenization architecture, accessibility compliance, and team leadership.

The Challenge

Most design system projects start with a brand. Ours didn't. When I joined, NEOM's sub-brand for urban mobility had no visual identity — no colors, no typography direction, no established aesthetic. Before a single component could be designed, we needed to answer a harder question: what does this brand look and feel like?

That question had a constraint: whatever we created had to align with the NEOM master brand without being absorbed by it. Mobility needed its own identity — distinctive enough to stand on its own across vendor touchpoints, coherent enough to feel like NEOM.

 Discovery & Brand Definition

We ran dozens of concept explorations before anything crystallized. Nature-inspired forms. Futuristic gradients. Geometric systems. Organic curves. Most directions either drifted too far from the NEOM world or didn't have enough personality to carry a product family.

The breakthrough came when we leaned into contrast: bold slanted shapes as a structural motif, paired with a gradient palette that referenced NEOM's landscape — the desert, the coastline, the night sky.

Futuristic without being cold. Distinctive without being disconnected. Once stakeholders aligned on the direction, we had our visual language. The design system work could finally begin.

Building the System

With a defined aesthetic, we moved into architecture: defining the token structure, building light and dark theme libraries, establishing accessibility standards, and creating the component set.

The challenge throughout was that these weren't standard components. NEOM's mobility products required patterns that don't exist in conventional design systems — booking flows, real-time transit interfaces, multi-vendor surfaces. Every decision had to balance the specific needs of the mobility context with the flexibility required for future applications we couldn't fully anticipate.

We built the system to be tokenized from the ground up — colors, spacing, typography, radius, all abstracted into properties that could be overridden per vendor or per theme without breaking the underlying structure.

Testing in the Real World

A design system is only as good as the products built with it. To stress-test our non-standard components before they were adopted across the ecosystem, I designed a mobility booking app — a realistic vehicle for putting the system into practice.

The app served two purposes: it validated that the components held up under real product conditions, and it gave us something concrete to bring to stakeholders.

I traveled on-site to Saudi Arabia to run usability testing directly with local users. Testing in-context mattered — mobility behavior, expectations, and environmental conditions in NEOM's environment are distinct from anything you can simulate in a remote session. The findings shaped several component iterations before final handoff.

From Concept to MVP

The stakeholder presentation changed the project's scope entirely. What began as a testing vehicle for the design system became something the business wanted to ship. The mobility booking app concept resonated strongly enough that stakeholders approved funding to build an MVP — and brought in two additional mid-level designers to execute it.

I moved into a dual role: continuing to lead design system development while directly managing the expanded team building the MVP. It was a significant shift in scope, but also a signal — the design system work wasn't just producing components. It was producing a product vision that the business wanted to invest in.

Documentation & CMS

The last piece was making the system usable at scale. We built a custom CMS to manage all components, documentation, and design tokens in one place. The goal was to reduce the friction of vendor onboarding — new partners could access component specs, usage guidelines, and token values without needing a designer in the loop for every question. Centralized documentation turned the design system from an internal tool into an organizational asset.