Case Study 03 · Design Systems · Product Ownership · Accessibility
UX strategy and a full design system for one of the world's largest retail destinations. Three very different visitors. One app that needed to serve all of them — reliably, accessibly, and fast.
-40%
Design Iteration Time
-25%
User Error Rate
+10%
Customer Retention
3
Personas Served
The Challenge
The Dubai Mall sees 100 million visitors a year. Its app had the right features on paper — wayfinding, loyalty points, store directories, restaurant booking. But in practice, it was failing the exact moments that mattered most: when Anya was jet-lagged and needed to find a store fast, when Mariam was managing three kids and trying to remember where she'd parked, when James wanted to get in and out in under an hour.
The app felt like it was designed for a demo, not for a Friday afternoon in the mall. My job was to change that — with a design system that would scale, and a user experience that started with the people actually using it.
"I paid premium to be here. Don't make me feel stupid for using your app."
That's Anya — international traveller, high expectations, zero tolerance for friction at the moments she's most cognitively depleted. She's not a difficult user. She's the user you need to design for.
User Research
Dubai Mall's visitor base is extraordinarily diverse — in nationality, in purpose, in physical context. We built personas that captured this complexity, with explicit accessibility dimensions for each, because the most common use cases weren't in comfortable office chairs.
Anya
38 · Singapore-based consultant · 48-hr Dubai visit
Goals
Pain Points
A11y Dimension
"I paid premium to be here. Don't make me feel stupid for using your app."
Mariam
41 · Emirati mother · Weekly Friday visit with 3 kids
Goals
Pain Points
A11y Dimension
"I want to actually enjoy being here with my kids. Not spend 20 minutes hunting for the car."
James
45 · British expat · Tuesday lunch visits
Goals
Pain Points
A11y Dimension
"Just work. I don't need an experience. I need a tool that doesn't waste my time."
Experience Mapping
We mapped Anya's journey in detail, because her context (jet-lagged, time-pressured, high expectations) created the highest stakes for every failure. What happened when she navigated to a closed store wasn't frustration — it was betrayal. The map showed us exactly where trust was built and where it broke.
| Stage | Anya's Thought | Emotional Arc | Accessibility Friction |
|---|---|---|---|
Awareness Emirates app mention |
"This looks promising. The mall is huge — I'll need this." | ✦ Hopeful, prepared | First impression opportunity: establish trust before she even arrives. |
Onboarding Downloads + signs in |
"Why does onboarding take this long? I just want to find a store." | ◈ Impatient | Cognitive Load Long onboarding strains jet-lagged attention span |
Navigation Searches for Zara |
"I'm definitely walking in circles. This is a total fiasco." | ▼ Frustrated, time-pressured | WCAG 1.4.11 Low contrast map labels in bright atrium light |
Loyalty Scans receipt |
"I have the receipt right here. Why won't it accept it?" | ▼ Angry, cheated | WCAG 3.3.1 Receipt scanner has no text error description — colour only |
Recovery Leaves 1-star review |
"This app made my trip worse. I'll warn others." | ▼▼ Betrayed, disengaged | No recovery pathway. No support channel accessible in-app. |
Design System
A 40% reduction in design iteration time doesn't happen by accident. It happens when you build a design system that every designer and developer can trust — with consistent tokens, component specifications, and usage rationale documented against real user needs.
Colour System — Contrast-First
Every colour pair tested at 4.5:1 minimum WCAG AA contrast ratio. Atrium-glare conditions required 7:1 for navigation-critical text (map labels, wayfinding CTAs). Warm, premium palette — not corporate blue.
Typography Scale — 8pt Grid
Headline — 24px / 1.2
Subhead — 18px / 1.35
Body — 16px / 1.7
Caption — 13px / 1.5
All sizes from a 1.25 Major Third ratio. Minimum 16px for body — protecting James's reading glasses scenario and older visitor contexts. No arbitrary sizes.
Touch Targets — Inclusive Sizing
Navigation actions: 48×48px minimum
Primary CTAs: 52×52px (pushchair-friendly)
Icon-only buttons: 44×44px + aria-label
Form inputs: 48px height, 16px label gap
Designed for Mariam's one-handed pushchair use and James's occasional glove use in winter. Comfortable margins prevent accidental activations.
Component States — All Seven
Every component documented with: Default · Hover · Active · Disabled · Loading · Error · Empty state.
Error states were designed with specific, actionable copy — not "Something went wrong." The receipt scanner error that betrayed Anya got a complete rewrite: "We couldn't read this receipt. Try better lighting, or tap 'Enter manually' below."
Accessibility Audit
We ran a full audit across all three persona contexts — Anya's bright-atrium glare scenario, Mariam's pushchair navigation, James's reading glasses. The findings weren't abstract violations. Each one had a real person behind it.
Receipt scanner provides colour-only error feedback
When a receipt scan failed, a red outline appeared with no text description. Users with colour blindness received zero error information. Even sighted users couldn't determine why it failed or what to do next — which led to repeated failed attempts and app abandonment.
→ Fix: Specific error text + icon + ARIA role="alert" + alternative manual entry pathway always visible.
Map labels fail WCAG 1.4.11 contrast in atrium conditions
Store name labels on the mall map used a light grey (#B0A8A0) on white background — 1.8:1 contrast ratio. In normal office conditions, barely acceptable. In Dubai Mall's bright atrium with glass ceiling, effectively unreadable. This was a daily failure for Anya and thousands of visitors like her.
→ Fix: Minimum 4.5:1 for all map text. High-contrast mode option for outdoor/bright conditions.
Floor selector touch targets: 28×28px
The floor selector in the wayfinding map used 28×28px tap targets. For Mariam with a pushchair and one free thumb, this required three or four attempts on average. In testing, two out of three parents navigated to the wrong floor at least once per session.
→ Fix: Floor selector redesigned as 52px pill buttons with floor name labels. Minimum 8px gap between targets.
Onboarding flow: 7 screens before core functionality
New users saw 7 onboarding screens before they could search for a store. For jet-lagged Anya walking in the mall entrance, this was actively hostile. The app that was supposed to help her was blocking her with a marketing presentation.
→ Fix: Progressive onboarding. Let users search immediately. Surface permissions and loyalty features contextually on first relevant use.
Loading states use spinners, not skeletons
When the store directory loaded, a blank screen with a spinner appeared for 1.5-3 seconds. No content preview, no indication of what was coming. For James, this ambiguity triggered his "the app is broken" heuristic and increased his likelihood of closing the app.
→ Fix: Skeleton screens for all content-loading states. Perceived performance improvement without changing actual load time.
My Process
This was my first role carrying both UX and product ownership responsibilities simultaneously. It changed how I worked — every design decision had to connect to a user story, a timeline, and a release. And every product decision had to connect back to one of the three personas.
UCDC Analysis + Multi-Context Research
User-Centered Design Canvas analysis across the three visitor archetypes. Field observation in actual mall conditions — including testing the wayfinding app in the atrium, in bright light, one-handed.
Accessibility-First Persona Development
Built Anya, Mariam, and James as accessibility-aware personas. Every access dimension documented as a design requirement — not an edge case consideration.
Emotional Journey Mapping
Mapped Anya's full journey from Emirates app discovery to post-visit review. Identified the trust-breaking moments that drove the 1-star reviews the client was receiving.
Design System Architecture
Built the complete design system: colour tokens, typography scale, component library, spacing system, and accessibility guidelines. Contrast-first approach throughout. Every component specification included human rationale.
User Flow Optimisation + A/B Testing
Redesigned core user flows with progressive disclosure. Ran A/B tests on key moments: onboarding length, receipt scanner error states, map label contrast. A/B testing contributed to the 10% retention improvement.
Product Ownership — Launch & Budget Management
Managed launch timelines and product specifications as Product Owner. Defined comprehensive user stories that kept engineering aligned with user needs through development. On-time, within-budget delivery.
Outcomes
-40%
Faster Design Iteration
The design system became the team's shared language. Decisions that previously required days of back-and-forth were resolved by pointing to documented components and tokens.
-25%
Reduction in User Errors
Optimised user flows, larger touch targets, and clear error states with actionable copy dramatically reduced the frequency of user errors in navigation and loyalty interactions.
+10%
Customer Retention Increase
A/B tested engagement improvements, combined with an onboarding redesign that let users reach core value faster, contributed to meaningful retention improvement.
On Time
On Budget
All product launches delivered on schedule and within budget. The design system infrastructure allowed the team to move faster as the project scaled.
Reflection
Doing UX and Product Ownership simultaneously is genuinely hard — and genuinely valuable. When you're writing user stories and design specs for the same feature, you can't hide behind vague requirements. You have to be specific enough for engineering to build it and empathetic enough to know whether it'll actually serve Anya at her most cognitively depleted moment.
The biggest thing I'd do differently: I'd push for more longitudinal observation data — particularly around the car finder failure that Mariam experienced every week. We fixed the technical issue, but we never fully understood the cumulative trust erosion that came from weekly reliability failures. That would have changed the priority order of some fixes.
The design system work here also reinforced something I believed but hadn't proven at this scale: accessibility isn't a constraint you design around. It's a quality bar that improves the experience for everyone. The contrast improvements that protected Anya's jet-lagged eyes made the map better for every user. That's not a compromise. That's good design.