#1: App Redesign

Research

Imagine flight 1829 is returning to Oslo at 10:52 PM, with pilot Anders and co-pilot Kjell. During descent, they encounter a flock of birds, and hear a thwack that appears to come from the nose cone. “Birdstrike,” Anders says. “Norwegian 1829 we’ve got a birdstrike,” Kjell says into his headset, to air traffic control. Anders checks to make sure all systems are still functioning. All systems seemed to be operating normally, and within 20 seconds of the event, they proceed with the landing. They switch to tower, land at 01L, and the landing goes smoothly. The 157 passengers disembark at the gate without a worry.

Now, Anders notifies Leif, on the ground crew, of the incident, and marks it in the log book. He goes out with Leif to inspect the aircraft. They investigate and notice that there is a good size dent on the nose cone, and one on the leading edge of the right wing. They inform ground operations that this aircraft will need to go out of service, and Kenneth, from the evening maintenance crew comes out to take a look at the dents, and see if they are outside of the normal size allowed. The one on the nose is too big to allow the aircraft to fly, and the one on the wing is borderline, so a structural repair will be needed. Kenneth notifies Lars in the maintenance office of the structural repair, and sends him measurements and images, so he can see if they need to ask Boeing for help with the repair.

Lars, a structural engineer, looks at Norwegian’s handbook for allowable damages, and begins pulling together the case for this repairs. He’ll need to look at the structural history of the aircraft, which will include rifling through the previous airline’s records, delivered when Norwegian took delivery from the lessor.

Lars' job, assembling this information, isn't easy, and neither is the team back at the Lessor, who will need copies of all these documents, as will every airline that uses this jet during its life. From this aircraft's first days in production, every flight, during every maintenance check, paperwork will be created documenting its physical health and any interesting events that occur.

Maintaining the structural records for every aircraft through multiple owners is currently challenging. Each airline uses maintenance systems, and systems for repair records that aren’t designed to be compatible. These documents often get loaded to a historical record, as PDFs, but visualizing these records is difficult.

Current Product

Software was developed in the early 2000’s to try to digitize the effort of tracking the aircraft asset through its life.

This UI is dated, and clunky to use, making it difficult to maintain these records. To update this interface, our mission was to create a user interface where our maintenance engineers knew they were signing off on accurate repair work, our design engineers knew their aircraft components would fly without error, our bankers (lessors) knew their aircraft assets were maintained well, and our pilots had the confidence of knowing that their aircraft were in great shape for their flights.

Workshop

An in-person workshop was held with representatives from approximately 10 airlines to share their problems, current solutions, and what their ideal solutions would look like. From this workshop, we distilled some major areas for improvement, including determining whether damage would be allowable (for flight) or not, improving the simplicity of reading the reports created, improving system integration (resulting in clarity of knowing the real problem in a fast-paced environment), and improving the ability to quickly integrate the directives, bulletins, and service documents released for each aircraft.

Personas

The primary users of the software include structural engineers at the airline, structural engineers at Boeing, airline mechanics, airline management team, and leasing company personnel. I created a persona artifact to capture this information.

Each of these personas are created to inform the creation of the redesign. How would Stephen like this to function? What feature would Talib most appreciate?

Interviews

Phone interview follow-ups with some of the workshop participants allowed for further exploration of the problems, and screen sharing to capture the UI’s and reporting that they were currently using solve the problems in aircraft structural tracking.

Outcome Map

We took this research and created an outcome map, where user problems were structured under the desired outcomes the software users would like to achieve.

Sketching

Research turned to sketching, and a rough collection of wireframes were produced with pencil, and then with Sketch, to illustrate a sample of the re-thought UI design.

Wireframes 

Based on the relatively extensive research, it was clear that a wide-sweeping software solution was really what the users desired. Something that would help them run their airline, and track their aircraft assets in real-time. These are some of the patterns that would be needed to fully represent the situation in which airline engineers found themselves.

Here’s a sample screen integrating these elements.

The lower right “Diagram” module became the focus of this software project, since what the users desired was outside the scope of this project. We scaled the UI design to fit within management’s appetite and the available talent.

Survey

A survey was sent out with a handful of especially brilliant respondents (from the workshop) commenting on potential UI solutions that the finished design would incorporate.

Each section of the UI was focused on in detail in the survey questions, with each section receiving a few detailed examples. For example, for plane identification in the upper left corner of the diagram, the list of events on the left side, or a pop-up on the aircraft, what information should be contained? Participants looked at multiple samples of each of these, with details, and voted on the best. Then they provided information about what they liked and what was missing for each element.

Pattern Exploration

Additional UI pattern layouts were explored, further exploring the best places to put the details needed to be wrapped up in this UI.

Design

Wireframes to Mock-Ups

Here's a sample wireframe that was converted to a mock-up in Sketch.

Animate

Animation was created in Principle to help the product manager explain how the new UI would function to rooms full of managers.

Redlines

Once the detailed design was approved by the team, the redlines were created and discussed with the development team for work.

New Product

At this phase, this project was evaluated against several hundred other projects, and was put on hold. The learnings from this project will be made available to a future team, and the current software will soldier on for a few more years.

While we make a concentrated effort as designers to stay close to the needs of the users, it's the larger political machinery that ensures they are placed at the right time in the right market.