Delta Airlines Decision Support Tools Brief
The background
There was an initiative at Delta airlines to modernize the information that the dispatchers had in the control tower. The dispatcher is the person at the airline that remains in contact with the pilot of the plane until it lands at its destination. The dispatcher is an employee of the airline (as opposed to the airport or the FAA, like air traffic controllers), and is responsible for many duties for each flight such as coordinating crews, monitoring weight and distribution, making sure that the catering gets there on time, makes the calls on cancellations, manages arrival and departure delays, manages de-icing stops, and more.
In this case, several such tools needed revamping. For a dispatcher, seconds can count, especially when managing multiple planes at the same time. All of this data previously was displayed on the screen in basic tables. Delay times had some visualizations, but at times they only seemed to complicate things. The idea here was to take the data from the tables and display them in such as way that the dispatchers could understand everything with just a quick glance, and make both faster and better decisions.
The problem
If you think in terms of the OODA loop (Observe, Orient, Decide, Act), they had all the data (Orient), but were being asked to make decisions without having a big picture of the Orient step of the loop shown to them. They had to build the picture in their head, or simply use the tables over and over until they got more intuitive with them so that they could do all of the orienting themselves. It’s not easy, and they shouldn’t have to where there are tools to make the decisions for them.
In addition, the dispatchers needed to be able to adjust certain variables and see their impact. Following are some examples of the UI screens designed for them after a number of interview and contextual analysis done with the dispatchers and the UX team.
Gate Capacity
Gate capacity is when an airline has to manage how many gates that they have in use at an airport vs the number of planes that are arriving and departing. If an airline has 100 gates open, most of the time that is plenty, but if during peak times they have more than 100 planes on the ground either waiting to taxi up to the gate, waiting to be cleaned, or waiting to depart, there is a problem.
In this case, the flights must be managed by pushing planes in or out, early or late, in an effort to get the planes to the gates as quickly and efficiently as possible, with less than a 5 minute wait for any plane on the tarmac. This could mean that if a plane is to arrive at gate 21, but the departing plane is still there because it got delayed, the station manager and dispatcher may have to route it to gate 17 at the very last minute because that plane is about to leave.
The original screens that the Station Managers had for gate capacity resembled the middle section of this page (below).
The part that looks like a 5 ine long spreadsheet (plus column headers). That's what they had, a live spreadsheet, hundreds of lines long, and with more columns. Imagine that the columns were not grouped together by function, but rather placed on the screen alphabetically.
THAT was what the Station Managers and dispatchers had to go on in order to make certain decisions. Obviously, not exactly ideal.
My approach here was 4-fold:
Get rid of the columns that don’t really matter to reduce the noise
Organize the columns by function
Show the gate utilization vs capacity at all times so that at any one time a Station Manager or dispatcher knows if things are tight or not, or will be soon.
See the systems' predictions for the future, and read in the systems' recommendations for gate switching and delays in order to maintain efficient gate utilization.
In the mcokup below, the screen is divided into 2 sections:
The “Holdouts and Delay Recommendations” section
The “Gate Capacity” section
(click to enlarge the image)
Let’s start with the Gate Capacity section (the graph on the lower half of the screen). The blue vertical line on the graph represents NOW. Everything to the left is what has happened, and everything to the right represents what is predicted to happen. As you can see, at about 1700 hours, there will be more planes on the ground (170) than there are open gates (160). This means that planes will be waiting around, and this could be a problem.
The graph, unlike a table, shows this information instantly, and it shows exactly HOW bad it will get. Speed and instant situational awareness make all the difference in the world when fast decisions have to be made, and to say that huge spreadsheets do not lend themselves to that is a massive understatement!
The Station Managers and Dispatchers can also see that they have about 4 hours to make adjustments to avoid the situation. This is alsao situational awareness that they simply did not have from combing through spreadsheets.
Jumping back to the part above, the first part has 2 sections:
The 1st section (with the grey areas, and red cells) only contains 3 rows of data. These are the only rows that the dispatcher really needs to have a good situational awareness.
The columns are time columns, by the hour, and the table can actually scroll right or left for up to 12 hours in the past and 24 hours in the future.
The table’s middle row shows the expected Holdouts, or planes that could be waiting on the tarmac.
Anything above 4 is bad, and will be highlighted in red as you see in 3 of the columns, where we have 5, 8, and 8 holdouts, respectively.
When the user clicks on the column where we have holdouts, those holdouts are shown in the table underneath, the 2nd section.
The 2nd section is the raw table (the old spreadsheet UI, but more focused), with the unnecessary columns removed, but JUST for the holdouts in the table above. There is no need for endless rows of data for planes that are not holdouts. We don’t care about those. We only care about the holdouts.
You can see with this screen, we give the station managers and dispatchers exactly what they need, and ONLY what they need in order to assess the situation.
Will there be holdouts?
Who are they?
When will they become holdouts?
How much time do I have, and
How can I manipulate arrivals and delays accordingly to minimize them?
If it’s not a Holdout, we don’t see them in the raw data table.
In the screenshots below, you can see how adjusting input parameters, and giving each one it’s own weight, allowed dispatchers and station managers to recalculate delays in order to minimize them and holdouts. You can scroll through the screens and click on them to enlarge.
Furthermore, an advanced filtering system was put in place in order to allow users to further slice and dice the data, narrowing down the list of resources even further. For example, the user could display in the table:
“Show me only EC2 resources with critical IAM misconfigurations AND critical and high misconfigurations, belonging to the AWS_Production account, and the US-West region”
This wasn’t too bad for a 1.0 release, and it is becoming the new centerpiece for the entire ICS platform.
De-Icing
Below you can see how simply by adjusting the inputs, and running those calculations, the dispatcher can immediately see the affect on de-icing delays vs cancellations. For example in one of them we can see the following:
At the current rate (0 cancellations), the result will be a ~45 minute de-icing delay for all planes that must be accounted for elsewhere.
If we cancel 20 flights, we can bring the de-icing delays down to about 25 minutes.
Cancelling more than 20 flights will not gain us any decrease in de-icing delays
This information can all be gleaned at an instant. No scanning through tables, no making calculations in your head, or anything. Simple, and instantaneous.
Tankering
The last example here is Tankering, or fueling. For this example, you can click here to see a PDF of the basic brief that I gave the project leader and stakeholders after I had conducted my dispatcher interviews during discovery (please excuse the typos in the document).
The screens in the brief were a low-fidelity first iteration pass, which I completed right before my contract ended.
The important part was to show that my solution would be able to meet all of the dispatchers needs and sensitive points. This allowed the dispatchers to constantly observe the fuelling situations, and gave them the support that they needed to make decisions such as "do we fill up in Atlanta for the whole trip, or fly on a partial tank and fill up during the Minneapolis stop-over on the way to LAX?" The tool took into account weight, flying efficiency and fuel economy, local fuel prices, and more to generate these calculations.
Prior to this project, the dispatchers made use of multiple tools and had to make the connections between what one tool showed and what another did in their heads. The final product was much nicer looking (this was really medium-fidelity) and included an on-screen widget that could be torn out of the browser window so that the dispatchers could always see when there was going to be a fueling issue with any flights at any time giving them a very high degree of constant situational awareness.