Case study — Pricing Logic
Rebuilding how a pricing feature works — across finance, legal, and product
Emerging Travel Group
Partners either avoided the feature, or used it in a way that broke their invoices
This feature let partners include certain add-ons (meals) in their room rate. But the underlying logic had real financial and legal gaps: costs were miscalculated in some booking configurations, tax treatment for the add-on could legitimately differ from tax on the room itself, and some partners couldn't use the feature at all because the add-on was provided by a separate legal entity and needed to appear separately for their own accounting.
Reconciling finance, legal, and product logic before designing a single screen
This wasn't a pure usability question. I started with a fin/legal questionnaire and interviews to validate tax and commission requirements up front, and only then moved into usability testing — first moderated, to shape the initial design, then unmoderated testing across three design variants to pressure-test the finalized flow under time constraints. Both the designer and I had planned time off mid-project, which pushed us toward unmoderated testing — a method my manager specifically noted as new for our team — to keep validation moving without either of us present to moderate.
Two operating modes, tested independently
[Visual: before/after screenshots of the settings and rate-setup flow, and a first-click/rage-click heatmap from a secondary interaction test.]
New users looked in the wrong place — until they'd seen it once
Experienced testers (who'd seen earlier concepts) correctly navigated to the new settings location; new users defaulted to searching under "services and amenities" instead.
"If I hadn't already known where to look from the interview, I would have decided these extras weren't worth setting up at all."
Users were confused by the distinction between selecting multiple individual add-on types (e.g. breakfast, dinner) versus one combined option (e.g. "breakfast and dinner") — a wording/IA problem, not a comprehension failure.
When asked which of the two pricing modes they'd actually choose, every new tester in that group picked the simpler, rate-inclusive option — a clear signal for how to set defaults.
A secondary heatmap analysis found a persistent expectation that a "more options" icon should be clickable to open an item, even after users had already learned an alternative path — a small but recurring interaction pattern worth tracking elsewhere in the product.
A validated, build-ready logic — currently waiting on engineering capacity
The research produced a fully validated product logic — two clearly defined operating modes and consistent tax/commission rules for each — tested and refined across three design variants. My manager's evaluation called the research itself "a complex, high-impact project" that went beyond typical scope by aligning finance, legal, pricing, and UX into one coherent, implementation-ready solution.
Given more runway, I'd have liked to validate the wording for the "combined vs. individual" add-on options with a dedicated round of testing rather than folding it into the broader usability rounds — it was the one area where confusion persisted across both experienced and new testers.
I'd also note, in hindsight, that research readiness and implementation timing don't always move together. This project is a good example of delivering a fully validated, build-ready outcome that's still waiting on engineering capacity — a normal, if slightly unglamorous, reality of working inside a prioritized backlog.