UX Case Study: Pilot vacation bidding web app
From left: Wireframe sketches after usability testing on earlier designs; mapping the new feature as it fits with the entire enterprise web app
Problem Statement
The process of bidding on vacations for pilots at Alaska Airlines was completed with legacy web apps using outdated technology. These included many steps which required manual data entry and reliance on static documents.
Sources of the pain points were from previous surveys, website analytics, feedback from the scheduling administrators, and pilots who represented the union.
Many times during bidding periods for the upcoming flight schedule, errors would occur, which had to be mitigated by phone calls, emails, audits, and updating spreadsheets and static documents. These frequent errors would reduce the confidence the pilot’s union had with the airline.
From left: Designing the feature to scale to a bigger enterprise web app; redline documentation provided for developers
Users and Audience
This web app is designed for pilots of Alaska Airlines to bid on their annual vacations. It helps both the pilots to have control over the leisure time they are awarded each year, and the airline to manage an efficient schedule.
From left: An earlier version of the design. Initial designs included a way to filter the calendar view to see available vacations for different bases, positions, and equipment. It also allowed a system for bidding multiple by entering a vacation length and the end of the range. Both of these features were scrapped after usability testing proved them too complex and of little value.
Roles and Responsibilities
As UX designer, I had the responsibility of facilitating discovery sessions, surveys and workshops. This research was done first, in collaboration with the product owner.
After the research, my role was to write scenarios, create wireframes and mockups, and test early and often with prototypes.
After testing and UX peer review, I facilitated several reviews with my product team and finally handed it off to the developer team.
From left: Making multiple bids on a laptop; making a single bid on a smart phone
My Solution
After gathering research from workshops and surveys, and studying the legacy process, I decided that a mobile web app would be optimal. The web app would be optimized for tablets and smart phones, but would also work on other platforms.
I introduced an advanced calendar component which would allow the pilots the ability to see available vacation days for an annual flight schedule, and make their bids on chosen days.
In addition, I designed a way for the pilots to see all of their bids for a year, edit and reorder them by priority, and submit them by the due date.
From left: Editing bids on laptop; edited bids on laptop; edited bids on smart phone; bid view on smart phone
How This Solution Solved the Problem
My solution allowed pilots to see a chronological calendar of the year with available days to bid for vacations indicated with colors and numbers. Previously they had to open separate static documents which the schedulers and admin posted in a company Sharepoint site. Usually pilots would print these out and refer to the document while making their bids on the legacy application. My solution allowed them to see all of the information they needed in one screen, and make their bids with fewer clicks or taps. It was designed to be responsive, so the pilot could complete their vacation bidding on a laptop, tablet or smart phone.
Additionally, the pilots were able to see their bidding rounds (a process which allowed them to choose their days off for a year by seniority) in the same screen. With the legacy application, they had to refer to another static document for this information.
Additional benefits were added to the solution for preventing errors by making primary CTAs inactive until required criteria was met.
My solution replaced several points of manual data entry with automatic data. It also reduced reliance on complicated documentation to explain the bidding process. Finally, designing a path of least resistance with clear affordances reduced the time spent by schedulers and admin to manage complaints and errors.
From left: Single bids on a smart phone; pilot profile card on a smart phone; ability to look at future rounds; and the ability to look at future rounds on a smart phone
Challenges
The designs I came up with had to use a very tight design system created for the business and enterprise web apps by the airline. In some cases, a specific solution had positive results with testing, but the existing design system did not support the new design pattern. In those cases, I had to work with the developers to build the design pattern from scratch.
This project was initially scaled to be a broad update to the vacation management system with many legacy processes. When feature creep scoped out the initial estimate, the project was split into two. The Pilot Vacation Bidding feature followed six months after the Pilot Vacation Trading feature was launched.
Affects for the Users
After the first part of the project launched, the feature for Pilot Vacation Trading, I shared several surveys to get feedback from pilots on the overall design. This provided valuable insight which was used to improve the Pilot Vacation Bidding feature when it resumed.
Outcomes and Lessons
Some of the usability testing I did with pilots during earlier wireframes and prototypes revealed that they wanted to see a calendar which matched their traditional mental model, with each date of the month also indicating the number of available days for bidding. Earlier I had assumed they just wanted to see the days, and refer to a separate screen for what was available.
We also learned that it was more intuitive to click or tap on a date, and be able to scroll through the entire year.
My earlier prototype included a simpler toolbar for bidding on single vacations or multiple vacations. The usability testing revealed that this took more discoverability than was reasonable. With the feedback from the pilots, I was able to hone in on an optimal solution.
Additional reviews with the UX team and the product team helped us build a feature which was truly the right solution.
As of this writing, the feature is in development. Post-launch surveys, analytics and usability testing are planned for later in 2021.
