The alarm that everyone missed
An alarm sounds in a busy control room.
No one responds.
Afterward, the event is described as human error.
The phrase is tidy.
It says very little.
How many alarms had sounded in the previous hour?
How often were they false?
What else were the operators doing?
Was the critical signal distinguishable from routine noise?
Did the interface support attention or consume it?
Had automation changed the operator's role from active control to passive monitoring, a task humans are not especially good at sustaining indefinitely?
Was the system designed for the human beings who would actually have to use it under pressure?
Human factors begins by asking these questions before turning the person into the explanation.
Definition
Human factors and ergonomics is the scientific discipline concerned with understanding interactions among humans and other elements of a system, and applying that knowledge to design in order to optimize human wellbeing and overall system performance.
The International Ergonomics Association uses this definition, and the International Labour Organization similarly emphasizes a systems approach, design, and the joint goals of performance and wellbeing.
Human capability is broader and less standardized.
In this page it means the task-relevant ability of people to perceive, attend, remember, decide, coordinate, act, adapt, and recover within real conditions.
The important phrase is within real conditions.
Capability is not what an ideal person can do in a quiet laboratory with unlimited time.
It is what people can do reliably while tired, interrupted, pressured, learning, collaborating, using tools, and confronting uncertainty.
Human error is often system information
Human factors does not deny that people make mistakes.
It asks why a particular mistake became likely.
A confusing label can create selection error.
A badly placed control can invite the wrong action.
A warning system with too many false alarms can train inattention.
An interface that hides system state can leave operators unable to build an accurate mental model.
A workflow that requires constant interruption can degrade memory for the primary task.
The system can exceed human limits and then misname the predictable result as human error.
This is a profound ethical shift.
It moves responsibility upstream into design, organization, staffing, training, workload, and governance.
Capability is not maximum performance
Organizations often design around peak performance.
The best operator can handle it.
The experienced nurse can remember it.
The senior analyst knows the workaround.
The expert pilot catches the anomaly.
But safe systems cannot depend on everyone performing like the best person on their best day.
Human capability fluctuates with sleep, stress, illness, experience, age, familiarity, workload, social pressure, and task design.
This does not make capability unreliable.
It makes context part of capability.
A serious design asks not only what a person can do, but under what conditions they can do it well enough, often enough, and safely enough.
Automation changes the human job
Parasuraman, Sheridan, and Wickens showed that automation can operate across several functions: information acquisition, information analysis, decision and action selection, and action implementation.
When a function is automated, the human role changes.
Sometimes workload falls.
Sometimes a new monitoring burden appears.
Sometimes skill is used less often and becomes harder to retrieve in emergencies.
Sometimes automation makes routine performance excellent while making rare recovery more difficult.
Parasuraman and Manzey's review of complacency and automation bias shows why simple instructions to “stay vigilant” are not enough. People can over-rely on automation, miss failures, or follow incorrect recommendations under specific task conditions, including when they are experienced.
This matters enormously for AI.
The relevant question is not whether the human remains in the loop.
It is what work the loop requires from the human.
The capability paradox
Automation can reduce demand and increase the importance of the remaining human task at the same time.
An AI system may handle ninety-five percent of routine cases.
The human receives the unusual five percent.
Their workload is smaller in volume but harder in complexity.
They have fewer opportunities to practice routine judgment, yet greater responsibility when the system is uncertain.
This is the capability paradox of advanced automation.
The more competent the system becomes at ordinary work, the more human capability may be concentrated around exception handling, sense-making, moral judgment, communication, and recovery.
These capacities are difficult to preserve if the work environment rarely exercises them.
Human factors meets Inner Technology
Human factors traditionally asks how systems should be designed around human characteristics.
Inner Technology adds a developmental question.
What capacities should the system help preserve?
If automation removes routine effort, what should humans practice instead?
If monitoring becomes central, how should attention be supported?
If AI provides recommendations, how should trust be calibrated?
If people need to challenge a model, what knowledge and authority do they require?
If emergency recovery remains human, how is recovery skill maintained when normal operation is automated?
The connection is not that human factors becomes self-development.
It is that system design and capacity development become inseparable when the system changes what humans need to be able to do.
The body remains part of system performance
Human factors has always taken the body seriously.
Posture matters.
Reach matters.
Vision matters.
Fatigue matters.
Noise matters.
Heat matters.
Pain matters.
So do cognitive and psychosocial conditions.
This is a useful corrective to digital systems that imagine work as disembodied information processing.
A person does not become infinitely scalable because the interface is software.
They still need sleep.
They still have limited attention.
They still experience threat, status, boredom, uncertainty, and overload.
The human operator is an organism inside a social system, not a cursor endpoint.
Capability and accessibility
Designing for human capability also means refusing the fiction of one standard body or mind.
Accessibility is not an edge case.
Different users may require different sensory channels, pacing, language, input methods, cognitive supports, or levels of assistance.
A technology can extend capability rather than merely accommodate limitation.
Screen readers, speech interfaces, alternative input devices, translation, memory support, and adaptive interfaces can expand real participation.
This is one reason the Institute avoids treating unaided performance as the gold standard.
Human capability has always been tool-supported.
The question is whether the support enlarges meaningful action and whether dependence is safe, understood, and governable.
Capability at the team level
Some tasks are beyond any individual.
Surgery, aviation, emergency response, scientific research, infrastructure control, and complex public administration depend on teams.
Capability then becomes collective.
Can the team form shared situation awareness?
Can uncertainty travel upward?
Can a junior person interrupt a senior one?
Can responsibility be located when multiple systems and specialists contribute?
Can the group recover from a surprising event?
A team with highly capable individuals can still fail if coordination architecture is poor.
Human factors therefore makes an important contribution to the Institute's move from person to institution.
Collective capacity is designed through roles, communication, tools, norms, and authority.
Graceful degradation is a human-capability property
The most revealing moment in a human-machine system may be the moment when the system stops behaving as expected.
Routine conditions can conceal fragility. A workflow may look efficient while automation is accurate, connectivity is stable, staffing is normal, and the case fits the categories the interface was built to recognize. The true capability of the system appears when one of those assumptions breaks.
Can a person understand what has failed? Is there a safe fallback? Has skill been maintained well enough to intervene? Does the interface reveal uncertainty, or does it continue to look authoritative while its reliability is falling? Can the team redistribute work without turning one operator into the final absorber of every exception?
Human factors has long treated system performance as a property of interactions rather than of isolated components. In an AI-mediated environment, this points toward graceful degradation as a capability question. A capable system does not merely perform well when everything works. It fails in ways that leave humans enough information, authority, time, and retained competence to recover.
That is a stricter standard than usability. It asks whether the relationship between person and system remains intelligible under pressure.
How should human capability be measured?
By task, context, and outcome.
Measures may include accuracy, time, workload, error, recovery, situation awareness, physical strain, usability, trust calibration, learning, transfer, and resilience to failure.
No single measure captures capability.
A system can increase speed while reducing understanding.
It can reduce workload while increasing complacency.
It can improve average accuracy while making rare failures harder to detect.
It can improve performance with the tool while leaving the person less capable without it.
These are different findings.
Good evaluation keeps them separate.
AI shifts the bottleneck toward exceptions
Automation often changes the human job rather than removing it.
When a system performs routine classification or generation well, the remaining human work can become disproportionately concentrated in ambiguity, exceptions, conflict, recovery, and cases where the model is uncertain or wrong.
That creates a capability paradox. The person may get less everyday practice at the underlying task precisely while being expected to intervene competently in the hardest versions of it.
A reviewer who rarely writes from scratch may still need enough authorship skill to recognize a persuasive but incoherent draft. A clinician using decision support may need less routine pattern matching while retaining the ability to recognize when the system's pattern is inappropriate. A public-sector worker may process fewer ordinary cases and spend more time with citizens whose lives do not fit standardized categories.
This is why capability preservation belongs beside workload reduction. A system can reduce average effort and still increase the importance of rare human expertise.
Designing for capability preservation
Capability-preserving design asks what must remain practiced because the human will still be responsible when the easy path fails.
That may require simulation, deliberate manual practice, rotation through tasks, transparent system feedback, or workflow designs that keep relevant causal structure visible rather than hiding it behind a recommendation.
The aim is not nostalgic manual work. It is graceful degradation.
If the automation becomes unavailable, unreliable, or inappropriate, can the person and team still understand enough of the situation to recover?
This is a human-factors question and a developmental one. It asks whether immediate efficiency is being purchased by creating a future point of fragility.
What the evidence does not show
Human factors does not imply that all failure is caused by design.
People remain responsible actors.
Nor does it prove that more human control is always safer. Well-designed automation can outperform humans in many functions and can protect people from fatigue, inconsistency, and overload.
The evidence does not support a simple manual-good, automated-bad distinction.
It also does not justify broad claims about “human capability” without specifying the capability in question.
And it does not show that a system optimized for performance in one environment will remain safe when workload, population, incentives, or context change.
What this changes for Inner Technology
Human factors gives Inner Technology a necessary external discipline.
It prevents capacity language from becoming a polite way to tell people to adapt to badly designed systems. If attention is continually fragmented by workflow design, the first intervention may belong in the workflow. If a citizen cannot understand a process because the process is incoherent, the answer is not attention training.
Inner Technology adds the reciprocal question: after the system is redesigned, which capacities still need deliberate cultivation because they remain part of responsible human performance?
The relationship is therefore not person versus system.
It is co-design across timescales: design the environment for real human limits now, and preserve the capacities humans will need when the environment changes, the tool fails, or judgment cannot be automated.
Designing for the person who will actually be there
The alarm sounds again.
This time it is rare enough to matter.
The display makes the state legible.
The operator has practiced the recovery.
The team knows who can stop the process.
The workload leaves enough attention to notice.
The system has been designed for a real person rather than an imaginary flawless one.
That is not lowering standards.
It is what serious standards look like when the human being is treated as part of the system.
Research references
- Babaei, E., Dingler, T., Tag, B., & Velloso, E. (2025). Should we use the NASA-TLX in HCI? A review of theoretical and methodological issues around Mental Workload Measurement. International Journal of Human-Computer Studies, 201, 103515. https://doi.org/10.1016/j.ijhcs.2025.103515
- International Ergonomics Association. What Is Ergonomics (HFE)? https://iea.cc/about/what-is-ergonomics/
- International Labour Organization. Human Factors and Ergonomics. https://www.ilo.org/ergonomics
- ISO 26800:2011. Ergonomics, General approach, principles and concepts.
- Parasuraman, R., Sheridan, T. B., & Wickens, C. D. (2000). A model for types and levels of human interaction with automation. https://doi.org/10.1109/3468.844354
- Parasuraman, R., & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation. https://doi.org/10.1177/0018720810376055
- ISO 9241-210:2019. Human-centred design for interactive systems. https://www.iso.org/standard/77520.html