Configuring the Payments Experience
What began as a configuration request evolved into a systems redesign. We needed to support granular payment targeting without increasing risk or complexity. The final approach centered on a layered rules and strategy model built for precision and control.
​Problem
​Airline revenue managers needed to configure payment offerings in near-realtime to respond to changing market conditions and target small but high-value customer segments. However, our payments configuration process lacked flexibility, and changes were tied to a quarterly release cycle. As a result, revenue-critical updates were delayed for months, preventing customers from acting on short-lived opportunities, running pricing experiments, and capturing available revenue.
​​
​
Objective
​Enable airline revenue managers to quickly configure and deploy payment changes—without release-cycle delays—so they can respond to market conditions and optimize revenue across customer segments.
​​
​
Role
​Lead UX designer
​​
​
Project Outcome​
Delivered a validated, rules-based configuration system that reduced cognitive complexity and enabled revenue managers to independently deploy highly targeted payment strategies in hours or days instead of months.
​
The project was approved for development but did not launch prior to company restructuring.
​​
​
Business Context & Constraints​
Airline revenue managers are highly-focused on their revenue targets, and they regularly need to make fine-grained changes to their online shopping and payment experiences in order to reach and exceed them. Even small changes to the experience had measurable and sometimes outsized effects on conversion, total checkout price, and ultimately, their bottom lines.
​
The early version of our checkout product had no configuration application designed for it. Over time, limited customization was supported through manual, consultant-driven processes tied to release cycles. However, this approach still prevented timely response to market shifts.
​​
​
Research and Insights​
​To better understand the impact, we spoke with eleven client groups. These conversations revealed three core gaps in the existing experience:
​
Configurations were not sufficiently targetable. Customers needed to apply changes by region, device, and channel—and often across multiple attributes at once (for example, “iPhones using the web interface from Brazil”). The existing tooling could not support this level of precision.
Configuration changes took too long to implement. Customers wanted to deploy changes daily—or even hourly—to test and respond to performance shifts. Our existing systems and processes didn't allow for that.
The range of configurable options was too limited. Customers needed control over both cosmetic elements and functional messaging—such as form labels and error states—to optimize conversion. Even small changes could have a meaningful impact on revenue.
​​
​
Strategy and Design Principles​
To address the constraints of our legacy release process and give customers meaningful control over revenue performance, we aligned on three guiding principles:
​
1. Make configuration deeply segmentable.
Customers needed the ability to target changes by region, device type, and booking channel — and combine these attributes when necessary. Precision was essential to unlock meaningful revenue optimization.
​
2. Prioritize speed without sacrificing safety.
We targeted reducing implementation time to one week or less while eliminating reliance on internal account consultants.
​
​3. Focus flexibility on revenue-impacting elements.
Rather than enabling unlimited customization, we prioritized configuration options that materially influenced conversion, pricing perception, and checkout behavior — based on direct customer feedback.
Exploration and Trade-Offs​
Version 1: Balancing Speed and Segmentation​​​​​​​​​​​​​​​​
Our first concept focused on enabling fine-grained configurations and implementation speed, while staying within known technical constraints.
Speed vs. Control
​
​Moving configuration into a self-serve application removed release-cycle delays and enabled immediate deployment. We introduced saved configurations to support rollback and reduce risk.
Assumption
Versioning would provide sufficient safety.
What we learned
While clients appreciated rollback capabilities, they were concerned about unintentionally deploying poorly-performing configurations without guardrails.
​
Precision vs. Simplicity
​We initially enabled targeting by region, channel, currency type, and cart content type. For simplicity, device type was inferred from channel (e.g., mobile app vs. web). We ultimately chose country-level targeting over region-level targeting because regional groupings were client-defined and not native to our system. This reduced implementation complexity but limited flexibility for customers managing markets at a regional level.
​
Assumption
Channel would serve as a reliable proxy for device type.
​
What we learned
This assumption broke down when customers accessed web experiences from mobile devices. Clients wanted device targeting to be independent so that they could prioritize Apple Pay on iPhones, or Android Pay on Android devices.
​
Assumption
Clients could correctly and easily configure their systems using country-level targeting.
What we learned
Airlines often segmented countries into multiple regions, and then applied different rules to each part of the country. This meant that a country-based configuration approach wasn't granular enough to solve their needs.
Users found it too overwhelming to try to comprehend the entire state of the configuration all at once.
Assumption
Presenting the entire state of the system at once would allow users to quickly implement their business rules.
What we learned
As segmentation options increased, the mental model became harder to understand. Users struggled to predict how overlapping rules would interact, reducing confidence in the system and increasing the risk of misconfigurations reaching production—potentially impacting conversion and revenue performance.
​
Version 2: A Rules-based Approach
​In our second iteration, we rethought the underlying segmentation model. Rather than attempting to represent the entire system state, we shifted to a rules-based approach centered on a single global default configuration.
​
Additional configurations were expressed as explicit exception rules layered on top of that baseline. This reduced cognitive load by allowing users to reason about one rule at a time instead of interpreting a full configuration matrix.
​
Assumption
Managing exceptions would impose a smaller mental load than reasoning about the entire system at once.
What we learned
Focusing on exceptions resulted in better testing outcomes and better qualitative results. However, when multiple cascading rules applied to the same feature, predictability became more complex. Because rule order determined precedence, reordering rules could change the final configuration outcome. Without clear visibility into evaluation logic, users still struggled to anticipate edge cases.
​
Despite these challenges, usability testing demonstrated a substantial improvement in clarity and confidence compared to Version 1, reducing the perceived risk of misconfiguration.
​
Assumption
A rules-based system would be sufficient for customers to fully manage their configurations.
What we learned
While the rules model addressed segmentation complexity, it failed to account for the seasonal and time-sensitive nature of airline pricing strategies. Revenue managers would have needed to manually update rules throughout the year to align with seasonal campaigns, fare changes, and promotional periods.
​
This introduced the risk of timing-related errors.
Our initial response was to introduce effective date ranges at the rule level. While this addressed timing control, it created new complexity. Rules would expire after their end date, yet many needed to be reactivated seasonally the following year. This required users to duplicate and maintain multiple corresponding rules with identical timing logic.
​
As seasonal rules multiplied, predictability declined and cognitive load increased. Users reported difficulty understanding which rules would activate or deactivate at specific times, due to the increasing cognitive load, which increased the likelihood of timing-related errors.
​
To address this, we introduced “strategies” — time-bound collections of rules that could be configured in advance, tested as a group, and automatically activated or deactivated on a defined schedule. This significantly reduced coordination complexity, improved predictability across seasonal campaigns, and enabled reusable configurations that could be deployed year after year without duplication.
​​
​
Final Solution​
​The final architecture combined a rules-based segmentation model with time-bound strategies and built-in validation mechanisms.
​
At its core, the system consisted of:
-
A global default configuration
-
Targeted exception rules layered on top
-
Time-bound strategies to group and schedule related rules
​
To address predictability concerns, we introduced a “test cart” system. Revenue managers could create representative cart scenarios and simulate how active rules and strategies would apply before deploying changes. This made rule evaluation logic visible and allowed users to validate configurations in advance, reducing the risk of unintended production behavior.
​
Versioning and rollback capabilities remained in place to provide an additional safety net, ensuring that configurations could be quickly reverted if necessary.
​
Together, these elements produced a scalable, time-aware configuration architecture aligned with airline revenue workflows — balancing precision, deployment speed, and operational safety.
​​
​
Pre-Launch Outcomes & Learnings​
​The company restructured prior to launch, and the product did not reach production during my tenure. However, testing cycles showed consistent improvements in clarity and task success.
Early sessions revealed confusion and hesitation around rule interactions. By the final iterations, participants expressed confidence in their ability to configure the system independently. In simulated configuration tasks, success rates and task completion improved as the mental model evolved from segmentation matrices to rules and strategies.
​
One early misstep involved designing region-level targeting before confirming the availability of region data within our internal systems. Closer collaboration with engineering earlier in the process would have prevented this assumption from reaching client testing. This reinforced the importance of validating data constraints alongside experience design.
​
Internally, there were ongoing discussions about how the rules-based model would scale under real-world production data. At the time of restructuring, we were actively modeling live configuration scenarios in high-fidelity prototypes to test edge cases and rule precedence behavior. While those evaluations were not completed, incremental testing up to that point demonstrated improved clarity and predictability compared to earlier concepts.
​
We also explored introducing a scoring system to resolve potential rule conflicts. However, user testing did not indicate a consistent need for that level of complexity, and we chose to avoid prematurely introducing additional abstraction.
