Red Sea Global
Connected Visitor Program - Multi-resort Booking
Context and problem
Most hospitality booking flows are built for a single property: pick dates, pick a room, pay. Red Sea Global's guests plan differently combining multiple resorts, accommodation types, and transfers into one trip. A single-property flow would have pushed that complexity onto the guest, at exactly the moment a high-value luxury purchase is most likely to be abandoned.
I joined as Senior UX Designer on the Booking Transactional Flow workstream to own that problem end to end.
Role & constraints
I led stakeholder discovery, competitive benchmarking, and the full information architecture and interaction design — through to developer hand-off. Discovery was compressed: a rapid assessment of requirements rather than an extended research phase, so early architectural calls had to hold up without a long validation cycle.
The team itself was a constraint worth naming: no one on it — including me — was a native English speaker, and we were designing for Arabic-speaking guests navigating a bilingual, RTL-aware product. That meant every IA and interaction decision had to be checked against how differently people read, scan, and navigate a system across cultures — not something a standard usability heuristic covers on its own.
▌ THE PROCESS
How we got there
Discovery
Interviewed users and mapped the current-state journey to locate the real friction, not the assumed one.
Exploration
Sketched divergent directions, then converged on one testable concept with the team.
Validation
Ran moderated usability sessions and iterated the prototype against what actually broke.
Approach
[IMAGE: Competitive benchmark — Six Senses, Four Seasons, Mandarin Oriental, One&Only vs. Airbnb/Expedia]
I benchmarked against luxury peers and mainstream booking platforms specifically to find where standard patterns would break under a multi-resort model. Nearly every competitor treated accommodation and mobility as separate transactions.
[IMAGE: Information architecture / multistep user flow]
The key decision: architect one non-linear, editable flow spanning resort, accommodation, and mobility selection through checkout — guests can revise any earlier choice without losing progress elsewhere. That's a more complex state model than a linear funnel, and I judged it worth the cost: a simpler flow would have shipped faster but shifted trip-planning complexity back onto the guest.
[IMAGE: Wireframes and interactive prototype]
From there I defined search and filtering behavior, optimized the accommodation and mobility selection paths, and built hi-fidelity wireframes and a prototype detailed enough for direct developer hand-off.
Outcome
The flow is live today at visitredsea.com. The clearest measurable result at this stage is time to market: concept through developer-ready design in six months, for a booking system spanning resorts, accommodations, and mobility. Post-launch usability or conversion tracking wasn't continued after hand-off, so I'm not claiming impact I can't back — the honest outcome here is that it shipped and it's running in production.
▌ DELIVERABLES
What shipped
- Benchmark
- Information Architecture
- User Flows
- Wireframes
- Mockups
▌ GALLERY
Selected screens
Colour and spacing tokens, generated from a single source. 
Button, field and card variants with every interaction state. 
Before: the same button drawn six different ways. 
Every pair checked to WCAG AA before it shipped. 
Usage guidance lives next to the component, not in a wiki. 
Rollout tracked per squad over one quarter.
Reflection
Designing for Arabic-speaking, multicultural guests reshaped how I thought about "clarity" — it's not a universal default. Reading direction, navigation habits, and how directly people expect a system to communicate all differ enough to change core interaction decisions, not just localization details.
Next case study →
Confidential (NDA)
LA Clippers