Alaska Airlines: Inflight recurrent training
Problem Statement
Alaska Airlines requires all flight attendants to complete annual recurrent training drills, and, in some cases, requalification training. These classes occurred at all of Alaska Airlines’ bases, on almost every day of the year.
The process of scoring the drills and processing each flight attendant was completely paper-based, and relied on shipping hand-printed forms.
With a paper-based class system, drills could be completed out-of-order, but it was difficult for the drill instructor to determine which drills were completed and which were not. Keeping track of the progress of students could also get complicated and confusing.
To help eliminate errors, the drill instructors had to audit each other’s drills. This proved to be very time-consuming, and not all errors were caught before being sent to the administrators.
After each set of class scores were delivered, the information was entered into a different database by hand. A lot of the data was redundant, with information already stored in the airline’s database.
The system was problematic, and costly mistakes were frequent. The consequences of errors could have significant negative impacts on both the airline and the flight attendants.
The project started with some discovery meetings, and followed up with workshops with stakeholders and contributors
Users and audience
The users of this solution are flight attendants who take duty as drill instructors.
Other users include schedulers, supervisors, and administrators who maintain employee records.
Explorations were made as sketches on graph paper
Roles and responsibilities
My role with this project was Lead UX Designer. I conducted all discovery and research, as well as creating wireframes, mockups, prototypes and facilitating usability testing.
I was part of a product design team responsible for flight-operations-facing digital solutions. In this team I collaborated with other designers on a design system, as well as peer review of our various projects.
These are the steps for a user finding a class from a schedule, and adding instructors to the class
The Solution
My solution was to design a mobile browser-optimized website. I designed it so that any drill instructor could take a company-issued iPad and conduct drills with any flight attendant student.
The drills were conducted on actual equipment in actual aircraft fuselages. The iPad was the ideal device for the instructor to enter scoring data into.
The drill instructor could enter all scoring data and verification for digital handoff through cloud computing.
Redundant data, already existing in current databases, was pulled in automatically. This reduced the time needed to enter data, as well as reducing errors.
From left: the roster display for a class; drill in progress; drills after a few scores have been added
How this solution solved the problem
My solution reduced errors by requiring steps to be completed before moving on. It kept track of completion and scores for the drill instructors. It required validation before submission, thus eliminating the need for auditing scores.
While the legacy process depended on a package of completed scores and classes being shipped, my design allowed instant access to the scores by the administrators and schedulers.
From left: the roster after the class is completed, and all scores are added; the roster during class, displaying some students in progress, and some absent; the view of a completed class as submitted to administrators
Challenges faced
I completed this project during COVID-19 lockdown in 2020-21, so many of the meetings with the stakeholders had to be completed in MS Teams online.
Additionally, the website was to be built from scratch, with starting points from the existing flight attendant website, which was powered by MS Sharepoint.
While I had frequent meetings and demonstrations with the engineering team, I had to explain many of the UI processes and nuances to them, because they were primarily back-end-focused.
The solution was dependent on a partially-developed design system, and many of the components had to be created for the unique user requirements of flight attendant training.
In handing off the mockups to developers, I needed to ensure that measurements and behaviors were specified. While we used Sketch and Abstract, there was some information not easily conveyed by those tools.
How the project affected the users and the business
While I completed my time at Alaska Airlines, just before the project was handed off to the engineering team, I was able to conduct comprehensive usability testing in-person with about six actual flight attendants.
The feedback from the final round of usability testing was overwhelmingly positive. The flight attendants who functioned as drill instructors were anxious to start using the tool, as they were aware of the shortcomings of their legacy paper process.
I transferred the project to team members I had collaborated with for the past year. The detail I had added to ensure the research and design were executed properly was noted and appreciated.
I created prototypes to run on iPads for user testing with actual flight attendant instructors. The sample size was about eight, and the sessions were held at the Flight Ops center near the Seattle airport.
Outcomes and lessons
The outcome was resoundingly positive.
I learned how some colors and symbols which I assumed were specific indicators of function, affordance, or semiotics, could be confusing.
Design systems and libraries can support many UX projects, but there are often complicated interactions which can only be achieved by new design exploration.
