How do system demands shape operator performance?

Performance-Shaping Factors Series

NEWSLETTER ARTICLE

Like all complex systems, numerous variables affect operator performance, for good or for bad. This series explores what these performance-shaping factors are, what issues exist because of them, and how they can be optimized.

Lesson 1 – System Demands

Let’s start with a graphics (interface) example.

I was sitting with an operator when I noticed a parameter with engineering units of WOBBE. At the time I did not know what a WOBBE was, so I asked the console operator. He replied, “I don’t know what it is—Let’s ask the head operator.” The head operator came over, adding his expertise, “I don’t know what it is—Let’s trend it.” After calling up the trend display, the head operator exclaimed, “I don’t know what it is, but we seem to be making a lot of them.” How could a parameter meaningless to the operator, likely not used in any task, end up on the display? Could the rationale have been simply that since it was being measured, it should be on a display? It certainly wasn’t going to prompt the operator to perform a task.

The parameter taking up space on this graphic violates a basic human factors design principle: Information must be actionable; it must support a task or function. So when we, as HF professionals, ask about actionable information, what we are really asking is which task or function needs this information? (You may want to ask this about morning reports. I’ve seen pages and pages of shift report content with no clear audience or purpose, but that’s a topic for another time.) 

When proposing this principle once, I was countered by some designers who said that while the information was not used in any task, it might be “nice to know”. Knowledge is infinite, so “nice to know” provides no way to distinguish what should or should not be on displays or in training, etc. Everything might be “nice to know”. Every nice-to-know added to a screen increases visual noise and clutter, making it harder for the operator to find the real information, that which is needed to determine if and what action needs to be taken. During an off-normal event, the graphics are so filled with clutter from these “niceties” that the operator can’t locate the real information he needs to resolve the issue.

Settling the debate . . . 

Focusing on tasks and functions is useful in one of the longer debates in the industry: How many controllers can an operator handle? Controllers enable an operator to enact some change on the process (e.g., take an action). There was an assumption that the number of controllers was indicative of the amount of action the operator needed to take. So higher loop units needed more staff than lower control loop units. But a controller that is never touched because no intervention in the system is needed results in little workload. These are what we call “set and forget”. It is not unusual to find units with low loops and poor automation having higher console workload than units with high loop counts and good automation. Loops are not important, tasks performed by the operator are. 

Lesson 1 Takeaway

A simple first step in designing for the operator is to ask some questions:

• What actions does the operator need to do?
• How does this design element facilitate them taking those actions?

Copyright 2023 Beville Operator Performance Specialists, Inc., All Rights Reserved