Human-centered design of complex systems: An experience-based approach

Abstract

This position paper presents a new approach based on my experience in the evolution of human-centered design (HCD) during four decades, and how it has struggled to become a discipline in its own right in complex socio-technical systems’ creation, development and operations. The 20th century saw tremendous industrial developments based on tangible materials that were transformed and assembled to make washing machines, cars, aircraft and power plants; during its last three decades, electronics and software were incrementally added to hardware machines. Operationalization issues moved from hardware to software, making automation and user interfaces central issues. From the beginning of the 21st century, we began to do the exact opposite! Currently, we typically start a project by designing and developing technology on computers, using software only, which is later transformed into hardware (and software). I denote this shift, the ‘socio-technical inversion’. Operationalization issues are moving from software to hardware, making tangibility a central issue. Three useful conceptual models are presented: the SFAC (Structure/Function versus Abstract/Concrete) model; the NAIR (Natural/Artificial versus Cognitive/Physical) model; and the AUTOS (Artifact, User, Task, Organization and Situation) pyramid. Concepts developed in this article are based on the rationalization of a long experience in the aerospace domain.

1 Introduction

When I was offered the opportunity to write this position paper in the Design Science journal, I tried to better understand what design science is about. I first thought that ‘design’ and ‘science’ could be considered as very different concepts leading to two very different kinds of practice and culture. Science is strongly based on rigorous demonstration and validation of initial claims. Design is about creativity and innovation, considered as a new synthesis of existing materials at various levels of integration. Consequently, putting design and science together, as complementary disciplines, contributes to combine creativity, demonstration and validation.

Design contributes to the production of artifacts that could be useful to and usable by people. An artifact is any conceptual or physical object that is made by people. Science contributes to the production of knowledge that enables explanation and/or prediction of facts and events. Consequently, I consider (at least in this article) design science as a discipline that contributes to the production of design knowledge useful to and usable for, the production of artifacts.

People have created artifacts for a long time, to support and improve their lives. Engineers have managed to optimize these artifacts in the mathematical sense (Papalambros & Wilde 2000). For that matter, the design of an artifact involves decision-making and engineering design, commonly supported by development of mathematical models that represent artifact structure(s) and function(s). Extension of these models to include people using or interacting with this artifact is a real problem since most human mathematical models are far from being representative, and even less predictive. There are very useful local mathematical models of physiological organs (e.g., respiratory or vascular functions models), but it is still impossible to develop global human mathematical models that take into account all ‘significant’ factors. In aeronautics, automatic control has entailed using human models that represent basic human pilot functions that enable landing a simulated aircraft in very restrictive conditions, for example.

More sophisticated human operator models, such as MESSAGE ¹ (Boy & Tessier 1985) and MIDAS ² (Corker & Smith 1993), were developed based on mechanistic architecture analogs such as Newell, Simon and Rasmussen’s generic models (Newell & Simon 1972; Rasmussen 1983). Even if these human operator models were extremely complex (sometimes too complex to understand what they were doing!), they were far away from what real people could do. It is often better to use conceptual human models to understand and observe activity produced by real people in human-in-the-loop simulations (HITLS). This evolution from narrow human mathematical and logical models to conceptual human models requires understanding of human-centered design (HCD) history.

HCD has been described in several ways. It emerged as a reaction to the rigid world of corporate design and engineering (i.e., current systems engineering), which dictates that engineering leads to design and development, and people would be considered when technology would be developed by creating user interfaces and operational documentation.

In 2005, the Hasso Plattner Institute of Design (known as the d.school) was founded at Stanford University after the name of its major donator, SAP co-founder Hasso Plattner, based on the Design Thinking concept developed by David Kelley, Larry Leifer and Terry Winograd (Weinberg 2012). Design thinking takes ‘context’ into account (i.e., people’s requirements, technological possibilities and economic viability) (Brown 2008). Design thinking brings flexibility that contrasts with analytical thinking rigidity (Plattner et al. 2016). In addition, design thinking incorporates creativity to conventional STEM ³ approaches, promoting a culture of innovation where HCD defines new STEAM ⁴ approaches. Finally, design thinking deals with change management, and therefore organization design.

HCD finds its roots in human–computer interaction (HCI), which takes into account human factors in computing systems and has also become a design discipline. Donald Norman is certainly one of the best promoters of HCD, where he recognized the need for observing activity, ⁵ making a difference between logic and usage. This leads to the concept of user experience (Edwards & Kasik 1974; Norman 1988). HCD encapsulates what Norman (1986) calls user-centered systems design (UCSD). The term ‘user’ may be misleading for two reasons. First, it lets people think about end users and not necessarily certifiers, maintainers and trainers, for example. Second, people who deal with a system have more characteristics than being users; they are people!

HCD of complex systems considers these philosophical distinctions for the concurrent creation and development of artifacts (concepts and/or technology), together with people and organizations that relates to them. Technology, organizations and people’s activities are co-designed and studied using different kinds of scientific methods. We now talk about the TOP model in HCD (Figure 1).

Figure 1. The TOP model (Boy 2013).

For example, NASA Human Systems Integration practitioner’s guide provides a very clear and explicit definition of HCD in the space domain (Rochlis Zumbado 2015):

1. (a) concepts of operations and scenario development;

2. (b) task analyses;

3. (c) function allocation between humans and systems;

4. (d) allocation of roles and responsibilities among humans;

5. (e) iterative conceptual design and prototyping;

6. (f) empirical testing, e.g., human-in-the-loop testing with representative population, or model-based assessment of human–system performance;

7. (g) in situ monitoring of human–system performance during flight.

After providing a definition of complex systems, this article will provide an analysis of the shift from 20th century’s technology-centered engineering leading to automation and maturity issues (i.e., going from hardware to software) to 21st century’s HCD leading to tangibility and organizational issues (i.e., going from software to hardware). I denote this shift, the ‘socio-technical inversion’. This will enable us to show that we now not only need to set prescribed tasks but also observe human activity. In addition, I will provide my experience-based contribution to HCD fundamentals that support complex systems design. HCD will be presented as interdisciplinary teamwork and a process that enables discovering generic concepts from observation.

2 What is a complex system?

The following properties typically characterize a complex system:

1. (1) a large number of components and interconnections among these components;

2. (2) many people involved in its life cycle that includes design, development, manufacturing, operations, maintenance and decommissioning;

3. (3) emergent properties and behaviors not included in the components;

4. (4) complex adaptive mechanisms and behaviors – this can be called adaptability;

5. (5) nonlinearities and possible chaos – this can be called unpredictability.

Examples of complex systems are aircraft, industrial power plants and large defense systems. They typically involve many people to design, manufacture, use, repair and dismantle them. In contrast, a simple system can be defined by the following properties:

1. (1) a small number of components and interconnections;

2. (2) behaviors directly related to components;

3. (3) no or very simple adaptive mechanisms and behaviors;

4. (4) linear or slightly linear responses to inputs.

Examples of simple systems are tables, cars and electronic watches. They do not require involvement of many people, except in the case of mass production.

From a design perspective, we distinguish and combine structural and functional complexity. The former is related to system structure, ⁶ sub-structures and so on. The latter is related to system function, sub-functions and so on. For example, the life cycle of an aircraft involves complex processes that deal with a large number of complex systems. Therefore, several sub-systems need to be articulated structurally and functionally. Consequently, several articulated backgrounds are required to design and manufacture a complex system, such as an aircraft. There is no space for improvisation. Whether they are designers, manufacturers or human operators, people who deal with complex systems need appropriate levels of familiarity with them and the environment they induce. This is what human–systems complexity analysis is about.

Some contributors talk about ‘complex socio-technical systems’ to emphasize people and technology (Grudin 1994; Carayon 2006; Baxter & Sommerville 2010; Norman & Stappers 2016). I will keep the term, ‘complex systems’, considering that the corresponding concept necessarily include people.

Finally, HCD of complex systems is necessarily interdisciplinary, since nobody can provide all possible contributions to the design of such systems, but a well-formed team can. Therefore, collaborative work is an important part of HCD (Poltrock & Grudin 2003). These concepts will be further developed in the article, using my concrete aerospace experience to illustrate them and make them more tangible.

3 The socio-technical inversion

3.1 20th century automation and maturity issues

During the 20th century, mechanical engineering was the major discipline in engineering. This great technological advancement allowed engineers to make washing machines, cars, aircraft and nuclear power plants, for example. Engineers assembled tangible objects to make complicated machines. A negative impact of this rapid evolution was discovered; the use of these machines was often discovered too late to make appropriate socio-technical corrections. Consequently, Human Factors and Ergonomics (HFE) specialists’ contributions were always possible only at the end of the development process, and therefore they were conflicting with engineers. In other words, HFE contributions were often not effective because operability (i.e., usability and usefulness of systems being designed and developed) was tested too late to provide results that could be integrated. Drastic modifications were almost impossible without spending big amounts of money. Corrective ergonomics led to user interface design (Vicente 2002).

HCI brought task analysis a step further because it moved from manipulation of physical objects to interaction with software-based objects, available on computer screens. However, the scope of HCI stayed limited to user interface design. ⁷ For example, HCI techniques developed for office automation were transferred to aeronautics, transforming the conventional aircraft cockpit into what we call today ‘interactive ⁸ cockpits’. Pilots now interact with onboard computers using a pointing device, but not directly with aircraft mechanical surfaces like in the past.

HFE tradition often fears discontinuity of work practices. I remember the fear of automation when the first highly automated cockpits were delivered during the late nineteen eighties; one of the HFE arguments was lack of continuity in work practices. This kind of automation was not a casual evolution of pilots’ work; it effectively led to a socio-technical revolution, which required that pilots knew not only how to fly an airplane but also how to manage onboard systems. At that time, HFE specialists did not have the right philosophy and practice to evaluate such a change. We needed to develop new concepts that led to a new discipline, cognitive engineering (Norman 1986). The challenge was to better understand the socio-cognitive consequences coming from the shift from control to management, which emerged from the incremental addition of software into hardware. This phenomenon has been called automation. ⁹ For example, pilots needed to know about and how to manage digital systems (i.e., this requires more cognitive capacities in addition to flying skills). The art of conventional flying incrementally became a matter of onboard system management.

During the eighties and nineties, automation drawbacks emerged from several HFE studies, such as ‘ironies of automation’ (Bainbridge 1983), ‘clumsy automation’ (Wiener 1989) and ‘automation surprises’ (Sarter et al. 1997). These studies did not consider the importance of technology maturity and maturity of practice. Automation can be modeled as cognitive function transfer from people to systems (Boy 1998). ¹⁰ If automation considerably reduced casual people’s burdens, it also caused problems such as complacency, which is an emerging cognitive function (i.e., not predictable at design time, but at operations time).

Good design can be seen as optimal function allocation. Human and system function allocation cannot be limited to a priori optimal assignment of prescribed tasks to humans and machines, in Fitts’s sense (Fitts 1951); it should be extended to the identification of emerging ¹¹ functions that are only observable at use time. This is the reason we need to observe what people really do.

3.2 21st century tangibility and organizational issues

Today, we develop an entire aircraft on computers from inception of design to finished product. Therefore, we can test its operability from the very beginning, and along its life cycle using HITLS and an agile ¹² approach using virtual prototypes. Consequently, operability of complex systems can then be tested during design. This is the reason why HCD has become a discipline in its own right. HCD enables us to better understand HSI during the design process and then have an impact on requirements before complex systems are fully developed. However, even if these environments are very close to the real world, their tangibility must be questioned, and most importantly validated.

What does the tangibility concept mean exactly? It has two meanings. First, physical tangibility is the property of an object that is physically graspable (i.e., you can touch it, hold it, sense it and so on). Second, figurative tangibility is the property of a concept that is cognitively graspable (i.e., you can understand it, appropriate it, feel it and so on). If I try to convince you about something, you may tell me, ‘what you are telling me is not tangible!’ This means that you do not believe me; you cannot grasp the concept I am trying to provide. We also may say that you do not have the right mental model to understand it, or I do not have enough empathy to deliver the message correctly.

Tangibility is about physical and cognitive situation awareness. For example, we first developed an Onboard Context-Sensitive Information System (OCSIS) for airline pilots on a tablet PC (Tan & Boy 2016). Physical tangibility considerations led to a better understanding of whether OCSIS should be fixed-based in the cockpit or hand-held. Other considerations led to the choice of displays of weather visualization going from vertical cylinders to more realistic cloud representations (figurative tangibility). A set of pilots gave their opinions on various kinds of OCSIS tablet configurations. It is interesting to note that the pilots always naturally used the term ‘tangible’ to express their opinions.

Therefore, tangibility metrics should be developed to improve the assessment of complex systems operability. This is where subject matter experts and experienced people enter into play. We absolutely need such people in HCD to help assess HSI tangibility. For example, very realistic commercial aircraft cockpits, professional pilots and realistic scenarios are mandatory to incrementally assess tangibility. OCSIS was tested from the early stages of the design process using HITLS, by recording what pilots were doing using it and analyzing produced activity. Such formative evaluations lead to system modifications and improvements.

While the 21st century shift from software to hardware is not necessarily obvious, it is the next dilemma we must address, especially now that we can 3D print virtual systems and transform them into physical systems. We will denote resulting systems, Tangible Interactive Systems (TISs) (Boy 2016). TISs are strongly based on the multi-agent concept, unlike 20th century automation that was usually based on the single agent concept. This is why TISs cannot be taken into account without a human–systems organizational approach. More generally, co-evolution of people’s activities and technology necessarily led to a tangible organizational evolution.

A shift from the old army pyramidal model to the Orchestra model ¹³ is currently emerging (see the Orchestra model in Boy 2013). For example, technology and emergent practices have led people to change ways of communicating among each other. The army model induced vertical communication, mostly descendent. Transversal communication (e.g., using telephone, email and the Web) contributed to the emergence of the orchestra model. This functional evolution is now changing organizations themselves (i.e., structures). For example, smart phones and the Internet have contributed to change in both industrial and everyday life organizations.

Having this organizational model in mind, it is now crucial to use it in HCD. In the next section, we will examine how structures and functions determine each other, and how HSI is a matter of cognitive intentionality and physical reactivity. Note that even if ‘structure’ is often denoted as ‘form’ in design and architecture, we will keep the term ‘structure’ within the scope of this article.

Summarizing

4 The task–activity distinction to better understand HCD evolution

At this point, let us clarify the relationship between the task–activity distinction and socio-technical disciplines (i.e., HFE, human–computer interaction, human–systems integration). What do task and activity mean?

A task is a prescription to people (e.g., human operators or users). Task analysis is a very popular practice in human factors engineering (Wickens et al. 2003). It is often performed a priori, as it is done in technology-centered engineering.

An activity is what people effectively do. Even though Paul Fitts’s work stressed the importance of observing activity rather than specifying tasks, he and his colleagues limited their observation to human errors; that is the negative part of activity only (Fitts & Jones 1947). Activity theories were first developed by the Russian School of Psychology (Leont’ev 1981; Kaptelinin 1995) and French School of Ergonomics (Leplat 1976; Leplat & Hoc 1983). The concept of activity also refers to distributed cognition (Hutchins 1995). Finally, activity is also defined in my model of cognitive function, which connects task and activity (Boy 1998), and is strongly inspired from these models, also anchored in situated cognition approaches (Suchman 1987) and embodied cognition (Varela et al. 1999). We can also say that compilation of people’s activities provides people’s experience (Norman 1988).

For the last sixty years, socio-technical evolution can be decomposed into three phases that made three communities ¹⁴ emerge (Figure 2):

• ∙ Human Factors and Ergonomics (HFE) ¹⁵ was developed after the second world war to correct engineering production, and generated the concepts of human–machine interfaces or user interfaces, and operational procedures; activity-based evaluation could not be holistically performed before products were finished or almost finished, which enormously handicapped possibilities of re-design. Sometimes, activity analyses were carried out prior to designing a new product, based on existing technology and practice; however, this HFE approach forced continuity, reduced risk taking, and most of the time prevented disruptive innovation.

• ∙ Human–Computer Interaction (HCI) started to be developed during the 1980s to better understand and master human interaction with computers; it contributed to the shift from corrective ergonomics to interaction design mainly based on task analysis. Activity-based analysis started to be introduced within the HCI community by people who understood phenomenology (Winograd & Flores 1987) and activity theory (Kaptelinin & Nardi 2006).

• ∙ HSI emerged from the need to officially consider human possibilities and necessities as variables in systems engineering (SE); incrementally combined, SE and HCD lead to HSI, to take care of systems during their whole life cycle (Boy & Narkevicius 2013). HSI involves more than human factors evaluations or task analyses. More importantly, it involves activity analysis at design time using virtual prototyping and HITLS (e.g., we can model and simulate an entire aircraft, fly it as a computing game, and observe a pilot’s activity). It also involves creativity, system thinking, risk taking, prototype development using agile approaches, complexity analyses, organizational design and management, as well as HSI architecture knowledge and skills.

Figure 2. Human-centered design evolution.

I do not want to create polemical discussions on labels, but say that there is a community around HFE, stable since World War II, with its own conferences and journals. The HCI community is clearly stable since the early nineteen eighties, with its own conferences and journals. Today, a new paradigm is emerging around HCD, HSI ¹⁶ and more generally, humanization of systems engineering. I know that HCD and HSI are still unstable terms, but we need to find a denotation for what we experience in the design and engineering world today.

In this article, I choose the term HCD to denote a design discipline set up to support HSI architects, who define and refine prototypes that will be further developed as final products by engineers. When we talk about considering human factors at design time, we talk about HCD, which requires more vision, technology, knowledge and skills than what current HFE can offer.

5 HCD fundamentals : My experience-based view

Designing systems for people requires knowing what both systems and people are about. Let us present these models that provide appropriate concepts and the relationships among them.

5.1 The SFAC model

Designing an artifact is defining its structure and function. Each structure and function can be described in an abstract way and a concrete way. The SFAC model (Structure/Function versus Abstract/Concrete) provides double articulation (i.e., abstract and concrete) between artifact structure and function (Figure 3) as follows: declarative knowledge (i.e., abstract structures); procedural knowledge (i.e., abstract functions); static objects (i.e., concrete structures); and dynamic processes (i.e., concrete functions).

The abstract part is a rationalization of the system being designed (i.e., knowledge representation). This rationalization can be represented by a set of concepts related among each other by typed relationships. This kind of representation can be called ontology, ¹⁷ semantic network or concept map. It can take the form of a tree hierarchy in the simplest case, or a complex concept graph in most cases.

The ‘declarative’ and ‘procedural’ terms ¹⁸ respectively refer to knowing what and knowing how. They are used to describe human memory. Declarative memory includes facts and defines our own semantics of things. Procedural memory includes skills and procedures (i.e., how to do things). We can think declarative memory as an explicit network of concepts. Procedural memory could be thought as an implicit set of know-hows. Declarative memory and procedural memory are both in the cortex and involve learning. The former is typically stored in the temporal cortex of the brain. The latter is stored in the motor cortex.

Figure 3. The SFAC Model (Boy 2016).

At design time, the concrete part is commonly represented using computer-aided design (CAD) software, which enables the designer to generate 3D models of various components of the system being designed. These 3D models include static objects and dynamic processes that allow visualization of the way components being designed work and are integrated together. Later during the design and development process, these 3D models can be 3D printed, allowing for a more graspable appreciation of the components being built as well as their possible integration. Testing occurs at each step of the design process by considering concrete parts together with their abstract counterparts (i.e., their rationalization, justifications and various relationships that exist among them).

The SFAC model is typically developed as a mediating space that design team members can share, collaboratively modify and validate. SFAC also enables the design team to support documentation of the design process and its solutions (Boy 1997). The concept of active design document (ADD), initially developed for traceability purposes, is useful for rationalization of innovative concepts and incremental formative evaluations (Boy 2005). The SFAC model was the basis of the SCORE system used to support a team, designing a light water nuclear reactor, in their collaborative work and project management (Boy et al. 2016).

5.2 The NAIR model

TISs cannot be studied, modeled, designed and developed if the distinction and complementarity of cognitive functions and physical functions is not well mastered. The (Natural/Artificial versus Cognitive/Physical) NAIR model is an attempt to rationalize this distinction for HCD (Figure 4).

Figure 4. Cognitive and physical functions: The NAIR Model (Boy 2016).

Natural or artificial software-based systems have functions that are either cognitive or physical. Natural systems include biological systems of any kind, such as people, and physical systems (e.g., geologic or atmospheric phenomena). Artificial systems include information technology, such as aircraft flight management systems, Internet and mechanical systems such as old mechanical watches.

Situation awareness, decision-making and action taking are three essential cognitive functions of any human being. They produce an intentional behavior. Symmetrically, physical functions produce reactive behavior. Artificial intelligence tools and techniques can support intentional behavior (e.g., aircraft FMSs ¹⁹ use operations research, optimization techniques and knowledge based systems); control theories and human–computer interaction tools and techniques can support reactive behavior (e.g., aircraft TCASs ²⁰ use radars, control mechanisms and voice outputs). On the natural side, intentional behavior can be supported by rationalist ²¹ philosophies (i.e., mainly related to the cortex, including reasoning, understanding and learning); reactive behavior can be supported by vitalist ²² philosophies (i.e., mainly related to the reptilian brain, including emotions, experience and skills).

5.3 The AUTOS pyramid

The Artifact, User, Task, Organization and Situation (AUTOS) pyramid extends the TOP model. It is a framework that helps rationalize HCD and engineering. It was extensively described in the introduction of the Handbook of Human–Machine Interaction (Boy 2011). The AUT triangle (Figure 5) describes three edges: task and activity analysis (U-T); information requirements and technological limitations (T-A); ergonomics and training (procedures) (T-U).

Figure 5. The AUT triangle.

Figure 6. The AUTO tetrahedron.

Figure 7. The AUTOS pyramid.

For example, artifacts may be aircraft or consumer electronics systems, devices and parts. Users may be novices, experienced personnel or experts, coming from and evolving in various cultures. They may be tired, stressed, making errors, old or young, as well as in very good shape and mood. Tasks vary from handling quality control, flight management, managing a passenger cabin, repairing, designing, supplying or managing a team or an organization. Each task involves one or several cognitive functions that related users must learn and use.

The organizational environment includes all team players, called ‘agents’, whether humans or artificial systems, interacting with the user who performs the task while using the artifact (Figure 6) (Boy 1998). It introduces three additional edges: social issues (U-O); role and job analyses (T-O); emergence and evolution (A-O).

The AUTOS framework (Figure 7) is an extension of the AUTO tetrahedron that introduces a new dimension, the ‘Situation’, which was implicitly included in the ‘Organizational environment’ (Boy 2011). The three new edges are: usability/usefulness (A-S); situation awareness (U-S); situated actions (T-S); cooperation/coordination (O-S).

The AUTOS pyramid is useful support to human-centered designers in the analysis, design and evaluation of HSI, by considering human factors (i.e., user factors), systems factors (i.e., artifact factors) and interaction factors that combine task factors, organizational factors and situational factors.

6 HCD as interdisciplinary teamwork

When I started developing the HCD graduate program at FIT, I faced the difficulty of integrating an eclectic set of disciplines that are needed to make a good human-centered designer. First, I was convinced that such a human-centered designer should already have a background in engineering, science and/or architecture. Why? The reason is simple: he or she would need to develop prototypes (i.e., be acquainted with software and/or hardware). After a while, I realized that collaborative work was essential because everybody cannot have such engineering skills to concretely develop and test a great idea. A group of well-chosen people can, by participating in a well-orchestrated HCD team. Consequently, I developed and taught the following six themes that future human-centered designers had to learn, articulate and apply.

6.1 HCD contributing themes

Cognitive engineering was born in the early nineteen eighties (Norman 1986). Human-centered designers should know about it because they need to understand cognitive modeling, human errors and engagement, situation awareness and decision-making (non-exhaustive list). Cognitive engineering is about using cognitive science concepts and methods in design and engineering (Boy 2003; Boy & Pinet 2008).

Advanced interaction media is about human–computer interaction today. Human-centered designers should know about advanced techniques and tools for system control, data visualization, ubiquitous computing, socio-media and so on. Advanced interaction media requires using the latest information technology in HCD.

Modeling and simulation (M&S) is one of the strongest pillars of HCD. HCD could not exist before M&S became tangible (i.e., efficient, easy to use, realistic and comfortable). M&S enables HITLS, making activity observation and analysis possible. It enables user requirements development in complex systems design.

Organization design and management (ODM) is another pillar of HCD (refer to the TOP model and AUTOS pyramid). HCD is seldom possible in an organization that is not prepared and structured to welcome it. ODM provides knowledge and skills to further understand why culture, organizational structures, politics and personalities can influence HCD, and how HCD can change them.

Complexity analysis is crucial in the design of complex system. It is about analyzing effects of a large number of components (people and systems) and interconnections among these components, looking for emergent properties and behaviors not included in the components, understanding adaptability and unpredictability. Complexity science is not really taught at school, and HCD cannot be effectively done if human-centered designers do not know about it, at least at the level of first principles. Students need to know about context changes and how to handle them. They also need to know about the effect of numbers (i.e., emerging effects of interactions among a large set of entities).

Life-critical systems (LCS) need to be categorized with respect to safety, efficiency and comfort. Human-centered designers should know about LCS properties, and make a distinction between internal and external complexity – this is usually related to technology maturity and maturity of practice (Boy 2013), as well as organizational maturity. Complex systems reveal their complexity when people interact with them. Very often the opposite of complexity is not only simplicity, but also familiarity.

6.2 Participatory design

One single person often cannot perform interdisciplinary work. It is hard to be an expert in everything. This is the reason people need to work in teams to perform interdisciplinary work. Cooperative work is then an important philosophy and practice. HCD cannot be implemented without cooperative work. People need to participate for the whole team to succeed. This is what we usually call ‘participatory design’. Participatory design was developed intensely during the 1960s and 1970s in Scandinavian countries. Among several initiatives and work efforts, the Utopia project is a great example of co-design of technology, organizations and jobs based on hands-on experiences (Bødker et al. 1987).

Participatory design ²³ requires collective situation awareness, empathy, and familiarity among design team members. Collective situation awareness is a matter of sharing purposes, current status of work in progress and a holistic view of the complex system being designed. Through collective situation awareness, participatory design should support intersubjectivity (i.e., design team members share the same meaning about what they are collectively designing). Empathy helps each design team member to understand and share the feelings of another. The more design team members become familiar with the complex system being designed (i.e., have a correct holistic view), the more they can articulate what they are devoted to do and what the other people, involved in other relevant components, do.

In groups, creativity emerges from the integration of various kinds of knowledge and skills toward satisfaction of goals and purposes. Teams, organizations and communities have their own properties. Teams are small, very fast, effective and highly collaborative. Organizations are large, very slow and very hierarchical. Communities could be small or big; they can be slow or fast depending on the domain; they can be highly collaborative. In all three types of groups, leadership and followship is required for each group member (i.e., if an expert leads the group today, he or she might not be the expert another day, and become a follower).

6.3 Orchestrating complex systems HCD: Team of teams

The 21st century is open, complex, dynamic and uncertain. We cannot design technology in a context-free framework any longer. More specifically, we need to situate industrial engineering (i.e., take into account context). Context is a matter of interaction among human and machine agents, and surrounding objects. Before delivering a new complex system, it is always better to anticipate possible emerging activities, properties and behaviors. Prototyping contributes to accelerate such anticipation. This context, which I am talking about, is perceived from the outside, but there is also context perceived from the inside (i.e., by each human agent ²⁴ of the system). Each agent should, in many circumstances, know about current context of a complex system.

Figure 8. System of systems.

When human agents achieve more autonomy, the overall organization becomes more decentralized and more interconnected. Consequently, agents require more coordination rules and more explicit shared context. This is a matter of appropriate organizational model, as well as individual competence and empathy. I have already described the shift from the old army model (i.e., hierarchical, mostly descendent, information flow) to the orchestra model (i.e., transversal multi-directional information flow). Like musical instruments makers and composers would architecturally design new musical instruments that determine new kinds of symphonies or concertos, human-centered designers are architects of new technology that determines new kinds of activities.

For example, the design of a commercial aircraft is a huge enterprise that associates engineers (musical instrument makers) and pilots (composers). As HSI architects, human-centered designers should take into account engineers’ and pilots’ activities and jobs from the beginning of the design process to certification of the aircraft. Making a large aircraft, or more generally a complex system, requires several interdisciplinary teams working in concert. Consequently, we need to think in terms of team of teams (Leifer 2016), to match the concept of system of systems (Figure 8).

The Orchestra metaphor is then extended to orchestra of orchestras in a wide sense since we include all stakeholders from composition (i.e., HCD) to performance. Since this team of teams approach to HCD is decentralized and relies on autonomous agents, it requires strong individual competence and coordination. It also requires strong individual empathy and motivation.

7 Discovering generic concepts from observations during design

Aerospace activities encapsulate both procedure-following and problem-solving tasks and functions. Astronauts and ground personnel never stop switching from one to the other. In this section of the article, I will use the virtual camera concept, initially developed in the context of the NASA Lunar Electric Rover ²⁵ (LER) for the exploration of the Moon (Boy et al. 2010; Boy & Platt 2013; Platt 2013; Platt et al. 2013; Platt & Boy 2014), describing its salient parts that enable presentation of generic HCD principles. Aerospace and more generally complex life-critical system domains involve expert and experienced human operators, which is not the case in public domains such as telephony and office automation.

One day, we were testing the LER prototype at Johnson Space Center in Houston, Texas. An astronaut was driving the rover on a Lunar-like hill, and I noticed that he was constantly asking people outside if he could go right, left, forward and backwards. This was because the hill was quite steep on one side and he did not want to fall down in the ‘crater’. People outside were helping him as if a person is attempting to park a car and does not have enough visibility. I thought about this possible scenario when he will be on the Moon, and nobody will be present to guide his maneuvers. This is the reason I proposed development of a virtual camera system based on what we know (e.g., NASA already provided Moon data to make Google Moon). This kind of geographical data could be used to help astronauts navigate more safely by providing more situation awareness. However, what would happen when astronauts would go to areas where nothing is known? The virtual camera system could be connected to real cameras and other appropriate sensors that would provide images and space data, which could be fused with existing data. When this process is done incrementally, the Moon surface data can be incrementally updated, and used not only as a navigation system but also as an exploration support system.

The virtual camera project began as a problem-driven case. Participatory design, agile development and formative evaluations led to exploring a domain that was much broader than expected. We incrementally discovered emerging properties of the virtual camera concept, as well as inducing implemented technology and related user experience. The generic virtual camera concept became tangible because appropriate information technology was available, such as digital cameras, big data management, data fusion, data visualization and hand-held computing devices. Incrementally designing, developing and testing virtual camera applications for space exploration, using progressively refined prototypes, led us to elicit fundamental problems to be solved as well as other domains of application. We incrementally realized that the virtual camera was a generic concept and tool that supported this endeavor. Let us present two examples.

Almost 70% of delays in big airports are due to incorrect weather planning. When pilots are facing a large convective front for example, they need to execute a maneuver that may induce a delay in their approach and landing phase of flight. Current technology provides limited short-term account of weather situation. By extending the virtual camera concept, we are developing the Onboard Weather Situation Awareness System (OWSAS) that enables pilots to have 3D visualization of weather information in the cockpit together with their trajectory and the trajectories of other surrounding aircraft (Laurain et al. 2015; Boulnois & Boy 2016).

The virtual camera concept has also been extended to crisis management support for decision-makers. Let us imagine a catastrophe like the one that occurred in Fukushima, Japan, in 2011. Decision-makers had to be supported to take appropriate actions. We developed a 3D visualization system associating geographical information (e.g., a kind of Google Earth representation of the Fukushima environment evolving in real time) and artificial reality objects floating on top of it (e.g., virtual representations of plants, showing available parameters, ongoing rescue reports, radioactivity propagation and so on) (Stephane 2013a , b ).

In these three different domains (i.e., space exploration, weather situation awareness and crisis management), we are experiencing the same kind of problems related to the degree of flexibility, innovation, complexity, maturity, stability and sustainability of the technology being designed and developed. Even if software is becoming easier to develop, tangibility of resulting systems must be better understood and mastered. This is impossible without participatory design, agile development and formative evaluations.

8 Discussion

It is very clear that 20th century technology-centered engineering followed by human factors investigations and corrective ergonomics is no longer a satisfactory solution for the design and development of current products. 21st century HCD puts people first from the very beginning of the design process, along the entire life cycle of the product.

HCD advocates the search for emerging properties instead of sticking to the currently established systems engineering practice using block diagrams, where people are represented by ‘black boxes’ linked to other system boxes. These boxes-and-arrows diagrams are useful but dangerous because they assume that people are linear rational systems. More specifically, complexity analysis requires systems thinking looking for emerging behavior and properties (Checkland 1981; Jackson 2003; Daniel-Allegro & Smith 2016). In addition, HCD deals with organizational issues, and therefore needs to be supported by appropriate models (e.g., the Orchestra model).

HCD of complex systems leads to the concept of TIS. A TIS includes both software and hardware. For this reason, the TIS concept can be related to the Internet of Things (IoT), which was coined by Kevin Ashton, an English entrepreneur, to capture the concept of integration between computer-based systems and the physical world (Gardian 1999). Smart phones, smart grid and smart houses are things in the IoT. In the IoT, things have sensors, effectors and are capable of information processing. TISs and IoT concepts are also very close to Cyber Physical Systems (CPSs), which are systems of embedded systems (Wolf 2014). CPSs are engineered systems that are built from, and depend upon, the seamless integration of computational algorithms and physical components (Lee 2008). The concept of CPS is not new. Most avionics systems in aircraft can be qualified as CPSs. For example, we can find the same kinds of systems in chemical and energy process industries, medicine, automotive, road infrastructure, robotics, and entertainment. Both the IoT and CPSs provide concrete approaches and tools for the development of TISs. The former starts from computer science and information technology premises. The latter starts from physical engineering and automatic control premises. It is interesting to follow the evolution of TISs from both perspectives, and they cross-fertilize each other.

9 Conclusion

HCD of complex systems developed over the last decades using automatic control, artificial intelligence, human–computer interaction and systems engineering, as well as human factors and ergonomics, human–computer interaction and HSI. HCD is a discipline that educates and trains HSI architects who design recommendations and requirements that engineers develop and manufacture. Human-centered designers, as HSI architects, require creativity skills and the ability to master tangibility.

HCD falls into the domain of open research, where experience is gathered from initiatives and proactive explorations of complex systems design approaches. We need to learn by doing. HCD should be practiced in order to generate such experience. The task–activity distinction is at the heart of HCD, a discipline, that is currently young and still under development (i.e., in addition to HCD methods that are predefined tasks, we need to explore HCD productions that are effective activities using the HCD approach).

Content presented in this article is still a work in progress. It is based on more than thirty-five years of work in human–machine systems, exploring human factors, ergonomic solutions, interaction design and more recently HSI. HCD could not have become effective if modeling and simulation did not evolve as it did, providing more acceptable realism at design time to use HITLS. In addition, complexity analysis is a key process in HCD, which provides a framework and methods for exploration, observation, awareness and rationalization of emerging behaviors and properties of new systems being operated. Finally, organization design and management is crucial because HCD is impossible if the organization is not prepared to do it.