Airline Mobile App:
Research-Driven Group Booking Feature
How a behavioral insight from user interviews generated a feature that wasn't on any roadmap, then survived four months of complexity work to ship.
The Brief
A major airline was rebuilding its mobile application from scratch. Over a 10-month engagement, I worked as the UX researcher and designer, conducting discovery research, usability testing, and iterative design across the full app experience.
This case study focuses on one workstream within that broader engagement: the shopping cart and checkout flow. It was the biggest research-driven win of the project, because it produced a feature that didn't exist before, born entirely from a behavioral insight uncovered during user interviews.
Discovery Research
Early in the engagement, I conducted 12 in-depth user interviews to understand how travelers interact with airline booking apps. The interviews covered the full booking journey, from search to purchase, and were designed to surface behavioral patterns rather than surface-level preferences.
When traveling with friends, the group gathered together in person, projected the booking screen onto a shared device, and purchased all tickets in a single transaction. Afterward, they manually calculated how much each person owed.
This specific cost-splitting exercise was described explicitly by one participant. The broader behavior pattern (one person purchasing on behalf of a group) appeared across several other interviews.
The existing shopping cart made this exercise harder than it needed to be. Fare content (benefits, baggage allowances, seat details) was mixed together with the cost breakdown in a single dense view. For a solo traveler, this was cluttered but manageable. For a group trying to figure out who owed what, it was unusable.
Connecting Research to Opportunity
The interviews told me what users were doing. Competitive analysis told me the solution was already proven elsewhere.
Groups book together, one person pays, then they manually split costs afterward. The app gave them no way to see per-person totals.
Southwest offered a per-passenger view, but their cart only includes tickets. Our client's cart bundled fares, taxes, baggage, ancillaries, and airport fees in one view. Far more complex.
I proposed two changes:
Restructure Information Hierarchy
Separate fare benefits (what you get) from cost details (what you pay). Eliminate the visual clutter.
Add "By Flight" / "By Passenger" Toggle
Let users switch between views. Turn the manual cost-splitting exercise into a built-in feature.
Pushback and the Complexity Challenge
The per-passenger toggle was not an easy sell, for two reasons.
The client had strong confirmation bias. Research was expected to validate, not challenge. The app was being rebuilt from a white-label, and any departure from the baseline was treated as financial risk. Every change required data-driven convincing.
Unlike Southwest's ticket-only cart, this cart had mixed fare types, different tax structures, and different ancillary selections per passenger. After approval, we spent ~4 months mapping scenarios to get the per-passenger math right.
I made the case using three arguments:
Research Evidence
The group-purchasing behavior appeared across multiple interviews. A real, recurring pattern, not a single anecdote.
Competitive Precedent
Southwest already offered per-passenger pricing. Users had an existing mental model. We'd be meeting an expectation, not inventing one.
Low-Risk Design
Toggle defaults to 'By Flight' (familiar view). Solo travelers see no change. 'By Passenger' is one tap away for those who need it.
Design Solution
The redesigned shopping cart separated content into two clear layers:
Flight costs, taxes, fees, ancillaries, baggage, and promotions. In "By Flight" mode, grouped under each flight leg with subtotals. In "By Passenger" mode, grouped under each traveler's name showing exactly what each person owed.
Baggage allowances, seat selection, boarding priority, and other inclusions. Displayed separately from cost information. Eliminated the visual clutter of the original cart.
The toggle sat at the top of the cart, clearly labeled, with "By Flight" as the default. Switching views preserved the same total.
Validation
The shopping cart redesign was validated during the third round of usability testing (UT3). Each round tested two to three features simultaneously; this was the first time the shopping cart was tested. I designed unmoderated remote tests using a Single Ease Question (SEQ) methodology.
Average SEQ score of 6/7 with no participants scoring in the low range (1–4).
Per-passenger view recognized and used without prompting by participants with group-booking experience.
One participant couldn't find the cart entry point (navigation issue, not cart design). Fed back into broader app navigation.
A participant suggested labeling the cart more explicitly, like 'cost breakdown.'
Results
The per-passenger cost breakdown went from a behavior no one on the product team had identified to a validated, shipped feature. It eliminated the manual cost-splitting exercise that groups of travelers had been doing outside the app, and it brought the client's shopping cart in line with competitive expectations, while handling significantly more complexity than any competitor's implementation.
Beyond the feature itself, the information hierarchy restructuring (separating fare benefits from costs) improved readability for all users, not just groups.
Reflection
This case study is the clearest example in my portfolio of research directly generating a feature.
The per-passenger cost breakdown wasn't on any roadmap. No stakeholder requested it. No competitor audit flagged it as a priority. It emerged because I sat with 12 users and listened to how they actually behave when booking flights with other people, and then connected that behavior to a proven solution in the market.
Working inside an organization with strong confirmation bias taught me something valuable about the role of research in risk-averse environments. The client's default expectation was that research would validate decisions that had already been made. Every departure from the white-label baseline was treated as a potential revenue risk, which meant that proposing something genuinely new required more than a good idea. It required evidence that was specific, quantifiable, and grounded in both user behavior and competitive reality.
This shaped how I built every research argument during the 10-month engagement. I learned to anticipate the question "what if this costs us money?" and to have the data ready before the question was asked. The per-passenger toggle succeeded not because it was an obvious idea, but because I could trace a clear line from a real user behavior, through a competitive precedent, to a design solution that added capability without adding risk for the majority of users.
The four months of scenario mapping after the feature was approved also taught me something about the gap between a research insight and a shipped feature. Discovering the opportunity took weeks. Validating the concept took one round of testing. Making it work across every permutation of fare types, tax structures, and passenger configurations took months of detailed design work. Research opens doors. Execution is what walks through them.