Home
Bringing Design Consistency to NEOM at Scale
Bringing Design Consistency to NEOM at Scale
Bringing Design Consistency to NEOM at Scale
8 min est. read
Overview
NEOM's digital campaigns were reaching 200,000 registered users monthly across Arabic and English markets. A single newsletter dispatch alone reached over 62,000 subscribers simultaneously across both languages.
But every campaign was a one off. Approved designs rarely matched what went live. At that scale, inconsistency was not just a production problem. It was a trust problem.
NEOM's digital campaigns were reaching 200,000 registered users monthly across Arabic and English markets. A single newsletter dispatch alone reached over 62,000 subscribers simultaneously across both languages.
But every campaign was a one off. Approved designs rarely matched what went live. At that scale, inconsistency was not just a production problem. It was a trust problem.
My Role
Lead Designer
Responsibilities
Design Systems Strategy
Timeline
Q3 2024
Impact Snapshot
Impact Snapshot
+0%
+0%
+0%
Faster campaign rollout
Faster campaign rollout
-0%
-0%
-0%
Dev QA cycles
Dev QA cycles
The Challenge
Every campaign started from zero. Without a shared design language, developers estimated values rather than reading them. Inconsistencies compounded across every build cycle. Arabic was treated as a translation layer rather than a design problem, which meant RTL layouts were mirrored rather than intentionally rethought. At NEOM's scale, running concurrent campaigns across two language markets without a scalable foundation, this was not sustainable.
Every campaign started from zero. Without a shared design language, developers estimated values rather than reading them. Inconsistencies compounded across every build cycle. Arabic was treated as a translation layer rather than a design problem, which meant RTL layouts were mirrored rather than intentionally rethought. At NEOM's scale, running concurrent campaigns across two language markets without a scalable foundation, this was not sustainable.
Key Decisions
Concepts Before Components
Visual direction was locked before a single component was built. Building systems before stakeholder alignment on creative direction creates debt that compounds with every revision cycle. The system scaled what was already approved, not the other way around.
Iterative Over Complete
Building iteratively rather than delivering a complete system upfront was a product decision as much as a design one. A full library on day one would have taken months and contained components that never shipped. Every component in this system earned its place.
Figma Dev Mode as the Communication Bridge
The inconsistency between approved and built was not a craft problem. It was a communication problem. Developers were estimating values because there was no source of truth. Figma Dev Mode closed that gap.
RTL as a Design Problem
Arabic support was designed in from the start, not retrofitted. Every component was built for both directions with hierarchies rethought for RTL reading patterns.
Concepts Before Components
Visual direction was locked before a single component was built. Building systems before stakeholder alignment on creative direction creates debt that compounds with every revision cycle. The system scaled what was already approved, not the other way around.
Iterative Over Complete
Building iteratively rather than delivering a complete system upfront was a product decision as much as a design one. A full library on day one would have taken months and contained components that never shipped. Every component in this system earned its place.
Figma Dev Mode as the Communication Bridge
The inconsistency between approved and built was not a craft problem. It was a communication problem. Developers were estimating values because there was no source of truth. Figma Dev Mode closed that gap.
RTL as a Design Problem
Arabic support was designed in from the start, not retrofitted. Every component was built for both directions with hierarchies rethought for RTL reading patterns.
Atomic Design Approach
Two Libraries, One Unified Framework
EDMs and Cloud Pages have different layout constraints, rendering environments, and interaction patterns. Building them into a single library would have forced compromises that served neither surface well. Two separate libraries, each optimised for its context.
EDMs and Cloud Pages have different layout constraints, rendering environments, and interaction patterns. Building them into a single library would have forced compromises that served neither surface well. Two separate libraries, each optimised for its context.
Design Documentation
Every token, component, and pattern was documented with usage guidelines and exact specifications. Latin and Arabic typography scales were documented separately, with Arabic hierarchies defined for RTL reading patterns rather than derived from Latin scales. Developers had a reference that removed ambiguity from every build decision.
Every token, component, and pattern was documented with usage guidelines and exact specifications. Latin and Arabic typography scales were documented separately, with Arabic hierarchies defined for RTL reading patterns rather than derived from Latin scales. Developers had a reference that removed ambiguity from every build decision.
Component Structure
Components were built across four levels, atoms, molecules, organisms, and templates, each layer composing from the one below it. Nothing was built in isolation. A button defined at atom level informed every form, card, and campaign template above it. This meant a single token update could propagate correctly across the entire system without manual intervention at every level.
Components were built across four levels, atoms, molecules, organisms, and templates, each layer composing from the one below it. Nothing was built in isolation. A button defined at atom level informed every form, card, and campaign template above it. This meant a single token update could propagate correctly across the entire system without manual intervention at every level.
Built for every use-case
NEOM's campaigns span multiple formats, hero announcements, event promotions, product launches, and community updates. A rigid component set would have broken under that variety. Every component was built with configurable properties, allowing teams to adapt layouts, toggle content sections, and switch between language directions without rebuilding from scratch. Flexibility was not a nice to have. At NEOM's campaign velocity it was a requirement.
NEOM's campaigns span multiple formats, hero announcements, event promotions, product launches, and community updates. A rigid component set would have broken under that variety. Every component was built with configurable properties, allowing teams to adapt layouts, toggle content sections, and switch between language directions without rebuilding from scratch. Flexibility was not a nice to have. At NEOM's campaign velocity it was a requirement.
Learnings
The most persistent design problems are usually communication problems in disguise. Visual inconsistency was the symptom. The real issue was that design and engineering had no shared language. The system solved that. Consistency followed.
Bilingual design cannot be retrofitted. Building Arabic in from the start was not more work. It was less work across the entire project lifetime.
A system is only as valuable as the engineering relationship behind it. The library could have been perfect and still failed if developers did not trust what they were reading. Adoption follows trust, not completeness.
The most persistent design problems are usually communication problems in disguise. Visual inconsistency was the symptom. The real issue was that design and engineering had no shared language. The system solved that. Consistency followed.
Bilingual design cannot be retrofitted. Building Arabic in from the start was not more work. It was less work across the entire project lifetime.
A system is only as valuable as the engineering relationship behind it. The library could have been perfect and still failed if developers did not trust what they were reading. Adoption follows trust, not completeness.