Edwin Hutchins takes some of the questions of cognitive science, namely “How is information represented, combined, and propagated throughout a system?” and asks it of a “distribute socio-technical system,” a commercial cockpit instead of just an individual.
He further scopes this down to how the wing configuration and speeds are matched during approach and landing.
He takes three different examinations of the same process. The first is purely procedural. It’s the sort of thing you’d find in the manual of the plane (an MD-80) or the way a pilot might explain it to another.
This reminds me a lot of how a run book might be written. It can be useful for communicating some typical process to others with similar training or experience, but doesn’t take into account other factors that may be going on.
Next he focuses on a cognitive description, but only on the representations and processes that are outside of the pilots. This includes things like the card that they need to find that tells the right approach for their gross weight.
He focuses a lot on “speed bugs”. Speed bugs are little sliders that go around the speed gauge and allow you to set them to point at various speed. Most of them are on the outside, but one is on the inside.
The pilots are able to use these to demarcate the various speeds that are important as they prepare for landing. At each of the various speeds they need to change the configuration of the wings to support that speed.
Even though we’re in software, where we may not be able to control the hardware that is being used, we can still create views that help ease the cognitive burden on processing information.
A quick overview of the process
- The pilots look at the current weight on the fuel gauge.
- They open a book of cards and select the one the matches the weight.
- This card contains the various speeds that they’ll need to hit (which also correspond to wing configuration) throughout the overall landing process. They put this card in a place they both can see.
- They set arrow indicators (speed bugs) on the speed gauge to these points, including one inside the gauge for the final landing speed.
They do this process prior to needing it because the weight won’t change much, but closer to landing things will be busier and they’ll need to bring their attention to bear on the task of landing itself.
A division of labor
Finally, he takes a cognitive look at the representations and processes that he can infer go on in the pilots themselves.
In this view, we are shown that the pilots aren’t really remembering the speeds. They may be remembering things like is a given speed fast or slow or how things went the last time they had a given configuration of weight and speed, but the other parts of the system are acting as memory at least for the retrieval of values.
The memory observed in the cockpit is a continual interaction with a world of meaningful structure. The pilots continually are reading and writing, reconstituting and reconstructing the meaning and the organization of both the internal and the external representations of the speeds. It is not just the retrieval of something from an internal storehouse, and not just a recognition or a match of an external form to an internally stored template.
While both pilots, one operating the flight controls and one not, have the same information of the state of the system (the same gauges for example), the pilot not flying helps interpret and translate that information into a medium that the pilot flying can use.
For example, as they begin the last part of landing, the pilot not flying will call out whenever the speed is 5 knots above or below target. This changes what would have otherwise been a very difficult visual task, keep your eyes on the landing environment, but also see the indicator into something much easier and in a different medium. Listen to what the pilot not flying says and adjust accordingly.
Other researchers have highlighted this possibility as well, and I think it’s one that is not well taken advantage of in most software systems, which is to provide more information in a non-visual channel. Interestingly our mobile devices are increasingly doing this, but rarely are desktop type devices.
In some software, Grafana being an example, there seems to be a push away from using audio. There is a feature request from 2016 to have an audio alert, but it’s still open today. I think that this is partly because it’s often used for noisy (in many senses) with a low amount of information provided.
Effective use of audio goes beyond an alert tone when something happens, the beep version of someone saying “hey” can only go so far. Of course this is partly why different tones exist for different items. But beyond that, I could imagine a system that takes advantage of audio in a similar way to mission control voice loops (check out issue 21 for more on mission control and voice loops) where perhaps there is some more information that we could listen to in the background.
Also, it turns out that while not intended by design, the width of the speed bug used for this final speed callout is 10 knots. This created an opportunity for pilots to take advantage of and change the nature of the task again. Instead of doing some small arithmetic continually or counting ticks, they can know the deviation has exceeded the 5 knot buffer in either direction if the needle is no longer in the speed bug.
I think there are a lot of hidden adaptations like this in all sorts of work. It can be difficult, but the processes of discovering them and preserving them or enhancing them can be a great way to improve tooling.
- Cognitive systems can and should be examined beyond the scope of an individual.
- This can reveal insights about the utility of certain parts of the system or ways in which it could be improved
- Things we might think of or call memory aids may aid other things like crosschecking in a cognitive system.
- Parts of a system, like air speed markers, can change the nature of a task making it cognitively easier.
- A procedural description of a task is very different from a cognitive description of the same task.
- Both are needed to effectively design a system.
- Having a second person in the cockpit allows representations to be translated from visual to auditory, helping to prevent overload.
- Various properties of the tools and environment can be utilized to support cognitive work, often beyond the intent of the original design.