dave.

Air Force /
F35 Maintenance

Checkout the official Air Force demo video

Redesigning Flight-Line Maintenance

Personnel management is still an ongoing effort under the “mad hatter” portfolio of apps. you can read about our recent success here, where we saw a 40% increase in time saving, and 115% increase in usability based on the system usability score vs. legacy software in recent tests.

The Problem

The Autonomic Logistics Information System (ALIS) is a slow, confusing, and inaccurate hardware and software system built to be paired with the F-35 Jet.

How bad is it, you say? Here are some quotes to be around the web from the Department of Defense (DoD) community:

“How bad is the F-35’s computerized maintenance system, ALIS? So bad the plane may be better off without it.”

“ALIS’ problems are legion and legendary in the defense acquisition community. New software builds take more than a year to formulate and are often late. Data gaps have caused canceled missions.”

“Nothing about ALIS development mirrored the best practices of the tech community, and the result was “good code in a fairly bad user interface and a bad architecture.”

TIME
1 Year

MY ROLE
Product design
Strategy
Research

The Plan

ALIS is massive system that wasn’t going to be easy to replace. Nine app teams were kicked off over the course of 6 months, each covering their own domain and all working together to change the way the Air Force thinks about Maintenance. I worked on the Athena Team – tasked with managing personnel on the flight line.

Team

We partnered with Pivotal Labs, industry leaders in Software Design and Development, for the first five months. Because of this, there were two product managers, eight developers, and two product designers – myself and my Pivotal Labs counterpart. After five months, we left to go back to Kessel Run HQ, where the team changed to one product manager, four developers, and myself as the sole product designer.

Objective

The simple and efficient management of 

flight-line maintainers.

How We Got There

Field Research

We began with a week-long trip out to Nellis Air Force Base to understand our user’s existing workflows and pain points.

During the project, we conducted bi-weekly zoom calls with our users to further validate our ideas, and took several other research trips to other Bases to ensure our solutions were covering all F-35 Unit’s needs.

Research Artifacts

Two key pieces were our user persona, and a detailed service blueprint. The service blueprint captured each step of our user’s workflow, along with their goals, pains, and systems used to complete said action.

Our user, Sam

Our user, Sam

Two key pieces were our user persona, and a detailed service blueprint. The service blueprint captured each step of our user’s workflow, along with their goals, pains, and systems used to complete said action.

Key Insights

We learned that the primary goal of a Section Chief is be sure they have enough qualified Maintainers on shift to complete the upcoming workload.
Outline of the beginning of the service blueprint we created. The blueprint is read left to right, with each step of a user’s workflow being captured, along with their goals, pains, and systems used to complete said action. For security reasons, i’m unable to upload the actual blueprint mapping their workflow.
Outline of the beginning of the service blueprint we created. The blueprint is read left to right, with each step of a user’s workflow being captured, along with their goals, pains, and systems used to complete said action. For security reasons, i’m unable to upload the actual blueprint mapping their workflow.

Problem 1

Maintainers write their events on a paper logbook (ex: dentist apt on Tuesday), which the Section Chief then input into Excel. Events could be incorrectly entered, and it was hard to track Maintainers down to communicate if their event was approved or denied. To solve this, we gave Maintainers limited access to tentatively add their own events. Section Chiefs would then see the added events, and simply click to approve or deny them. Once a decision was made, a Maintainer would get a notification informing them.

Problem 2

Section Chief’s constantly checked the schedule to make sure they had enough qualified Maintainers on shift. It was hard to keep track, and younger Section Chiefs might approve an event that left them under-staffed. We built a table that added up their necessary Certifications, and alerted them if a pending event would be cause a shortage.

Problem 3

Tracking Maintainer’s training was a tedious process. Section Chiefs had to download, update, and recheck their training progress every week. We are currently in the process of building out an automated system to track what work Maintainers have accomplished, and recommend when they’re due for an upgrade to the next training level.

Result

Default Home Page of Personnel Management, where user can add and manage events, track certifications, and prepare for upcoming staffing shortages.

Home Page with pending events for the supervisor’s approval, as well as notifications of changes to their crew’s events.

In the future, Personnel Management will recommend whether or not the events should be approved, based on existing coverages and upcoming work to be done.

Preview of certification coverage for the upcoming week. Each row represents a certification that a maintainer has been specially trained in.

To complete certain work, it’s required to have a maintainer certified in that work.

Section Chiefs use these certifications as a measurement of their staff health, and whether or not they need to move maintainers around, or deny appointments.

Maintainer’s page, where both they and the Section Chief can add and view appointments, filter by appointment type, and view what type of work they’ve accomplished in the past (still in work).

This previous work history is used to inform Section Chiefs when the maintainers are due for an upgrade to a new level.

Next

GOGov / Permitting

© David Zemsky

Linkedin Envelope