Loading field map
Human factors in human-computer interaction begins with a persistent tension: how should designers model the people who will use their systems? The answer determines what counts as a design problem, what methods are appropriate, and what success looks like. Over four decades, researchers have offered competing answers, each expanding or narrowing the scope of human capabilities that technology must accommodate.
In the early 1980s, the dominant approach imported models from cognitive psychology. Human Information Processing (HIP) treated the user as a system that receives input, processes it through limited-capacity channels (attention, memory, reasoning), and produces output. The goal was to predict human performance—reaction times, error rates, task completion times—with enough precision to guide interface design.
HIP produced concrete engineering tools. The GOMS family of models (Goals, Operators, Methods, Selection rules) allowed designers to estimate how long an expert user would take to complete a task by decomposing it into keystroke-level operations. Fitts' law predicted pointing time based on target size and distance. These methods worked well for tasks with well-defined procedures, such as data entry, telephone operator consoles, or aircraft cockpit procedures. The journal Human Factors, founded in 1958, had long published such quantitative studies, and HIP gave HCI researchers a rigorous vocabulary to join that tradition.
Yet HIP's strength was also its limitation. By focusing on the individual mind as an isolated processor, it had little to say about collaboration, about the physical environment, or about how people actually adapt their behavior when tools and colleagues are present. A designer using GOMS could predict how fast a single user could dial a phone number, but not why a team of air-traffic controllers might develop a shared shorthand that bypassed the interface entirely. By the late 1980s, researchers began to ask whether the unit of analysis should be larger.
Distributed Cognition (DCog) emerged in the early 1990s as a direct response to HIP's individualist framing. Edwin Hutchins, in his studies of naval navigation teams, showed that cognitive work is not confined to individual minds but is distributed across people, tools, representations, and the environment. A ship's navigation team does not compute position inside each member's head; the computation is spread across charts, alidades, radio communications, and the coordinated activity of the group.
DCog shifted the unit of design analysis from the individual user to the socio-technical system. Its methods were ethnographic: researchers observed real work settings, traced how information moved through artifacts and conversations, and identified breakdowns where the distribution of cognition failed. This made DCog especially influential in Computer-Supported Cooperative Work (CSCW), where the design challenge is not a single interface but a constellation of tools used by multiple people with overlapping goals. A DCog analysis might reveal that a hospital's electronic health record system forces nurses to memorize information that the paper chart had made visible to everyone in the room—a design problem invisible to HIP's individual-task models.
DCog did not reject HIP's findings about human memory limits or attention. Instead, it argued that those limits are best understood in context: people offload memory onto sticky notes, coordinate attention through gesture, and build shared representations that no single individual holds. The designer's job, from a DCog perspective, is to support these distributed processes rather than optimize a single user's task time.
At roughly the same time, a different reaction to HIP was taking shape. Ecological Interface Design (EID) drew on James Gibson's ecological psychology, which argued that perception is direct: organisms pick up information from the environment without internal mental computation. For EID, the design problem was not to model the user's internal processing but to make the work domain's constraints directly perceptible.
The key method was the Abstraction Hierarchy, a multi-level representation of a complex system (such as a nuclear power plant or chemical refinery) that connects high-level functional purposes to low-level physical components. An EID interface displays these relationships visually, so operators can see, for example, that a temperature increase in one part of the process threatens the plant's overall safety goal. The operator does not need to hold a mental model of the system; the interface itself reveals the constraints.
EID retained HIP's concern with operator performance in safety-critical domains—aviation, process control, anesthesiology—but changed the theoretical lens. Where HIP asked how fast an operator could read a gauge and compute a response, EID asked whether the gauge could be redesigned so that the operator simply saw the problem. The two frameworks thus addressed the same class of problems (high-stakes, time-pressured work) with different assumptions about human cognition. EID's focus on direct perception made it especially effective for supervisory control, where operators monitor automated systems and must detect rare but critical anomalies.
By the early 2000s, a third reaction had gathered force. User Experience Design (UXD) argued that human factors should not be limited to task performance, error reduction, or even distributed cognition. People use technology for pleasure, identity, social connection, and aesthetic satisfaction. A system that is efficient but frustrating, or functional but joyless, has failed on dimensions that matter to users.
UXD broadened the goals of human factors to include subjective experience: emotion, meaning, delight, trust, and long-term engagement. Its methods—personas, journey maps, experience prototypes, and usability testing that probes satisfaction as well as task completion—were designed to capture what it feels like to use a system, not just how quickly a task can be done. In commercial settings, UXD became dominant because it aligned with business goals: a positive user experience drives adoption, retention, and brand loyalty.
UXD did not replace the earlier frameworks so much as add a new layer of concerns. A safety-critical interface still needs the analytical rigor of HIP or EID; a collaborative tool still benefits from DCog's systemic view. But for consumer software, e-commerce, social media, and entertainment, UXD's emphasis on subjective quality became the primary design lens. The tension between UXD and the older frameworks is not about which is correct but about which dimensions of human experience matter for a given design problem.
Today, all four frameworks remain active, each with a distinct niche. HIP continues in domains where quantitative prediction is essential: military cockpits, medical device interfaces, and any setting where human error has catastrophic consequences. DCog guides the design of collaborative systems, from air-traffic control to open-source software development platforms. EID is the framework of choice for complex process-control environments where operators must manage hundreds of interdependent variables. UXD dominates the commercial web and mobile ecosystem, where emotional engagement and brand experience are paramount.
What the frameworks agree on is that design must be empirically grounded. All four insist that designers should study real users in real contexts, evaluate prototypes systematically, and treat the human as the measure of success. They share a commitment to fitting technology to people rather than the reverse.
Where they disagree is on what counts as the relevant dimension of human experience. For HIP, the relevant dimension is cognitive capacity and task efficiency. For DCog, it is the distribution of cognitive work across people and artifacts. For EID, it is the direct perception of domain constraints. For UXD, it is the holistic subjective experience. These are not competing truths but different lenses, each revealing aspects of human-technology interaction that the others downplay.
The practical consequence is that a designer today must choose a framework based on the problem at hand. A medical device intended for emergency use by a single operator calls for HIP or EID methods. A social platform for collaborative project management calls for DCog. A consumer app for meditation calls for UXD. The frameworks coexist because the questions they answer are genuinely different, and the human factors tradition has learned to value that diversity rather than resolve it into a single orthodoxy.