Foundations of Human-Automation Interaction

Deciding which parts of a task go to a person and which go to a machine is called function allocation, and it's older than computing itself as a formal discipline. Paul Fitts led a 1951 study for the National Research Council surveying, in the report's own words, the kinds of things people could do better than the machines of the era, and vice versa, commissioned to fix problems in air navigation and traffic control (Fitts, 1951). The resulting eleven-item comparison became known by an acronym coined almost two decades later: MABA-MABA, Men Are Better At, Machines Are Better At.

The list is intuitive and still widely taught. Machines, Fitts argued, are better at fast, repetitive, high-precision, high-force tasks, and at doing several things at once reliably. People are better at improvising, recognizing unanticipated patterns, and exercising judgment under ambiguity. It became the default starting point for an entire discipline because it was simple enough to actually use, not because it was the last word on the subject.

The list's most obvious weakness is also its most persistent criticism: it's static, a snapshot of what 1951 machines could and couldn't do. Joost de Winter and Peter Hancock tested whether the list still matched modern belief, surveying 249 engineering graduate students plus nearly 3,000 crowdsourced respondents across 103 countries on all eleven of Fitts's original statements. The result reversed Fitts's own assessment on several points: present-day machines are now widely believed to surpass humans at detection, perception, and long-term memory, exactly the kind of pattern-recognition tasks Fitts assigned confidently to the human column (de Winter & Hancock, 2015).

That reversal matters for more than historical interest. If task allocation still defaults to whatever's left over once the obviously-automatable work is assigned, that leftover principle keeps handing people the tasks a machine merely doesn't do yet, rather than the tasks a person is actually suited for.

The next problem with a simple list is that it treats automation as binary: a task is either given to the human or the machine. Thomas Sheridan and William Verplank's 1978 study of undersea teleoperators proposed something more useful, a ten-level scale running from fully manual, level one, through the computer suggesting one option and acting only with human approval, around levels four through six, to fully autonomous action with no human notified at all, level ten (Sheridan & Verplank, 1978).

Most real disagreements about automation are really disagreements about which level is appropriate, not about whether automation belongs at all. That reframing, arguing about degree instead of yes-or-no, is the scale's lasting contribution.

Sheridan and Verplank's scale still treats automation as a single number for the whole task. Raja Parasuraman, Thomas Sheridan, and Christopher Wickens's 2000 model splits it into four independent functions, information acquisition, information analysis, decision and action selection, and action implementation, and argues each one can sit at its own level of automation independently of the other three (Parasuraman et al., 2000).

The loop in FIG. 1 makes this concrete: a system can lean heavily on the machine for sensing and analysis while staying close to fully manual at deciding what to do with that information, the pattern behind the human-in-the-loop checkpoint shown there. That's not a compromise position on some single automation dial. It's an honest description of how most real systems, including most AI-assisted ones today, actually work: four independent settings, not one number.

Lisanne Bainbridge's 1983 paper gave the field its most durable piece of bad news, cited well over a thousand times since and still gaining citations decades later. Automating the routine, easy parts of a job doesn't just remove workload, it removes practice. The operator is left responsible for exactly the tasks that couldn't be automated, the rare, hard, unanticipated ones, using skills that have atrophied from disuse, at the exact moment those skills matter most (Bainbridge, 1983).

This is not an argument against automation. It's an argument that automating a task without also planning for how the human stays capable of the task it didn't automate is an incomplete design.

Every framework in this lesson was built for automation that behaves the same way today as it did yesterday, a fixed decision rule, a fixed sensor. Large language model agents don't hold still. Mica Endsley, whose situation-awareness research anchors the next lesson in this series, published a direct update in 2023 addressing exactly this: what changes for a human teammate when the automation is generative, adaptive, and capable of natural-language explanation rather than a fixed control law (Endsley, 2023).

None of the four frameworks in this lesson stop applying. Function still gets allocated, automation still sits at levels, the four functions still separate, and the ironies of losing practiced skill still apply, arguably more urgently, when the automation itself keeps changing out from under the human relying on it. What's different is that trust, explanation, and situation awareness, the subject of the next lesson in this series, now have to account for a teammate whose behavior isn't fixed.