#3: App Design

This airline fuel tracking application is designed to allow flight operations engineers to monitor fuel policy performance. The project includes field research at an airline and a partner design relationship for better ideation and synthesis.

Skills Used: User Research, Interaction Design, Visual Design, Design Workshop Leadership

Research

Airlines have fuel policies that are designed to provide guidance on how flight engineers, dispatchers, and pilots can save fuel. Performance of these policies are difficult to measure, and researching new opportunities to save fuel is time consuming. Many potential policies aren’t looked at in detail, or are very difficult to measure in the context of a specific airline’s operations.

An airline consulting organization came to our team requesting we review their app designs and provide a new design.

Team

I was assigned to lead this design project with a second designer working part-time to help me strategize and review options. A third analyst and designer worked on detailed designs once we had our initial design structure in place.

Review Existing Designs

The app’s current designs were modeled after a Tableau canvas. I wanted to improve the flow through the application, add a grid structure, update the color palette to an in-work corporate standard, and generally improve the clarity of the design.

Journey Map

We talked to flight operations engineers and looked at the customer journey, which highlighted the biggest pain points included: trust between multiple people in the airline organization, seeing a comprehensive summary of what was going on, and being able to monitor if savings in one area was simple adding cost to another area.

Notes, Sketches, & Wireframes

We started wireframing, my design partner and I, adapting the design to include the desired features, reworking the design to incorporate findings and improve simplicity. We knew we wanted to communicate the variety of ways, or "lenses" with which to view this fuel information, but needed to further refine the design, so as to provide density without too much noise.

A first breakthrough came when we realized it might be possible to take the map out of the box, and give it more space, linking it to the end of the window, rather than putting it in its own little box.

A second breakthrough came when we realized that the list was needed to rack-and-stack every “lens” used to look at the problem. “Lens” examples included: a list of flights, a list of airports, a list of aircraft, a list of routes. Each of these lists of information needed to be easily racked-and-stacked, not unlike the list one might see when searching for a good restaurant or a new house. At first, we envisioned an app where the panels floated left when clicked, revealing the next level of detail, similar to how Zillow’s app was working at the time. And, some of the early bar graphs were inspired by the way Mint’s app was working.

Paper Prototyping

We did paper prototyping to see how it would feel to layout the information in a dozen or so different ways, and determine which patterns would be needed, and how they could interact with each other. My design partner and I decided to create a list on the left, and provide a panel that could be pulled out to display box-plot information in cases where the user was on a large desktop display. The map would use as much of the window as was possible.

Information Architecture & Mockups

As we found our way through a couple of the core screens, we were also working through iterations of the information architecture of the application to get the feeling we wanted.

We started with some high level concepts we wanted the flow to capture.

Then we thought about how these things could interact together, and what types of screen configurations we’d need to show to communicate this to the development team. We ended up at this idea: high level group exploration, medium level group analysis, and detail level individual flight information. With this model, a user could get a high level summary, and quickly go to specific details to see and learn why.

We used this information architecture to created a single PDF in Illustrator that we updated every few days with our business analyst, so she could see progress on the design, and write technical specifications for the development team.

Visual Design

We also established a visual design that was in line with the Boeing brand, using a standard color palette and font settings.

Divide & Conquer

In addition to these screens, another designer was working on detailed screens for each policy optimization. He took the Tableau canvas idea, and visually organized it using our style and formatting rules. We had collaboration sessions each week, and in the end the two fit together perfectly. His strength as a data scientist creating detailed screens worked really well once he had a framework for visual design, and a set of questions to answer for each screen. Our strength as providing information architecture hierarchy helped his screens make sense in their new, cleaner context. 

Design Evolution

We had taken what was a design of only detailed Tableau-like analyses and broken it into logical pieces: "all flights" a general summary and exploration of flights; "flight group" a collection of specific optimizations for a group of flights; and "single flight" detailed analyses for each flight; We included full rack-and-stack, filter, and export capability at each step.

This logical flow made it much easier to recognize where savings were located within the larger airline, and then see either which group of flights or which flights are contributors.

Mock-Up Evolution

The mock-ups evolved, a few features at a time, to add functionality, and incorporate desired business requirements. Here are some of the concept screens in greater detail, mocked-up on the smallest screen size that we envisioned. Larger screens would provide longer lists, and larger maps.

These design concepts were used to inform the design of the application for discussions with an airline partner.

The project was then handed to an external consultancy to partner with a new technology vendor to create a test application. Finally, it was handed off to a development team overseas to turn the prototype software to production quality.