Fleet Maintenance

Overview

ROLE

Lead Designer

American Airlines currently has a fleet of 956 aircraft. Each plane is made up of millions of parts, and many are regularly replaced with new parts, or sent out for repair.  Each part must go through a receiving and inspection process prior to going back into inventory. The process relies on a legacy green-screen program built in the 1960s called "SCEPTRE", where the experience and operational efficiency is as evil as the name sounds.

Our mission is to overhaul the system with the goals of decreasing part receipt time, lowering training costs, and boosting employee morale.  Over the past year, I've lead a 30-person team through the design of the new application that will replace the legacy system as the center of the user experience for 100+ specialized employees.

My responsibilities on the account have grown to include establishing AA's first internal design system, which will help the designers and developers of this department scale across applications within their ecosystem.

DEPART

Today, when receiving or inspecting a part our users must complete from memory a particular sequence of standalone SCEPTRE screens based on the type of part they're dealing with.  The cognitive load, visual presentation, and data entry redundancy slows down operational efficiency and weakens morale. It takes someone a year to become proficient.

ARRIVE

The new web app will walk Logistics Specialists & Inspectors through their core workflows, employing progressive disclosure to present info and tasks right when they're needed, with the aim of reducing cognitive overload, and improving operational efficiency. I built this prototype in Origami.

Getting There

On Day 1 of the project, we jumped into the deep end with our primary end users, Material Logistic Specialists (MLS), and Quality Control Inspectors (QC).  At the time, we understood very little about their world other than the facts that their jobs require a lot of data entry.

It didn't take long to gain an appreciation for the incredible level of detail required to review, receive, and inspect an entire universe of airplane parts that could be delivered at any moment. 

A busy, but normal workload. As floor space dimishes, it becomes harder to navigate and find the items you're receiving or inspecting.

A QC Inspector reviews an inflatable slide, making sure the correct maintenance actions were completed and there are no defects.

A MLS person starts breaking down a large pallet of goods that he will then review and complete the Initial Receipt into SCEPTRE. 

We started noticing how much the MLS and QC folks move back and forth between the floor and their designated workstations. This forces our users to commute multiple times between the two locations for most orders. 

The cognitive load created by SCEPTRE was evidenced by lengthy cheat sheets every user had pinned up in their space, resulting in a disdain for the system.

At the end of the two days, we had collected an immense amount of qualitative data to distill.  As I headed home, I kept thinking about one particular quote by an Inspector... 

"I want receiving and inspecting a part to be as simple as ordering a pizza on the Papa John's website. Just walk me through the steps." - Inspector

Unpacking & Ideation

The next day, I guided the team through an ideation exercise that used notes and observations from our shared immersion as a jumping off point. I seeded the exercise with demonstrating a basic product storyboard, and then asked each person to spend 10 minutes sketching a solution free of tech or budget constraints to solve a pain point or inefficiency we had witnessed. 

Solutions presented ranged from more aspirational AR-based applications, to clever tweaks in the arrangement of the workspace, to more pointed approaches on how a new UI could be laid out.  

A number of challenges and constraints became more clear as we converged on an approach, which would influence our direction. 

• Legacy Technology - SCEPTRE would still be the system of record in the backend. This meant that we would be influenced by the requirements and processes of that system.
  
  
• Legacy Thinking & Processes - Some of our key business stakeholders have worked for the company for 20+ years, which could be difficult when challenging the status quo.
  
  
• Vendor Integration - Minimal system integration with American's vendors meant that our users must continue to operate within a reactive mindset instead of a predictive one.
   
  
• Interdependent Siloed Teams - This project represents one of six in the program. Some teams were creating applications that share the same users, yet strategy and communication between the groups could be unclear.
  
  
• Union Employees - Our end-users belong to a strong Union.  There was a good degree of sensitivity to change, along with usability testing which we would have to  work around. 
  
  
• FAA Regulations - Oftentime as regulation would prevent us from pursuing certain design approaches.

Working Process

Due to our constraints, we decided that we would first build a progressive web app accessible via desktop that would enable our users to perform their full range of tasks. 

I worked along two talented people on the design front, Mike and Eva. We would travel to Dallas to review incredibly dense business processes with the Business Analysts and Product Owners, write user stories, and return to Chicago to converge on solutions.

We're a team that believes it's important to celebrate our milestones. One night, I was able to bring some of them out to one of my favorite spots, Second City!

Thinking back to the memorable interview quote about making the experience like ordering a pizza online, I set out to establish several guiding design principles.

1.  Minimize Cognitive Load - The new app should lead users through their workflows, and empowering them to focus on what's important.  It should also avoid redundant data entry and make better use of what the system already knows.
   
   
2.  Be Approachable - Our interface should have a friendly voice that asks simple questions, and provides additional context to help the future generation of users understand why they're doing what they're doing. 
   
   
3.  Let Experts Be Experts - For our experience and highly specialized users, we needed to be to ensure a sense of control and freedom.

I explored using cards to serve up the individual tasks to  bring some uniformity around wildly variable content, and several approaches to the navigation to support orientation within the workflow, while also creating a sense of momentum.

Some early wireframes...

Establishing a Visual Identity

After we had the green light on the design approach from our Product Owner, we worked to bring it to life by establishing a visual identity. I provided guidance and worked with a Visual Designer as we first tackled a core  piece of the app: the workflow navigation. 

Once the main navigational flow was vivsually established, the styling of the other UI elements fell in place rather quickly.

Early Iterations

Current Model

Cruising Altitude

After several months, we had created a design framework that enabled us to transform hundreds of independent transactional items in SCEPTRE into three main workflows in our app: 1) The Queues, 2) Receipt, and 2) Inspection.  The Queues would act as a singular point where all Receipt and Inspection flows would begin, and where the final task of Binning would occur.

Evolution of The Runway

On our earliest conceptual designs, I had presented a simple card on the right side of the screen.  Over the course of the project, we adapted the functionality and style many times to act as a task completion tracker and navigational aide. It became a critical piece of the UI that let our Experts be Experts.

We called it the "Runway". 

First Version

Later Version

Over time, we began to notice some inconsistency among the UI elements creeping into our releases.  An internal audit and documentation of our own design, code and guidelines soon blossomed into being hired to lead the creation of a  Design System for the entire program ecosystem. More to come on that in the future as it unfolds! 

Socialization

We recently shared our work with users in Dallas, Phoenix, Tulsa, and Charlotte. Our Product Owner went for a choreographed approach with a tight message, given the union enviornment and sensitivity around change. 

These events  were part pitch deck, part pseudo-usability group session, with a breakout interview at the end. Despite the unconvential format, we were able to bring valuable feedback back into the design process. Specifically, many of the changes to the Runway were influenced by how our users reacted to it.

The overall response was quite positive and validated that our approach to the problem was headed in the right direction! 

Reflection & Looking Ahead

The scale and complexity of this project has pushed me to grow as a designer in multiple ways. Creating and evolving a design framework that could solve for what we had in front of us, but could also handle a world of future unknowns enabled me to be comfortable amongst huge ambiguity more than ever before.

However, my biggest takeway from this project will be an appreciation for how creating change in a large enterprise environment really comes down how well you can manage people and communication more than anything else. Being the lead designer, I was afforded the opportunity to grow those abilities in numerous ways.

This project is still running, with a targeted launch in the next few months. I've transitioned to oversight while I begin taking on the Design System initiative for the entire program. I'm very excited about the learning opportunities it will present!