Home
Solving the Multi-Traveler Addon Problem at Sastaticket
Solving the Multi-Traveler Addon Problem at Sastaticket
Solving the Multi-Traveler Addon Problem at Sastaticket
4 min est. read
Overview
While designing the addons flow I identified a structural problem the product owner hadn't considered. Baggage, seat, and meal selection each required knowing the specific traveler and itinerary before they could function, information that didn't exist until after traveler details were entered. Moving them to after that step solved the dependency problem cleanly.
While designing the addons flow I identified a structural problem the product owner hadn't considered. Baggage, seat, and meal selection each required knowing the specific traveler and itinerary before they could function, information that didn't exist until after traveler details were entered. Moving them to after that step solved the dependency problem cleanly.
My Role
Product Designer
Timeline
Q3 2022
When I pushed back on where the addons lived
When I pushed back on where the addons lived
The product owner initially wanted baggage, seat, and meal selection placed in the same addons step as Sasta Refund and Travel Insurance, before traveler details were entered.
As I started designing I realised these three addons couldn't function without knowing the specific traveler and itinerary first. A seatmap can't render without knowing the flight. Baggage can't be assigned without knowing the leg. Meal selection can't be personalised without knowing the passengers.
I proposed moving them to after the traveler details step, where that information would already be available. The PO saw the problem immediately and we restructured the flow together.
The product owner initially wanted baggage, seat, and meal selection placed in the same addons step as Sasta Refund and Travel Insurance, before traveler details were entered.
As I started designing I realised these three addons couldn't function without knowing the specific traveler and itinerary first. A seatmap can't render without knowing the flight. Baggage can't be assigned without knowing the leg. Meal selection can't be personalised without knowing the passengers.
I proposed moving them to after the traveler details step, where that information would already be available. The PO saw the problem immediately and we restructured the flow together.
Financial addons like Sasta Refund and Travel Insurance worked here because they applied to the whole booking. The PO initially wanted baggage, seat, and meal in this same step.
Financial addons like Sasta Refund and Travel Insurance worked here because they applied to the whole booking. The PO initially wanted baggage, seat, and meal in this same step.
Baggage selection requires knowing the specific traveler and itinerary. That information doesn't exist before traveler details are entered.
Baggage selection requires knowing the specific traveler and itinerary. That information doesn't exist before traveler details are entered.
Seat selection requires a full seatmap per flight per traveler. It can't render without passenger and itinerary data.
Seat selection requires a full seatmap per flight per traveler. It can't render without passenger and itinerary data.
Meal selection adds a third layer, categories, per traveler, per flight leg. All three addons shared the same dependency problem.
Meal selection adds a third layer, categories, per traveler, per flight leg. All three addons shared the same dependency problem.
Each addon type had its own review state, giving users a clear summary of their selections per traveler and itinerary before proceeding.
Each addon type had its own review state, giving users a clear summary of their selections per traveler and itinerary before proceeding.
Learnings
Learnings
The best time to catch a flow constraint is before the user stories are locked. Identifying the data dependency early meant we restructured the flow before any engineering work had started, saving significant rework downstream. It also reinforced something I've found consistently, the gaps in a brief are usually more important than the brief itself.
The best time to catch a flow constraint is before the user stories are locked. Identifying the data dependency early meant we restructured the flow before any engineering work had started, saving significant rework downstream. It also reinforced something I've found consistently, the gaps in a brief are usually more important than the brief itself.