Before NASCAR switched to digital displays, some drivers rotated their dashboard instrument dials to odd angles. Text on the dials laid sideways or upside down, but the improved user experience warranted the modification.
They weren’t alone. For decades, operators of other race vehicles and even fighter planes performed similar modifications in their dashboards.
One of our test pilots offered me this fact while I was developing an experimental cockpit display for KittyHawk. The test pilots were the primary users of the display, so I relied heavily on their feedback during each design iteration:
“Your display looks fine, but just know I’m hardly ever going to look at it. Most of the time, my eyes are gonna be outside, on the horizon”.
The less time he spent gleaning data from the display before taking action, the better it served his needs. Still, the interface needed to display enough information for him to act appropriately during critical flight phases, or when a life-threatening situation was detected.
I began looking for ways to minimize interaction time – the time between the moment an indication was displayed, and the pilot taking an action. The most important asset in my search became a carefully maintained and updated list of possible user actions.
Besides precisely controlling a high-speed vehicle, pilots and race car drivers are tasked with as little else as possible. A list of user actions for them can be quite short. A fictional list of test pilot actions for a first flight might look like this:
From a list of user actions like this, I would list beneath each action the data needed to select or perform it. For example:
By refining and maintaining a list like this, I could throw out data which could not be sorted under an action. This list helped prevent features from creeping into the scope of the design and increasing visual clutter.
After expanding the list to include action data, I’d go through each item to make sure the “user-derived” form was being displayed. Here’s an example of what I mean by “user-derived”:
In college, I’d buy, repair, and sell some very cheap cars. While driving a newly-repaired car, I would often have to babysit the temperature gauge in order to catch any sudden increase.
I spent a lot of time remembering and comparing the last position of the temperature needle. Temperature was important, but I was missing a gauge which displayed the rate of temperature change. I could have minimized a lot of interaction time with something like this:
In the data list for this car test, “Temperature” is an important item for selection of the action, “Pull Over and Turn off Engine”. The item, “Rate of Temperature” is an important derivative for minimizing interaction time. When absent, the user must derive that themselves.
With the cockpit display, I would step through all the data items early in each design iteration. For each data item, I’d ask the question: Does the user need to read, calculate, or remember past states before using this data? If so, I’d modify the data list to include the user-derived form of that data.
Through this process, I found often that a good interface became understandable as a still image, i.e. when it was not running and animated.
We’re used to animated cues in our smartphone, tablet, and computer interfaces. An animation can be a natural way to indicate the direction of motion, but it increases interaction time. If an interface can be glanced at, instead of watched, the time needed to use it is minimized.
Many pilots learn to regularly scan over their instrument panels in a methodical sweep, checking if anything is abnormal, and updating their mental model of the aircraft. The less distance they have to look down, and the more apparent an abnormal condition is, the shorter their scan takes.
This is why NASCAR and other race vehicle operators customized their dials. Each dial was rotated so that all the needles on their engine and speed gauges should be pointing up during critical moments in the race. It was easy to notice with a quick glance if any dial needles were not vertical. Researchers have studied, and validated this practice as a fast way to pick out abnormal dials (Warrick and Grether 1948).
Aircraft often use a “Master Caution” light, close to a neutral line of sight as a general indicator for the pilot to inspect all instruments for warnings. A warning tone might accompany or replace the light to make sure the pilot notices.
This is not overkill. Lights and colors which seem very bold and obvious at the test bench are invisible to a user whose gaze is focused elsewhere. Rather than expect attentiveness, I found it necessary to grab attention when its absolutely needed.
Sometimes the amount of data displayed can be reduced through grouping. Compare these two interfaces for a crew alert system:
This example might be a bit exaggerated, but the point is this: If extra information doesn’t change the action taken, it might not be necessary. Reducing data keeps the display picture simple, and makes it easy to scan.
That was my process for a single design iteration for the cockpit display. If I were to advise someone in a similar design I’d repeat these most important points:
In my experience, no matter how well thought out an interface is, or how sound the theory behind it, nothing substitutes actual testing, refinement, and iteration.
