flight editing feature
In-app flight editing feature for Lola.com, allowing users to modify their existing flight booking.
Client: Lola.com
Role: Lead Product Designer
Duration: June 2020 – Dec 2020
context
As COVID-19 disrupted travel plans worldwide, Lola.com—a travel management platform for small to mid-sized businesses—was inundated with flight cancellation and change requests. The internal support team (Wombats) became overwhelmed with manual booking modifications. To reduce support load and empower users, the team prioritized building a self-service flight editing feature.
This in-app capability aimed to streamline the user experience, enabling travelers to make eligible changes to their flights without assistance. It also needed to work within the technical limitations of flight APIs and legacy booking systems.
my role
As the lead designer for the travel pillar, I was responsible for overseeing the entire UX process, from research to testing and high-fidelity delivery. This involved collaborating with the product manager and engineers, conducting research, creating wireframes, and designing high-fidelity prototypes. My goal was to build an intuitive, reliable experience for users while working within a fast-paced, high-stakes environment.
problem space
Before this feature, users had no way to edit their flights through the app. Every modification — no matter how small — had to go through the Wombat team. During the pandemic, the volume of requests surged, leading to delays, user frustration, and increased operational costs.
The core challenge
How might we enable users to make flight changes independently, while ensuring accuracy, clarity, and compliance with airline rules.
Usability and technical constraints:
• When are changes allowed based on fare rules, timing, and user permissions?
• How should exceptions (e.g., multi-passenger bookings or flights within 60 minutes) be handled?
• What is the right balance between automation and support intervention?
Approach
To kick off the project, I led a discovery sprint with stakeholders from product, engineering, and customer support. The main focus was to identify the technical limitations of existing flight booking systems and the needs of the users.
Discovery phase:
• User Interviews: Talking to both users and the Wombat team to understand pain points and identify repetitive scenarios.
• Use Case Mapping: Grouping editing scenarios into two categories: eligible and ineligible for self-service.
• Flowchart Development: Designing clear decision trees to visualize editable conditions (e.g., cabin class change, flight legs, passenger count, timing).
• Rapid Wireframing: Due to time constraints, we moved quickly into prototyping core flows while validating edge cases in parallel.
solution
Given the urgency of the feature, we focused on delivering high-fidelity designs quickly. I worked closely with the engineering team to ensure technical feasibility and iterated on designs with real users to maintain a user-centric approach. We also identified key touch points (email notifications, trip receipts, PDF invoices) that would need to be updated to reflect the changes.
The feature allowed users to modify flights directly within the Lola app, provided the booking met certain criteria. To streamline the flight editing process, I categorized use cases into two groups: eligible and ineligible for self-editing.
Self-Service Eligible Scenarios:
• Single traveler booking.
• No flown segments.
• All legs of flight selected for class change.
• Booked by the traveler or on behalf of someone else.• More than 60 minutes before departure.
Self-Service Ineligible Scenarios:
• Multiple travelers in a booking.
• Class changes for individual legs.
• Less than 60 minutes before departure.
Wireframes
I wireframed user flows for both the “happy path” and edge cases to ensure that all potential flight edit scenarios were covered. However, we prioritized building a reliable "happy path" experience first, then layered in exception flows and edge case handling to maximize flexibility and reduce support overhead.
Design Flows Covered:
• Change outbound flight date.
• Change cabin class (entire trip).
• One leg flown (partial eligibility).
• Refund options: airline credit, even exchange, forfeiture.
• Multi-traveler bookings (handoff to support).
• Changes within void period.
User flow: Change outbound flight date
1. Select the trip from the Trips page.
2. Choose the leg of the flight to change.
3. Select a new date.
4. Search for available flights.
5. Select the new flight.
6. Checkout.
7. Confirm changes.
outcome
The flight self-editing feature was launched on an accelerated timeline and successfully reduced the burden on the support team. By supporting both the ideal use case and a wide range of real-world edge cases, the solution struck a balance between user empowerment and operational feasibility.
Also, the modular structure of the feature also set the foundation for future automation in travel management.The immediate impact:
• 20% reduction in Wombat ticket volume for flight changes.
• Positive user feedback on autonomy and reduced wait times.
• Increased system reliability through built-in eligibility logic and messaging.
Prototype included:
• Cabin class changes (applies to the entire flight).
• Handling one leg of the flight that had already been flown.
• Offering various refund types (even exchange, airline credit, forfeited value).
• Scenarios where users had to connect with the Wombat team for multiple travelers or urgent changes within 60 minutes of departure.
Happy path
This is the ideal scenario where a user meets all eligibility criteria: a single traveler booking, no flown segments, and changes requested well in advance. The user is able to successfully select a new flight and complete the checkout process without any friction.
Cabin Class Change
Users often wanted to upgrade or downgrade their entire flight to a different cabin class. The system needed to ensure that class changes applied consistently across all flight legs to qualify for self-service.
One Leg Flown
Some users tried to modify roundtrip bookings after already flying the outbound leg. In these cases, the system had to detect the flown segment and restrict edits to only the remaining leg, while ensuring users understood these limitations.
Refund Types
Depending on airline rules, users might encounter different refund scenarios—such as even exchange, partial refunds, or forfeited value. The interface had to clearly explain refund outcomes before users committed to a change.
Multiple Travelers
When bookings included more than one traveler, complexities like split tickets or differing change preferences made self-service infeasible. These cases required a clear redirect to the Wombat support team with messaging to manage expectations.
60 Minutes to Departure
Airline policies typically prevent edits within 60 minutes of departure. For last-minute changes, users had to be rerouted to support, with time-sensitive alerts built into the interface to reduce confusion or panic.
Change Within Void Period
Edits made shortly after booking often qualify for a free void or cancellation, depending on the airline. We designed a flow to surface this information upfront, giving users a chance to void the trip instead of going through a full change flow.
Reflections & Growth
This project showcased the power of agile collaboration under pressure. With travel restrictions changing daily and support requests spiking, our team had to move quickly, often designing and testing in parallel with development.
Although the compressed timeline meant fewer upfront usability tests, we compensated by launching a tightly scoped MVP and iterating rapidly post-launch. Our "snappy and scrappy" mindset helped us deliver a high-impact feature that met urgent user needs while laying the foundation for more robust editing capabilities in the future. This project remains one of my favorite examples of fast, user-centered problem-solving under high stakes.
Key takeaways:
• Clear scoping and smart prioritization of edge cases were essential for delivering a focused, efficient solution.
• Open communication across design, product, engineering, and support enabled faster alignment and smoother execution.
• Trust and close collaboration between design, engineering, and product management fueled the team’s ability to deliver quickly under pressure.
• Embracing a "snappy and scrappy" mindset helped the team stay agile, iterate fast, and deliver a high-impact feature on a tight timeline.
