flight editing feature
A self-service flight editing feature for a corporate travel app — giving travelers full control over their bookings without the wait.
(Native Mobile · B2C · Edge Cases)
Client: Lola Travel and Expenses
Role: Lead Product Designer
context
When COVID-19 disrupted travel plans worldwide, Lola's internal support team — the Wombats — was overwhelmed with flight change requests overnight. Every modification, no matter how small, required manual intervention. The volume was unsustainable, so the solution was to put control back in users' hands.
Building a self-service flight editing feature isn't just about the happy path — it's about designing a system that can make real-time decisions on behalf of users, tell them whether they can edit their own booking, and if not why they can't, and what to do next. At the moment when things don't go the user's way, the design either builds trust or destroys it.
My role
Lead designer on the travel pillar, owning the full UX process from discovery through high-fidelity delivery. I worked directly with the product manager, engineering team, and the Wombat support team to define eligibility logic, map edge cases, and design a system that could handle both self-service and handoff scenarios gracefully.
problem space
Before this feature, users had no way to modify their flights in the app. Every change required a Wombat. During the pandemic, requests surged — delays mounted, users were frustrated, and operational costs climbed.
Technical questions
• Airline fare rules are complex and invisible to users. How do we surface eligibility without overwhelming them?
• The cost of a wrong decision is high — missed flights, fees, forfeited value. How do we create confidence at the decision point?
• Some users can self-serve. Some can't. How do we redirect smoothly without making people feel abandoned?
Approach
I kicked off with a discovery sprint with stakeholders from product, engineering, and the Wombat team. The main output was a decision framework — grouping every possible editing scenario into two buckets: eligible for self-service, and ineligible.
That framework became the backbone of every design decision that followed and it was deliberate: build the happy path first, get it right, then layer in edge case handling — each one designed not as an error state, but as a moment of trust.
Self-service eligible
• Single traveler booking
• No flown segments
• All legs of flight selected for class change
• Booked by the traveler or on behalf of
someone else
someone else
• More than 60 minutes before departure
Self-service not eligible
Routed to Wombat support with a clear explanation and direct next step
Routed to Wombat support with a clear explanation and direct next step
• Multiple travelers in a booking
• Class changes for individual legs
• Less than 60 minutes before departure
system-wide decisions
Rather than presenting users with a wall of airline restrictions, I designed the system to make the eligibility call silently and route accordingly — no jargon, no technical explanations, just the right experience for the right scenario.
Refund types
Depending on airline rules, users might face an even exchange, partial refund, or forfeited value. Outcomes were surfaced clearly before users committed — not after.
Change within void period
Edits made shortly after booking sometimes qualify for a free void. Surfaced proactively so users had the chance to cancel instead of going through a full change flow they didn't need.
Edits made shortly after booking sometimes qualify for a free void. Surfaced proactively so users had the chance to cancel instead of going through a full change flow they didn't need.
Cabin class change
Class changes had to apply to the entire trip to qualify for self-service. The system detected partial eligibility and blocked it cleanly, explaining why rather than just saying no.
Class changes had to apply to the entire trip to qualify for self-service. The system detected partial eligibility and blocked it cleanly, explaining why rather than just saying no.
user flow / happy path
The ideal scenario. Single traveler, no flown segments, plenty of time. The user selects a new flight, reviews the change, and completes checkout without friction.
not eligible for Self-service
One leg flown
A round-trip traveler who had already flown the outbound leg. The system detected the flown segment, locked it, and presented only the remaining leg for editing. A technically complex scenario routed to the Wombat team.
A round-trip traveler who had already flown the outbound leg. The system detected the flown segment, locked it, and presented only the remaining leg for editing. A technically complex scenario routed to the Wombat team.
Multiple travelers
Complexity handled as a graceful handoff. A clear explanation and a direct path to the Wombat team.
Complexity handled as a graceful handoff. A clear explanation and a direct path to the Wombat team.
60 minutes to departure
Time-sensitive alerts built directly into the interface. Users understood immediately why self-service wasn't available and what to do next.
Time-sensitive alerts built directly into the interface. Users understood immediately why self-service wasn't available and what to do next.
Reflections & Growth
The immediate impact
• 20% reduction in Wombat ticket volume for flight changes
• Positive user feedback on autonomy and reduced wait times
• The eligibility framework set the foundation for future automation across travel management
The hardest design work on this project wasn't the happy path — it was the edge cases. Each one was a moment where user trust could either be built or broken. A clear explanation, a direct next step, a proactive surface of information the user didn't know to ask for — these were the details that made the difference between a feature that empowered users and one that simply redirected them.
This project also reinforced how much edge case design depends on deep collaboration with engineering and support. The Wombat team knew every scenario that caused friction. Engineering knew every constraint. Getting those perspectives into the design early was what made the system robust.
