Emirates Skywards/Loyalty Platform/37M Members/Design a rules engine, not a page/Aviation/180 → 1 System/Web · iOS · Android/Emirates Skywards/Loyalty Platform/37M Members/Design a rules engine, not a page/Aviation/180 → 1 System/Web · iOS · Android/
( Product Design — Aviation )

Emirates
Skywards

A $3B loyalty platform was leaking its best customers. So I stopped designing a page.

Role
Lead Product
Designer
For
Emirates Skywards
via Noah Design
Year
2019
37M members
Platforms
Web · Mobile · iOS · Android
Scope 37M members
Emirates Skywards

37M members who spend 30% more per trip and rebook 42% more often — and the best ones were quietly drifting into indifference. I was hired to redesign the members page. What shipped was a system that decides which page to show, to whom, when.

37M
Members served by the framework at scale
180 → 1
Tier-and-journey permutations resolved by one system
25+
Modular components with tier variants and journey states
5 methods
Card sort, moderated usability, surveys, A/B, heatmaps — reversed the IA
Honesty note: launch slipped from 2022 (pandemic travel collapse, internal restructuring) and I left before it went live — so I don't have post-launch numbers. What I can vouch for is the framework: the Skywards team still uses it to configure the surface today.
Scene one · The brief

“Redesign the members page. Increase engagement.”

Ten words. Skywards was category-defining — 37M members, 12 partner airlines, Miles people planned lives around. But engagement was drifting: still booking, slowing quarter on quarter. With these unit economics, that mattered:

30%
More spend per trip vs. non-members
42%
More rebookings from Skywards members
1%
Shift in engagement × 37M members = 9-figure revenue

“Skywards members spend 30% more per trip than non-members. They rebook 42% more often. So even a 1% shift in retention or engagement across 37M members translates into nine figures of revenue.”

— Internal business case, month one

A nine-figure problem framed as a ten-word brief. That's the tell: when the stakes are that big and the ask that narrow, the ask is almost always wrong.

The business case — Skywards members spend 30% more and rebook 42% more often
The business case — why even a 1% drift was a nine-figure problem
Interlude · The psychology

A short note on why loyalty programmes work at all.

Miles have no intrinsic value — the airline can devalue them overnight. What makes a loyalty programme workisn't the miles. It's four psychological effects Skywards had leaned on for two decades.

Investment loops

Members don't own miles — they own the effort that earned them. Every flight is a deposit; the more you invest, the more you return to protect it. The page was meant to make that loop visible.

Endowment effect

“Your miles” feel worth more than the same miles in the abstract. The pronoun “Your” and the balance rendered up top both underwrite that.

Loss aversion

“Miles expire in 47 days” hurts about 2× as much as “Earn 5,000” feels good. Every expiry warning and countdown carried more weight than any banner.

Goal-gradient effect

Members accelerate as they near a tier — someone 90% to Gold is more active than one at 30%. Tier-progress modules are load-bearing, not decorative.

Interactive · The member journey

What members actually do, think and feel

Pre-booking
Making a Booking
During Travel
After Travel
Triggers

A business trip or family holiday — or an email offering a deal, or a nudge about miles to spend or a tier to retain.

Enough miles for a reward flight, or expiring miles to spend — or an upgrade is wanted or available.

At the airport, unsure which tier benefits are available.

An email on miles earned or tier status — and a worry that miles weren't added to the account.

Activities
  • Check miles / statement
  • Use the Miles Calculator
  • Check tier status
  • Book an upgrade
  • Book a reward flight
  • Check benefits at current tier
  • Read email & check Skywards account
  • Check miles / tier were added
Thinking
  • What's the best value?
  • How far can my miles take me?
  • How many miles can I earn?
  • How many miles will this cost?
  • Can I upgrade with my miles?
  • What benefits do I get?
  • Can I get a reward flight?
  • Can I access the lounge?
  • Can I get bonus miles?
  • Have my miles been added?
  • How many did I earn?
  • Did I retain my tier?
Experience
Checking milesSimple, easy
Miles calculatorNot useful, bland
Tier statusApp easy · web confused
Booking upgradeConfused, uncertain
Reward flightHigh value
Check benefitsUnaware, low value
Read emailGood in app
Check miles addedAppreciated, in control

Every good decision here was really about which of these four effects to lean on, and when. See loyalty as a stack of behavioural loops, not a set of features, and what to design — and what to strip — gets easier.

“Cycles of repeated investment, where individuals commit more resources — time, money, or effort — into a pursuit due to their previous investments.”

— Investment Loops · Sigma UX Handbook
Scene two · The member

The heatmap that killed the brief.

A composite of members we spoke to

Priya, Gold tier, eight years an Emirates flyer, lands in Dubai on a red-eye. She claimed her miles mid-flight — a ritual — but the code failed, and now she's in the members section trying to fix it before her connection. Not tier benefits. Not a welcome banner. She wants to claim miles for one flight, right now.

She scrolls past six things she doesn't need, taps three that look right, and on the fourth finds the claim form — buried under “My Account.”

Priya is not the problem. The page is.

We ran heatmaps across four weeks of session data. The pattern was stark enough to change what we were designing.

The legacy Skywards members pageLinear — one layout for 37M users; the heatmap showed attention pooling on the Claim Miles form, not the nav or content

Why Priya bypassed everything we designed.

The visual design was strong. The heatmap just showed four psychological effects firing at once — none favouring what we'd put on screen.

Selective Attention.She came to claim miles, so every module that wasn't the claim form was functionally invisible — her brain filtering to the task.

Information Scent.The strongest cue on the page was the “Claim Miles” field, so attention flowed there. The hero and tier carousel smelled wrong; only the form smelled like her task.

The design implication

When a member's task model diverges from the designer's dashboard metaphor, the member wins. The job stops being “make the page better” and becomes “design a system that produces the right page for the right member at the right moment.”

Scene three · The map

The moments where members actually needed the programme.

First I had to know what the right moments were. I mapped the full journey — every trigger, activity and question a member asks at each step. Four stages: OnboardingPre-journeyIn-journey Post-journey.

Interactive · The tier × journey matrix

Which module shows, and when

Pick a membership tier and a journey stage — the home rebuilds itself from the widgets available for that cell.

Membership tier
Journey stage
Upcoming FlightsAvailable
Book FlightAvailable
Miles CalculatorAvailable
Payment MethodsAvailable
UpgradesAvailable
Priority ServicesAvailable
Flight StatusNot available
NotificationsAvailable
Travel AnalyticsNot available
RewardsNot available
Earn BonusNot available
Nominate PartnerNot available

7 of 12 widgets available for Gold · Before Flight

Two things jumped out: the same member needs different things at different stages, and different tiers need different things at the same stage. Substantively different.

Engagement wasn't dropping because the page was broken. It dropped because the key moments — pre-booking, at the airport, after travel — were designed for a generic user who didn't exist.

Scene four · The math

Fifteen widgets, four stages, three tiers. Do the math.

Mapped against the tiers (Blue, Silver, Gold; Platinum a v2 edge case), we counted the widgets a member might need at any moment: fifteen — Claim Miles, Book a Flight, Upcoming Trips, Tier Progress, and the rest.

Fifteen on one surface is Hick's Lawterritory. But cutting wasn't an option — a Gold member on travel day needs a different six than a Blue member at signup. Not too many widgets; the wrong ones for the wrong person at the wrong moment.

15
Widgets a member might need surfaced
× 4
Journey stages
× 3
Tiers
180
Permutations to design, review, spec, ship, maintain

You can't design 180 pages — especially when tomorrow adds a tier, a stage, or a widget and you're back to square one. I saw it in Week 7, staring at forty layouts that all felt wrong: the difference between designing a screen and designing a system.

The Skywards home rebuilt from modular widgets — one grid assembled per member from tier, journey stage and language
Components that knew who you were
Scene five · The pivot

So I stopped designing a page. I designed a rules engine.

The pivot took an afternoon to see and three weeks to sell. What I'd hit was Tesler's Law — complexity is conserved: you can hold it in the system or inflict it on the user, never make it vanish.

The old page put it on the member — every Priya scanning past fourteen things to find one. My proposal moved it into the system. It read:

“Design will not ship 180 layouts. Design will ship a matrix of allowable widget combinations, a set of adaptive layout primitives that hold any combination gracefully, and a component library where every module knows which tier and journey stage it's rendering for. Product configures. Design owns the primitives. Engineering ships once.”

— Design proposal, month three

Three groups of people had to buy this to move it forward:

Product

Loved it — a config panel instead of a change request. “You don't file a design ticket for a Gold promotion. You toggle it.”

Engineering

Loved it less — a rules engine is harder than a page. The pitch: “Build the primitives once, never re-scope again.” The maintenance maths sold them.

Brand

Worried a system-built page would feel generic. We agreed brand signs off every layout primitive— not every permutation. That's how it scaled.

Me

Had to stop showing screens and start showing rules. Harder to pitch — nobody Instagrams a matrix — but the only way this shipped on time.

Observation-booth research walls — members' pain points, issues and needs clustered across sticky-note boards
How we validated: observation-booth research walls

“The page was designed as a dashboard. Members were using it as a utility. That mismatch was the real insight.”

The artefact

The Widget Availability Matrix.

Every cell answers one question: at this stage, for this tier, should this widget surface? Product owns the toggles; design owns the primitives that hold the result. A slice of the shipped matrix below — the real one is wider.

OnboardingPre-journeyIn-journeyPost-journey
BlueSilverGoldBlueSilverGoldBlueSilverGoldBlueSilverGold
Complete profile··········
Book first flight··········
Upcoming trips······
Airport info·········
Lounge access··········
Claim miles·········
Redeem miles······
Tier progress····
● surfaces · · hidden · A product manager toggles these without opening a design file. The layout primitives adapt.
Craft · Adaptive layouts

Six layout primitives that hold any widget combination gracefully.

Knowing which widgets surface is half the system. The other half is how they render — at one, three, six, or the rare eight. So I built six layout primitives, each tuned to a widget count and priority, and made every matrix cell resolve to one.

“Each cell of the tier × journey matrix resolves to one of these layouts, based on widget count and priority. Product teams configure; design owns the layout primitives.”

— Layout specification, November 2019
Modular layout primitives — each tier × journey cell resolves to one of these
25+ modular components — every module ships with tier variants, journey states and copy rules baked in

One Welcome module, four faces: city-of-origin for returning members, a first-flight CTA for Blue, an upgrade-nudge for Gold. One component, zero extra design tickets — the shorthand for how the whole system worked.

Before / after

What the legacy page looked like. What it became.

Before — the audit

Too many nav options, everything at a zero state, “My Account” (where you book and redeem) hidden, five viewports of components, no clear booking CTA.

After — the new surface

Same member, same stage. A page assembled at request-time from relevant widgets, ordered by priority, styled by tier. A utility that knew what she came for.

Legacy Skywards members page — annotated auditRedesigned Skywards members surface — Gold tier, in-journey
Before / after — legacy audit, then the redesigned surface at Gold tier, in-journey
Redesigned surface — Silver tier, pre-journeyRedesigned surface — Blue tier, onboarding
Same primitives, different jobs — Silver pre-journey and Blue onboarding
Research

How we knew we weren't guessing.

A framework this ambitious needed proof. We ran five research methods across the design phase — some to inform, some to test, some to keep us honest.

42
Members in the card-sort study that reversed our information architecture
8
Moderated usability sessions with real Skywards members
4
Key markets tested across (UAE, UK, India, Australia)
5
Research methods: card sort, moderated usability, surveys, A/B, heatmaps

The card sort was the most useful. Forty-two members sorted the fifteen widgets by “how often would I reach for this?” — not “how much do I like it?” Claim Miles and Redeem Miles, buried three levels deep, were what members reached for most. We reversed the IA in a week.

“Many users, even the higher tiers, found it difficult to find where to spend, claim and buy miles — which is a key revenue driver for the business.”

— Research finding, quantitative + qualitative
The redesigned Skywards members surface, live in production
Impact

What shipped, and what I can't take credit for.

Honesty first: launch slipped from 2022 (pandemic, restructuring) and I'd left before it went live — so I don't have the post-launch numbers a perfect case study puts up top. Here's what I can point to:

1
Widget Availability Matrix adopted as the framework the Skywards product team still uses to configure the surface
25+
Modular components shipped in the system, each with tier variants and journey states
180 → 6
Permutations reduced to six adaptive layout primitives
42 → new IA
Card sort completely reversed the information architecture pre-launch

The work I'm proudest of isn't a number — it's that the framework outlasted me. The Skywards team was still configuring the surface through the matrix three years on. That's the bar for a system: it survives its designer.

Reviewing the numbers behind the redesign
Learnings

What I'd do differently.

1. I'd push back on the brief in week one, not week seven.

The right brief wasn't “redesign the members page” but “design a system that decides which page to show” — and I found that out after seven weeks of pages that would never ship. Now week one is research only: better to burn a week on the right question than a quarter on the wrong one.

2. I should have designed the measurement plan on Day 1.

I can't quote the uplift — partly because I left, partly because we hadn't built the measurement rig up front. A framework with 180 configs needs a measurement layer as deliberate as the design. On my next system-scale project, it was in the brief on Day 1.

3. Every design decision was already a psychology decision.

The whole project was applied behavioural science dressed as a UI redesign. Now, before Figma, I write the behavioural map — which effect I'm leaning on, which tax I'm removing. “Because it's cleaner” loses to a stubborn stakeholder; “because Loss Aversion outweighs the gain frame ~2× here” ships.

“The work I'm most proud of isn't a number. It's that the framework outlasted me on the project.”

— Personal note, on leaving Emirates

Emirates Skywards is the project I return to whenever I'm about to design a page and catch myself. It taught me the difference between shipping a screen and shipping a system — and that the hardest part of a system isn't the design. It's the argument for it.

Working through the same reframe on your platform? My inbox is open.