Several years ago, I was on a flight that taught me firsthand about the proper role of automation in our technology. We had been flying since early in the morning from Chester County Airport in Pennsylvania to Monterey Airport in California. I was the second-in-command on this transcontinental flight in a Beechcraft Premier 1A. Because we were flying to the west against the jet stream, our plan required two fuel stops along the way. The first stop in Mosby, Missouri, went as planned without incident. The second stop at Grand Junction, Colorado was doomed from the start. Cruising at 41,000 feet over Kansas we decided to run some performance calculations. When the captain and I calculated the takeoff out of Grand Junction we realized that the runway wasn’t long enough. Normally over 10,000 feet of runway would be plenty. In fact, our home airport had less than 6,000 feet. But Grand Junction sits at a high altitude, which means thinner air, and it was very hot that day, which means the air would be still thinner. This thin air has a compounding effect because the engines have less air to produce thrust and the wings have less air to lift the plane with. We needed to have full fuel tanks or we would need to make another stop along the way. It quickly became clear that Grand Junction was not an option, so we started searching the charts for other airports that might work. The captain and I began doing all of our performance calculations for each airport until we finally found one that met all of our requirements: close enough to get there with the fuel we had, a big enough runway to land and take off with full fuel, and close enough to Monterey to make it there without stopping. This airport was Salt Lake City International in Utah.

We refueled at Salt Lake City and continued on. By the time we reached the airspace near Monterey it had been a very long day. We began the approach to runway 28L with the autopilot following a radio beam called the localizer for lateral navigation. Many airports use another radio beam called the glideslope for vertical navigation. However, this airport has steep terrain on the approach path so the approach involves several vertical steps before landing. These steps are marked waypoints on the map which can be found using several different methods. For our approach we were using the GPS and a database of waypoints to tell the autopilot when to descend. As the aircraft reaches each waypoint it can then begin descending down to the next altitude step. The weather was clear around us but we could see a small layer of clouds closer to the airport. In order to safely (and legally) get through these clouds, we would need to fly the approach procedure very precisely. As the aircraft reached the first step down it was supposed to automatically begin descending, but instead it simply remained level. We scanned the autopilot controls and the flight computer only to find that everything was set correctly. Traveling at such high speeds means that there isn’t time to reset the approach in the computer, and there isn’t much time for troubleshooting. Rather than try to fix the problem, we relied on a simple rule in aviation, “If the pilot ‘gets behind’ the automation or the automation creates excessive workload, remove the automation and fly the aircraft by hand.”

We turned off the autopilot and turned off the vertical navigation coming from the computer. The captain flew the approach by hand while I managed the steps down by giving him visual cues through the flight computer and verbal callouts at each step. If we had tried to fix the automation in flight or work with it as it was, we would be seriously compromising our safety because we are trying to use a system that already has an unknown problem which would give us a higher workload and a much higher chance of making a mistake.

Remove the automation and fly the aircraft by hand

Automation is nice, but it is not capable of handling the infinite situations that the real world presents. In software it is not always possible to provide a way to “turn off” or override automation that is critical to the software. In fact, automation is the very core of software, as it carries out millions of calculations in the blink of an eye. However, there are places where automation is an extra convenience and here we find an opportunity to let the user get past the automation and override it with manual settings.

At work I built a system to import user records between two of our products, and bring all of the user data along too. The two systems had different customizable fields that did not always match. So I built some automation that would look at the names of the fields and bring over exact matches. My code would also make some educated guesses by adding in keywords based on the type of field it was looking for. This automatic system worked great and carried over all of the data for most of our customers. But the few it didn’t work for made me realize that automation was not the miracle cure it seems to be. Some of these clients had fields that sounded like they would refer to two different data points entirely, for example, ‘Remote Work’ mapped over to ‘Laptop Needed’. I resolved this by adding a dropdown menu with the option to explicitly select a field from the other product or choose ‘(Auto)’. This system was able to meet the needs of 90% of the customers through automation, and allowed the other 10% to turn off the automation and make it work for their needs.

When you give the user the ability to get past automation, you are giving them more power and providing the small features that can have a great impact on their experience with your product.