Case Study
Flipping the Mental Model
in a Complex System
Giving airline revenue teams direct, real-time control over their checkout — without engineering.
Case Study
Giving airline revenue teams direct, real-time control over their checkout — without engineering.
Airlines had no self-serve way to configure their hosted checkout. Every change required an internal request and a quarterly release cycle.
Lead UX Designer — sole designer on the project; owned the end-to-end configuration experience across both non-technical and technical user roles.
Broad configuration logic had to remain operable by non-technical users, independently, without engineering involvement.
Validated, rules-based system. Participants who couldn't complete tasks in early testing worked through the same scenarios independently and with confidence by final rounds.
Our final solution reduced the scope of the problem for the users, turning a mental model that required users to comprehend the state of the entire system all at once into a rules-based model where users could focus on exceptions and edge cases instead.
We added features like rollbacks and a test cart system, allowing users to preview how their rules would affect shopping carts before publishing to production — effectively enabling unit tests for payment configurations.
Approved for development; not launched before company restructuring.
I inherited a research-centered but unvalidated first-draft design. I started by mapping the user stories to their screens, walking through the expected flows, and gathering internal feedback. The response came back almost universal: friction wherever the design placed excessive demands on users' working memory.
Airlines embedded our hosted payment page directly into their booking flows. They needed payment behavior to respond to context: a frequent flyer seeing loyalty points first, an iPhone user seeing Apple Pay, a high-risk market triggering stricter authentication. None of that was possible without filing a request and waiting for the next quarterly release.
Digital commerce manager
Non-technical ops specialist. Owns the payment experience and regional configuration.
Developer / integration lead
Embeds the payment page into the airline's booking flow. Ensures reliable behavior across channels and systems.
The system needed to give commerce managers direct control — without engineering involvement — over:
Mapped as a system model, the scope ran from data sources and global form-of-payment availability down to card-provider rules, display customizations, translations, and the services — 3DS, installments, split payments, multi-currency pricing — each market could switch on.
Rejected concepts attempted to visualize the state of the system as a matrix for our users, but this quickly became overwhelming as the configurations scaled.
Working as the sole designer, influence had to come from the quality of the thinking rather than positional authority.
The most consequential decision I made was pushing to test the inherited V1 designs before the team committed to building on top of them. I was concerned the existing approach wasn't dynamic enough to support how airlines actually needed to configure payment behavior — but I needed data, not just instinct. I brought our UX research team into the project specifically to validate or disprove that hypothesis.
I also presented design direction and research findings to stakeholders, translating complex configuration logic into strategic rationale for a non-technical audience.
Our research team ran 11 moderated sessions with representatives from four international airlines, spanning digital commerce managers, product owners, developers, and payment ops leads.
The objectives the study set out to answer — framing the research before any sessions ran.
The research confirmed my earlier suspicions: the V1 model wasn't sufficient, and the findings gave the team clear, client-backed rationale for adopting a fundamentally different approach. That decision — to pressure-test the direction early rather than design further into a flawed model — reframed the entire project and prevented a much larger course correction later.
Crop from the architecture-ontology mural — Outlook's rules editor (top-left) was the mental model the new system borrowed from. The matrix view in the middle is what it had to replace.
The condition taxonomy — every dimension a rule could fire on, mapped together.
The rules engine blueprint — rule editor, criteria/action type lists, conflict-resolution catalog, and the strategies layer that bundles rules into reusable packages.
Three design stages, each shaped by what research revealed about how airlines actually needed to manage payment behavior.
V1 — The inherited starting point. A tiered product model that organized configuration around feature sets, rather than around the decisions airlines actually needed to make in production.
V1 payment methods — the matrix model that research confirmed was unworkable. Users had to hold the full configuration state in their heads across every combination of channel, currency, region, and spend type simultaneously.
Iteration 2 — A regional/channel table view. Closer to how airlines thought about their markets, but still required users to reason across the full configuration state from multiple directions at once.
Final — The rules editor. Users define one rule at a time: what conditions trigger it, and what action to apply. The full configuration emerges from rules layered on a global default — no matrix required.
What that means in the user flow — before and after the rules model:
A fresh configuration for every region, built from scratch.
Select a region
e.g. Eastern Australia
Select a channel
Web · Mobile · Call center · Airline.com · Agencies
Build the configuration from scratch
Repeat for every other region
Western Australia, North America, EU, APAC, MENA, LATAM, …
×30+ iterations
A global default covers most cases; rules handle the exceptions.
Select every supported region at once
Select channels
Web · Mobile · Call center · Airline.com · Agencies
Build the global default
Default applies everywhere
One configuration covers every supported region and channel.
Add an override rule (only when needed)
e.g. "On mobile in Eastern Australia, show digital wallet first."
Side-by-side, the difference is unmissable: V1 required users to rebuild the same configuration thirty-plus times to cover the globe. V2 ships one default that already covers everything, and rules carry the exceptions.
Shifted from matrix to rules-based model
V1 designs asked users to manage the full configuration state at once. Participants couldn't predict how their settings would behave in production. We shifted to a global default with exception rules layered on top, letting users reason about one condition at a time. Testing showed significant improvement in clarity and task confidence.
Led with the design instead of the research
After the additional research study, the researcher and I used a stretch when the team was focused on other development to brainstorm — and landed on the rules-based direction. We brought it to the PM as a new design before walking her through the friction the research had surfaced, and inadvertently blindsided her with the pivot. We backed up, walked through the findings and our thinking, and made the case — but the substance was right and the sequencing wasn't. Leading with the problem and letting the solution land second would have given the pivot the structural support it needed from the start.
Introduced strategies for seasonal complexity
Revenue managers needed to activate and deactivate rules throughout the year to align with promotions, creating timing risk and duplication. Strategies — time-bound rule packages scheduled in advance and reusable across years — substantially reduced the coordination overhead of seasonal campaigns.
Added a test cart to make logic visible
Rule order precedence was hard for users to predict. We built a simulation tool that let revenue managers preview exactly how their active rules and strategies would apply before pushing to production. Clients could create simulated carts to show clearly how rules would affect a user based on cart content, origin country, device type, and other factors — allowing them to verify configurations before going live.
Caught two bad assumptions late
We treated channel as a proxy for device type — that broke when users accessed web experiences from mobile devices. Accessing our payments path from an iPhone needed a different configuration than from Android. We also designed for region-level targeting before confirming the data existed in our systems; regions were client-specific and not available in our platform. Both reached client testing before we caught them. Earlier engineering involvement in assumption review would have prevented both.
Made the system legible one dimension at a time
Alongside the rules model, a "view by" layer let managers look at the entire configuration through any single lens — form of payment, region, channel, spend type, or currency — to see coverage at a glance, or filter down to one specific rule. The same system underneath, made navigable instead of overwhelming.
Our final solution let users craft rules that created exceptions layered on top of their default configuration. Error checking was built into the rule creation process, and features like test carts and rollbacks ensured maximum confidence when configuring live systems.
The working presentation I built to define the rules-based model — the user stories that set the scope, the libraries of conditions and actions a rule can draw on, the testing and strategy surfaces, and a representative per-feature configuration screen. Select any thumbnail to open it, then scroll to zoom and drag to pan.
The Configuration Manager landing state: Strategies (time-bound, reusable rule packages) on the left, individual rules on the right. Each rule surfaces its condition tags at a glance — users can scan coverage without opening individual rules.
Selected frames from the configuration board — hover for labels, select to open, then scroll to zoom and drag to pan.
Full artifact HPP configuration presentation Open the complete board — every frame, sticky note, and user story — as a single PDF. View
Higher-fidelity screens: per-form-of-payment settings with coverage across currencies, countries, spend types, and channels; the rule builder; custom channel definition; split payment pair stacks; installment plan rates; and terms and conditions configuration.
Testing trajectory
Early participants couldn't accurately predict configuration behavior due to the complexity. Final-round participants completed the same tasks independently and with confidence, thanks to a simplified mental model.
The hardest challenge wasn't the configuration complexity. The challenge was making conditional logic feel predictable to the person who didn't write the rules. The test cart solved it: make the system's behavior visible before it reaches production, and confidence follows.
Approved for development. Did not launch before company restructuring.
← → prev/next · scroll or pinch to zoom · drag to pan · Esc to close