Ecological interface design
Ecological interface design is an approach to interface design that was introduced specifically for complex sociotechnical, real-time, and dynamic systems. It has been applied in a variety of domains including process control, aviation, and medicine.
EID differs from some interface design methodologies like User-Centered Design in that the focus of the analysis is on the work domain or environment, rather than on the end user or a specific task.
The goal of EID is to make constraints and complex relationships in the work environment perceptually evident to the user. This allows more of users' cognitive resources to be devoted to higher cognitive processes such as problem solving and decision making. EID is based on two key concepts from cognitive engineering research: the Abstraction Hierarchy and the Skills, Rules, Knowledge framework.
By reducing mental workload and supporting knowledge-based reasoning, EID aims to improve user performance and overall system reliability for both anticipated and unanticipated events in a complex system.
Overview
Origin and history of EID
Ecological interface design was proposed as a framework for interface design by Kim Vicente and Jens Rasmussen in the late 80s and early 90s following extensive research into human-system reliability at the Risø National Laboratory in Denmark. The term ecological in EID originates from a school of psychology developed by James J. Gibson known as ecological psychology. This field of psychology focuses on human-environment relationships, in particular in relation to human perception in actual environments rather than in laboratory environments. EID borrows from ecological psychology in that the constraints and relationships of the work environment in a complex system are reflected perceptually in order to shape user behaviour. In order to develop ecological designs, analytical tools developed earlier by researchers at the Risø National Laboratory were adopted, including the Abstraction Hierarchy and the Skills, Rules, Knowledge framework. The EID framework was first applied and evaluated in nuclear power plant systems. These tools are also used in Cognitive work analysis. To date, EID has been applied in a variety of complex systems including computer network management, anaesthesiology, military command and control, and aircraft.Motivation
Rapid advances in technologies along with economic demands have led to a noticeable increase in the complexity of engineering systems. As a result, it is becoming more and more difficult for designers to anticipate events that may occur within such systems. Unanticipated events by definition cannot be specified in advance and thus cannot be prevented through training, procedures, or automation. A complex sociotechnical system designed based solely on known scenarios frequently loses the flexibility to support unforeseen events. System safety is often compromised by the operators’ inability to adapt to new and unfamiliar situations. Ecological interface design attempts to provide the operators with the necessary tools and information to become active problem solvers as opposed to passive monitors, particularly during the development of unforeseen events. Interfaces designed following the EID framework aim to lessen mental workload when dealing with unfamiliar and unanticipated events, which are attributed to increased psychological pressure. In doing so, cognitive resources may be freed up to support efficient problem solving.In addition to providing operators with the means to successfully manage unanticipated events, EID is also proposed for systems that require users to become experts. Through the use of the Abstraction Hierarchy and the Skills, Rules, Knowledge framework, EID enables novice users to more easily acquire advanced mental models that generally take many years of experience and training to develop. Likewise, EID provides a basis for continuous learning and distributed, collaborative work. When faced with complex sociotechnical systems, it is not always possible for designers to ask operators what kinds of information they would like to see since each person understands the system at a different level and will provide very different answers. The EID framework allows designers to determine what kinds of information are required when it is not possible or feasible to ask users. It is not the intention of EID to replace existing design methodologies such as UCD and task analysis, but to complement them.
UCD and EID: Why use EID at all?
As we can see from today’s windows based interfaces User-Centered Design has done an excellent job of identifying user preferences and limitations and incorporating them into the interfaces. In the pre-UCD era, interface design was almost an afterthought to a program and was completely dependent on the programmers while totally neglecting the end user.Benefits of UCD
UCD adds three key ideas:1. That Interface Design is a field on its own because it bridges between humans and the program/environment.
2. That an understanding of human perception, cognition, and behavior is critical to designing interfaces.
3. That much can be learned by getting feedback from the actual users of the interface, at the early design stages, and then testing through various points in the design
But there are some problems in this approach as well.
How is EID relevant?
The UCD approach commonly focuses on single user interactions between the user and the interface which is not enough to deal with today’s increasingly complex systems where centralized control of information is needed and it is displayed on a variety of interfaces in varying detail. EID is a preferable addition to the complex systems’ design process when even very experienced users do not have a complete understanding of how the entire complex system works. It is a known fact that users don’t always understand or even feel the need to understand all the relationships behind the complex processes that they control via their interfaces.Furthermore, the users are not always aware of the constraints that affect the system that they work with, and discovering these constraints can take some extra effort. EID incorporates this constraint based style in the design approach where it examines the constraints of the user domain before getting user input. EID focuses on understanding the complex system – its build, its architecture, and its original intent and then relaying this information to the end user thereby reducing their learning curve and helping them achieve higher level of expertise.
The constraint based style in interface design also facilitates the handling of unanticipated events because, regardless of the event, the constraint is broken and it can be seen by the user who in turn can proactively work with the interface to restore the constraint and fix the system.
This does not in any way take away the usefulness of UCD but stresses the fact that EID offers some unique insight into the design process and it could be used in conjunction with other cognitive engineering techniques to enhance the user interfaces and increase human reliability in human-machine interactions.
The abstraction hierarchy (AH)
The abstraction hierarchy is a 5-level functional decomposition used for modelling the work environment, or more commonly referred to as the work domain, for complex sociotechnical systems. In the EID framework, the AH is used to determine what kinds of information should be displayed on the system interface and how the information should be arranged. The AH describes a system at different levels of abstraction using how and why relationships. Moving down the model levels answers how certain elements in the system are achieved, whereas moving up reveals why certain elements exist. Elements at highest level of the model define the purposes and goals of the system. Elements at the lowest levels of the model indicate and describe the physical components of the system. The how and why relationships are shown on the AH as means-ends links. An AH is typically developed following a systematic approach known as a Work Domain Analysis. It is not uncommon for a Work Domain Analysis to yield multiple AH models; each examining the system at a different level of physical detail defined using another model called the Part-Whole Hierarchy.Each level in the AH is a complete but unique description of the work domain.
Functional purpose
The functional purpose level describes the goals and purposes of the system. An AH typically includes more than one system goal such that the goals conflict or complement each other. The relationships between the goals indicate potential trade-offs and constraints within the work domain of the system. For example, the goals of a refrigerator might be to cool food to a certain temperature while using a minimal amount of electricity.Abstract function
The abstract function level describes the underlying laws and principles that govern the goals of the system. These may be empirical laws in a physical system, judicial laws in a social system, or even economic principles in a commercial system. In general, the laws and principles focus on things that need to be conserved or that flow through the system such as mass. The operation of the refrigerator is governed by the second law of thermodynamics.Generalised function
The generalised function level explains the processes involved in the laws and principles found at the AF level, i.e. how each abstract function is achieved. Causal relationships exist between the elements found at the GF level. The refrigeration cycle in a refrigerator involves pumping heat from an area of low temperature into an area of higher temperature.Physical function
The physical function level reveals the physical components or equipment associated with the processes identified at the GF level. The capabilities and limitations of the components such as maximum capacity are also usually noted in the AH. A refrigerator may consist of heat exchange pipes and a gas compressor that can exert a certain maximum pressure on the cooling medium.Physical form
The physical form level describes the condition, location, and physical appearance of the components shown at the PFn level. In the refrigerator example, the heat exchange pipes and the gas compressor are arranged in a specific manner, basically illustrating the location of the components. Physical characteristics may include things as colour, dimensions, and shape.Causal Abstraction Hierarchy
The hierarchy described before is a functional Abstraction Hierarchy representation. A functional Abstraction Hierarchy emphasizes the "means-ends" or "how/why" links of the hierarchy. These connections are direct and illustrated across the five levels of the Abstraction Hierarchy.As the systems get more and more complex, we need to follow the flow structure as well as to understand how the system works. This is when a causal Abstraction Hierarchy representation becomes necessary. As the flow patterns become increasingly complex and it becomes increasingly difficult to derive the flows directly from the system diagram, we add causal models to the functional models.
The causal models help to detail the flow structure and understand more complex flow patterns within a specified Abstraction Hierarchy level. A causal Abstraction Hierarchy representation has the same structure as a functional Abstraction Hierarchy representation but with causal links drawn. Causal links are also known as "within the level" links. These links show how the processes and flows are connected within each level.
The two representations are closely related but are usually developed separately because doing so results in a clearer model which captures most of the system constraints.
In very elaborate flow systems causal models can be used to simplify or abstract the flows. In such a scenario we may find it easier to identify the main feed and product lines at first, then control lines, emergency supply lines, or emergency shunting lines. Causal links are most useful at the Generalized Function and the Abstract Function levels which show flows of materials, processes, mass, or energy.
The Skills, Rules, Knowledge (SRK) framework
The Skills, Rules, Knowledge framework or SRK taxonomy defines three types of behaviour or psychological processes present in operator information processing. The SRK framework was developed by Rasmussen to help designers combine information requirements for a system and aspects of human cognition. In EID, the SRK framework is used to determine how information should be displayed to take advantage of human perception and psychomotor abilities. By supporting skill- and rule-based behaviours in familiar tasks, more cognitive resources may be devoted to knowledge-based behaviours, which are important for managing unanticipated events. The three categories essentially describe the possible ways in which information, for example, from a human-machine interface is extracted and understood:Skill-based level
A skill-based behaviour represents a type of behaviour that requires very little or no conscious control to perform or execute an action once an intention is formed; also known as a sensorimotor behaviour. Performance is smooth, automated, and consists of highly integrated patterns of behaviour in most skill-based control. For example, bicycle riding is considered a skill-based behaviour in which very little attention is required for control once the skill is acquired. This automaticity allows operators to free up cognitive resources, which can then be used for higher cognitive functions like problem solving. Errors in skills-based behaviour are routine errors.Rule-based level
A rule-based behaviour is characterised by the use of rules and procedures to select a course of action in a familiar work situation. The rules can be a set of instructions acquired by the operator through experience or given by supervisors and former operators.Operators are not required to know the underlying principles of a system, to perform a rule-based control. For example, hospitals have highly-proceduralised instructions for fire emergencies. Therefore, when one sees a fire, one can follow the necessary steps to ensure the safety of the patients without any knowledge of fire behaviour. Errors in rule-based behaviour are due to insufficient technical knowledge.