Flipping the Mental Model in a Complex System
Giving airline revenue teams direct, real-time control over their checkout — without engineering.
Problem
Airlines had no self-serve way to configure their hosted checkout. Every change required an internal request and a quarterly release cycle.
Role
Lead UX Designer — sole designer on the project; owned the end-to-end configuration experience across both non-technical and technical user roles.
Constraints
Broad configuration logic had to remain operable by non-technical users, independently, without engineering involvement.
Outcome
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, and turned 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, which allowed users to preview how their rules would affect shopping carts before publishing their rules to their production systems. Effectively, allowing users to create unit tests for their payments configurations.
Approved for development; not launched before company restructuring.
Early versions presented common configuration options to the users, but research revealed that these options were not sufficiently granular for our clients.
Our final version reduced the cognitive load on users and allowed them to focus only on the portion of the configuration tasks that they were interested in.
1. Context & Problem
Airlines embedded our hosted payment page directly into their booking flows. Because shoppers never left the airline's site, the page had to feel indistinguishable from it — and when it didn't, conversion dropped.
Every single thing we can do to make this look better makes us more money.
Client Shopping Product Manager
Beyond appearance, airlines 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, brand standards, and regional configuration.
Developer / integration lead
Embeds the payment page into the airline's booking flow. Ensures reliable behavior across channels and systems.
Clients needed granular control over the look and feel of the checkout experience, which required careful planning of the configuration experience. The UI could transform to feel like a seamless extension of our clients' shopping paths.
2. Constraints & scope
The system needed to give commerce managers direct control — without engineering involvement — over:
-
Payment method availability, display order, and branding by region, device, channel, and user status
-
Surcharges, fees, and tax display by method, region, and channel
-
Fraud controls and data collection requirements by market
-
Installment options, multi-currency support, and loyalty point redemption rules
-
Split payment combinations
-
Terms, error messaging, and UI branding — logos, colors, fonts, field labels
-
How the payment page integrates into the airline's booking flow
Clients frequently expressed a need for extensive control over theme, color, fonts, and even wording of labels and error messages. Our solution was to provide a UI to account for common UI requests, while giving technical users access to a style sheet for maximum control.
Clients could preview their theme changes directly in the configuration UI.
3. Leadership & influence
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.
4. Research & insights
Our research team ran 11 moderated sessions with representatives from four international airlines, spanning digital commerce managers, product owners, developers, and payment ops leads.
-
Simple toggles weren't sufficient. Airlines needed payment display to respond to multiple conditions simultaneously — device, region, channel, login status, cart contents, fraud profile — in combination, not independently.
-
Branding flexibility was a conversion requirement. Shoppers who sensed a third-party checkout abandoned. Visual continuity had to be treated as a core feature, not a cosmetic option.
-
The if/then rules direction was validated. We had modeled the approach on filtering logic familiar from tools like Outlook to reduce the learning curve for non-technical users. Research supported moving forward.
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.
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.
5. Key decisions & tradeoffs
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.
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 the rules would affect a user based on their cart content, origin country, device type, and other factors. This system would allow users to check that their configurations were correct before pushing them to production.
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 different a configuration than if a user accessed it from an Android device.
We also designed for region-level targeting before confirming the data existed in our systems. Regions were client-specific, and we didn't have that data in our systems. Both reached client testing before we caught them. Earlier engineering involvement in assumption review would have prevented both.
Our final solution let users craft rules that created exceptions that layered on top of their default configuration. Error checking was built into the rule creation process, and we had other error-reduction features in place, like test carts, and rollbacks, to ensure maximum confidence when users were configuring their systems.
6. Outcomes & reflection
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.
7. Project status
Approved for development. Did not launch before company restructuring.
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.