Building MxHub

MxHub is a new internal application that was created within Alaska Airlines for the maintenance and engineering department. As the lead designer on the team, I was responsible for designing all aspects of the MVP.

Background

Alaska Airlines is a Seattle-based transportation company. MxHub is our new internal application for supporting aircraft engineers, who are responsible for fixing aircraft issues and keeping planes safe.

Our goal is to identify key usability issues within the current process and integrate existing software into one intuitive tool that allows engineers to move through their workflows seamlessly. By improving the efficiency of this department, we will minimize the time each aircraft is out of commission, saving both time and money.

My Role & Contributions

Research & UX/UI Design

While I started as one of three designers, in less than a year, I became the lead designer on the project, with a team of two product owners, a scrum master, and four developers. This meant being responsible for every aspect of our product; from UX research and strategy to pixel-perfect delivery.

The Process

Our team works within an agile process of 2 weeks sprints. The design process is based on the double diamond method and lean UX process. We aim to incorporate the key phases of discovery, definition, development, and delivery in all our epics.

The Problem

The maintenance and engineering department is in dire need of a tech overhaul. The current process is fragmented, requiring users to go between several different tools in order to complete their work. Additionally, many of these are not mobile-friendly, which limits a technician’s resources while out on the aircraft.

Prioritization

In building out a brand-new application it is important to understand the main goals in order to stay focused. As part of our strategy, we did several rounds of affinity mapping, outlining the high-level goals of our application and features that would support those goals.

Research & Scope

After going through several hours of demos and interviews with different stakeholders outlining the current tools, I was able to map out the problem that each tool was trying to solve as well as the limitations of that tool.

I used personas and journey maps to analyze areas of opportunity and major pain points. Our first task was to replace the primary tool outlining aircraft, flight, and maintenance information. This decision was based on the business's need to retire that software, as well as user research outlining its value.

Methods:

User interviews (in-person and virtual)
Surveys
Forums (demos, etc)
Behavioral Observations (Site visits at several airports)

Goals:

Understand user’s mental models, goals, and needs
Discover pain points and opportunities in the user journey (software limitations, process inefficiencies)
Determine the best path forward to deliver the most value to users in our MVP

User Flow

Aircraft logistics is a complex system. Within our user groups, there are different types of technicians, two different companies Alaska and horizon, and various station sizes and locations, each with their own localized processes that affect maintenance workflows. The flow below represents how technicians resolve one type of maintenance issue. However, there are many more flows to be considered for our product.

Information Architecture

While previous solutions treated the aircraft as the central container in which everything else revolved, deeper research revealed the individual maintenance issues to be the most central. This pattern is similar to the information architecture and UI of a task management system, where items are broken out into cards and boards.

Since resources and status center around each aircraft, it makes sense for each aircraft to have a dashboard view, with each maintenance issue being listed as its own card, opening to reveal further details, the status of completion, attachments, comments, and resources.

Adapting UI Patterns

Looking at the goals of our application I was especially inspired by UI patterns in task management systems. These products have features most aligned with the goals of our own, such as sharing status, assigning work, and communicating with different stakeholders.

Wireframing Solutions

Deciding on the layouts and user workflows involved several rounds of low-fidelity iterations and testing. These wireframes served to shape the eventual solution. In addition to gathering feedback and doing research, many of the decisions were influenced by the design system of Alaska Airlines as a whole.

In an effort to keep consistency across various internal tools, the company decided to stay as close to Native iOS styles as possible. While the majority of our components were custom-made to accommodate our use case; elements such as modals, navigation, and overall UI patterns were based on Apple’s Human Interface Guidelines.

Testing

Designs were validated through user testing of low-fidelity concepts and high-fidelity prototypes. In addition to conducting various virtual tests and surveys through Maze; I traveled to several stations, doing in-person usability testing in order to listen and observe how users interact with our application.

As part of measuring the progress of our product, I sent out quarterly SUS and CSAT surveys. These have resulted in an average of 8 out of 10 satisfaction rating. Since its implementation, engagement with users continues to increase as we receive positive feedback.

Mockups

As the first version of our app, features are constantly being added and designs updated. The mockups below are a snapshot of the main pages within the application: listing out incoming aircraft, outlining maintenance work that must be completed, and demonstrating troubleshooting and collaborating around individual issues.

1. Aircraft List
2. Aircraft Details
3. Deferred Issue Details
4. Troubleshooting Issues

Shipping the Product

Participating in refinement sessions, agile rituals, and the QA process has been as an integral part of my role as the designer for the product. I worked closely with developers; providing clarity around specifications, and analyzing the QA build. Once the design intent was delivered, the beta version was sent out to select users for feedback, then to all users via a general release. This video demonstration was used to educate users on how to utilize the application.

Conclusion

Takeaways:

Define the problem first. Prior to diving into specific features always take a step back to view the high-level issues and define the problem. This allows you to question assumptions and broaden.
Narrow scope while preparing for future iterations. Given limited resources it is important to make strategic decisions in order to deliver value quickly, building foundational patterns for future versions.
Honor user research. Throughout this process, there were times when stakeholders pushed solutions that contradicted user research. These solutions cost significant time and money and upon completion, were not able to be implemented due to user rejection.
Involve engineering upfront. This helps to reduce any rework later on as understanding of the technical limitations upfront will help inform design strategy.

Future Developments

As the lead designer, I continue to work closely with the product owners and leadership to help shape the roadmap. While our MVP has come a long way, there is still much to do. We will continue to absorb the functionality of antiquated programs, redesigning and integrating them into our application. Some of this future work includes:

Adding aircraft history
Increasing functions within the activity feed and collaboration feature
Automating manual searches
Allowing leads to assign technicians
Creating a digital logbook
Continually improving existing features