One baggage step,two sides to serve,and the details people skipped.
Travellers wanted a shorter booking. Pegasus needed baggage, a key revenue line, chosen on purpose. I redesigned the native baggage step to hold both, tested it, refined it and shipped it.
airlines benchmarked on app, mobile web and desktop
scenarios designed into one step
completed the new flow in testing
never opened the detailed rules
A step travellers wanted shorter, and Pegasus needed
An earlier usability study, run by another research team, gave us the travellers’ side. Pegasus’s product team gave us theirs. We took both into the redesign.
One step had to hold both.
Travellers’ side: earlier usability study by another research team. Pegasus’s side: notes from the product team, October 2024.
How others handle the same choice
Four airlines, three platforms and two scenarios: one passenger on the lowest fare, and a family of four. I walked each journey and annotated what they ask, when, and for whom.
Screens captured from each airline’s app, October 2024.
Where Pegasus diverged
| Behaviour | Pegasus | Wizz Air | Ryanair | Vueling | Volotea |
|---|---|---|---|---|---|
| Baggage shown in the bundle | Text on app & mobile web; icons on web | Icons | Icons | Icons | Icons |
| Steps after bundle selection | Passenger info → seat → meal → baggage → other services | Passenger info with baggage → seat → other services | Passenger info → baggage → seat → other services | Passenger info → seat → baggage → other services | Passenger info → seat → baggage → other services |
| If no baggage is selected→ Field-level errors | Field outlined in red, with an error message | Field outlined in red, errors above the field | Radio button turns red, error by the passenger name | Field outlined in red, errors above the field | Main CTA disabled, can’t continue |
| Package & baggage in payment summary | GapNo package information | No package info; extra baggage shown | Package info in app and web; paid extras shown | No package info; paid services shown | No package info; paid extras shown |
| Adding & removing extra baggage→ Explicit add / “I don’t want” | GapSlider in app, multiple choice on web | Keep the included option or choose “no baggage”; no deselect needed | Choose the included option or another one to continue | Radio buttons, with a “selected” label | Radio buttons |
| Warning when only a cabin bag is chosen→ Rules in a bottom sheet | Yes, tooltip | No | Yes, bottom sheet | Yes, info bar | Yes, modal |
| Per passenger vs. apply to all→ “Apply to all” toggle | GapEach passenger, one by one | Both | Both | Cabin bag applied to all; checked bag per passenger (tabs) | Cabin bag applied to all; checked bag per passenger |
Rebuilt from my competitive feature matrix: app, mobile web and desktop journeys, October 2024.
Four gaps worth designing for
One passenger at a time
Pegasus asked each passenger separately; Wizz Air and Ryanair also offered “apply to all”.
→ Apply-to-all toggleRequired choices
Competitors flagged the exact field, or kept the button disabled until a choice was made.
→ Required, error and confirmed statesWhat the fare includes
Pegasus’s summary left the bundle out; Ryanair showed it on app and web.
→ Allowance shown in the stepAdding and removing
A slider in the app, multiple choice on the web, and no clear way to say no.
→ Explicit “Add” and “I don’t want”Ten scenarios, one step
Every traveller reaches the same step with a different bundle and need. I designed each scenario into one contextual step, cabin and checked as separate decisions, with “apply to all” and inline validation. I owned the interaction model.
Depends on the bundle
No allowance in the bundle
Has an allowance, wants more
Depends on the traveller’s choice
Wants, or doesn’t want, a cabin bag
Chooses a checked bag
Sports or music equipment
Adds equipment step by step
Continues without a cabin bag
States the step must catch
Tries to continue without choosing
Opens the cabin bag rules
Cabin bag limit reached on the flight
The essentials show up in the step itself
The detailed sizes sit one tap away. What a traveller must know appears as the step responds.
The interaction worked. The detailed rules went unseen.
A moderated usability test with ten participants on the native flow. First, who completed it. Then, who never opened the detailed baggage rules.
The interaction worked. The detailed rules went unopened. That gap shaped the July refinement.
Choices you can see without a tap
The test showed that what sits behind a tap goes unseen. In the refinement, the checked-bag options moved out from behind a button and into the step itself.
12312 kg and 20 kg sit in the step instead of behind a + button; more sizes under “Other options”.
At Pegasus’s request, “Add a cabin bag” now comes before “I don’t want one”.
At Pegasus’s request, 20 kg is marked as recommended.
Wireframes from my March and July flows. Visual design by the team’s UI designer.
Before refining, I looked again
Pegasus asked for a recommended size, and the test pointed to checked bags in view. Before refining, I looked at how six airline apps handle the same step. Two patterns fed the refinement; the ones that let travellers skip the step didn’t make it.
Screens captured from each airline’s iOS app, July 2025.
One step, every scenario
The shipped step on iOS, walked through the way a traveller meets it.
Plays once. Pick a step to see it again. Shipped UI by the team’s UI designer; interaction and states from my flows.
On iOS and Android
One contextual baggage step replaced per-passenger screens, refined after testing.
A web adaptation
I’m adapting the flow for web now, building on the test findings.
The “why again?” stays
The step still shows for everyone, because baggage is a revenue line. The design keeps it quick instead of hiding it.
Post-launchPost-launch data wasn’t shared with our team.
“Business goals and user needs had to share one step. The work was making that trade-off visible, not pretending it away.”
Put both sides on the table first
The traveller’s complaint and the business need, side by side, before the first screen is drawn.
What sits behind a tap goes unseen
In this test, and later in my fare bundle study, details behind a tap went unnoticed. Must-knows belong in the step’s states.
Name which changes come from the business
“Add first” and the recommended size were Pegasus’s calls. Saying so keeps the design honest.