UX Case Study: Flight Attendant PDR
PROBLEM STATEMENT
The business stakeholders for Alaska Airlines wanted an easier way for flight attendants to request to drop a scheduled flight.
There were errors in awarding or denying a flight attendant a drop request because there were many points where data was manually transferred by phone, email or text. Mistakes could cause problems with the FAA or the flight attendant union.
Parts of the process were hacked by the users, because some of the aspects of the job were not supported by the Sharepoint site which had been configured for the tasks.
The steps a flight attendant needed to make in order to make a personal drop request were overly complicated, and asked for information which was readily available from existing databases.
Usability testing prototypes.
The date and trip selectors were designed as clickable or tap-able controls, which demonstrated a better way for the user to communicate their choice.
USERS AND AUDIENCE
Flight attendants needed the feature to follow company policy in regards to whether the day off was paid or unpaid, and to help the schedulers fill the vacancy for the scheduled flight.
Schedulers (who schedule flight attendants on flights) needed the feature to get the correct information from the flight attendants in order to award or deny the request.
ROLES AND RESPONSIBILITIES
I functioned as Lead UX Designer. I worked with a product owner and five full-stack developers.
My responsibilities included gathering the initial request from the business and verifying it with research. I conducted discovery workshops and user interviews.
After the research, I began sitemaps and user journey maps. These informed wireframes.
Later I conducted usability testing with flight attendants, using clickable prototypes.
I also conducted testing with schedulers.
I scheduled UX team peer reviews, to ensure my designs aligned with the enterprise design system.
I reviewed the prototypes with the product team to help the engineers plan how to build the back end functionality.
From left: Some earlier ideas to represent different trip types. When a trip was separated by a gap, it was called a “sequence interruption point”, and it meant that the flight attendant would return to their base while still serving the trip.
Right: instructions for developers on various selection states.
MY SOLUTION
The solution I designed was intended to simplify or even eliminate the need for data entry. It took what the system already knew about the flight attendant requesting to drop a scheduled flight, and allowed them to make the remaining selection by clicking from available options.
This solution would also reduce the amount of data entry for the schedulers, who often had to cross-reference the drop request being made by a flight attendant with information from other enterprise web apps.
While the schedulers previously had to check information from several other web apps and systems, my solution consolidated most of that information into a single UI, with a few exceptions.
HOW DID MY SOLUTION SOLVE THE PROBLEM?
The flight attendants can now see all of the information about them in the web app, because it fetches this information based on their authentication and their company ID, and they can select the exact trip or trip segment they need to drop by tapping from a list of their upcoming trips.
They can also revoke a drop request with a single tap, if they change their mind.
The schedulers can get most of the information they need to approve a drop request in one web app, because my team designed it to fetch the data it needed from other databases without the need for manual cross referencing and data entry.
Left: wireframing began with sketches on graph paper. Multiple iterations were explored before working with Sketch.
Right: Discovery sessions with schedulers, using Microsoft Teams in place of whiteboard and sticky notes.
CHALLENGES I FACED
I faced a major challenge in the functionality of the date or trip picker tool. Initially I wanted the flight attendant to perform basic data entry of the date range they wanted to request to drop. But, with many usability tests on early prototypes, I found that a simple graphic representation of the dates of their assigned trips would be simpler.
The idea of a graphic representation was suggested by many of the testers I interviewed. The challenge came when we had to make a distinction between what is known as a “reserve” and a “line-holder” trip assignment.
The reserve was simple, because it means that the flight attendant is on-call to take a trip, and has to be ready on a specific series of days.
The line-holder is assigned to specific flights, weeks in advance. They can select to drop a part of a trip, which can span two days. A date picker as was designed for the reserve flight attendants wouldn’t work.
The solution we shipped was designed by a brainstorming session with another product team.
Left: the schedulers had their own colors designated for each base for Alaska Airlines. We used the same colors to designate the bases in UI badges.
HOW DID THE PROJECT AFFECT THE USERS AND THE BUSINESS
As of this writing, the project is still in development, and will be released later in Q2 2021.
The final designs of the scheduler screens, which replaced a customized Sharepoint interface.
OUTCOME AND LESSONS
The project as defined by the product owner and the stakeholders was adjusted after user research revealed slightly different pain points than were assumed.
While the flight attendants were more likely to use the feature on a smartphone, the schedulers preferred to do their tasks on a desktop.
Research with the schedulers showed that they really needed to see a very small subset of the data they were getting in a Sharepoint spreadsheet to award a drop request. Though they expressed skepticism that our team could retrieve data from another API which would streamline their work, my team worked hard to build it.
I learned that the schedulers had their own colors to designate specific Alaska Airlines bases, so we used the same colors to represent the bases in the web app.
There was an earlier request by users to allow them to view all personal drop requests by all flight attendants in all bases. Usability testing of this feature in the prototype revealed it offered little value to flight attendants, so it was dropped.
