Integrating Cognitive Engineering Into Industry Design Teams

Cognitive engineering takes a broad perspective that can—and should—help address fundamental questions within a system’s design. Neelam’s discussion of organizational constraints in a preceding essay, for example, tackled a structured approach to deciding the allocation of functions to different workers in the work domain, an early design decision that will determine the requirements for so many other parts of the system, including machine functions, user interfaces, communications, procedures, and training.

This essay relates our own observations as to how cognitive engineering as a discipline can be brought into the organizational dynamics of broader cross-disciplinary design. Imagine, for example, a small cadre of cognitive engineers hired into the hierarchy of designers tasked with creating the next generation commercial aircraft. The hierarchy is structured around different aircraft subsystems—perhaps one design team for the flightdeck, others for propulsion, fuselage, and so forth—all tied together by a central chief engineer’s office. The chief engineer will likely tell the team that the design being safe is the foremost requirement (although the definition of safety can be ambiguous and often is defined by certification standards). Beyond that, however, the design is about the business case already negotiated with the aircraft buyers: cost (development cost, manufacturing cost, operating costs in terms of personnel and fuel) and benefit (routes flown, fuel burn, passengers carried). Therefore, every proposed design change must reduce cost and/or increase benefit.

How does our small cadre of cognitive engineers make an impact in this hierarchy? They cannot define the overall design process but instead must find ways to be effective within it. Our own observations of design have found several key constructs within the organization that our cognitive engineers can work to tap into or create (Coso & Pritchett, 2015). The first is establishing a common goal within design teams that all team members can comprehend and relate to, regardless of their discipline or role in the group. Such a common goal is true in any team context: The challenge for the cognitive engineer on a design team is to tap into that goal. This challenge requires them to not only define why human cognition concerns should be embedded into the goal but also translate those concerns into terms with specific and direct merit in the eyes of other designers on the team. And so the principles of good human-centered design need to be translated into team-wide goals and, ultimately, specific, measureable design requirements: reduced pilot training cost for the airlines or faster “turn times” at the gate allowing for more flight operations per day per aircraft, for example.

Now that our cognitive engineers have gotten their colleagues’ attention with concerns about (training) costs and (reduced turn-time) benefits, they face the tough work of trading off between competing ideas. Perhaps, for example, a cognitive engineer proposes that some of the autopilot modes may be confusing, and hard to portray, to the pilot. Thus, the cognitive engineer suggests simplifications to those modes to reduce both potential safety concerns and training costs. The designer behind the autopilot mode logic, however, knows that some of the mode switches are already implemented in expensive, established-and-certified software. Here, the construct of a trading zone can help as a means for designers with diverse perspectives to communicate and coordinate with each other despite differences in their norms, values, methods, and performance metrics. This construct was first recognized with Galison’s descriptions of interactions among subcultures of physicists and engineers (Galison, 1997) and has since been used to examine engineering teams within NASA (Kellogg, Orlikowski, & Yates, 2006), the development of Earth Systems Science Management (Gorman, 2005), and the evolution of coordination among diverse stakeholder groups (Jenkins, 2010). At their most basic, such trading zones provide a space where potential tradeoffs can be discussed and “traded” based on their estimated impact on common goals.

Trading zones, however, do not appear out of nowhere but are the result of an evolution of shared language and intermediary boundary objects among the disciplinary and subsystem groups. Boundary objects, such as storyboards, 3D CAD drawings, or prototypes, are tangible and intangible artifacts that span knowledge boundaries and serve as a means of translation (Collins, Evans, & Gorman, 2007; Star & Griesemer, 1989). The cognitive engineers can develop these objects to help other designers, the chief engineering office, and potential customers/users to visualize where the pilot might have difficulty comprehending the autopilot modes. Likewise, the cognitive engineer might start defining the impact of different designs on pilot training cost in a shared cost analysis tool, quickly highlighting to other designers in a shared language the relative benefits of their proposals.

At a more existential level, the cognitive engineers can also consider the appropriate role and strategy for their interactions within the system. The cross-disciplinary practice (CDP) framework developed by Adams, Mann, Jordan, and Daly (2009), for example, proposed categories of cross-disciplinary work: (1) working together, (2) intentional learning, (3) strategic leadership, and (4) challenging and transforming practice. These categories, defined in the literature as perspectives held by individuals about cross-disciplinary work, can also be viewed as strategies that designers might seek to implement within their design team. Cognitive engineers, for example, can seek to understand the perspectives taken by their teammates as well as the constraints and flexibility embedded within their own role to determine the most appropriate strategy for bringing their concerns to cross-disciplinary design. The strategy working together, for example, requires an iterative communication process of asking questions, listening, and being aware of how to communicate with individuals who have different training and learning how to move past one’s disciplinary mindset to take personal responsibility for facilitating effective collaboration (Adams, Forin, Srinivasan, & Mann, 2010). Based on observations of the organizational dynamics, a cognitive engineer may choose to invoke this strategy, taking deliberate actions such as attending other designers’ meetings to learn more about their methods and concerns. Through these, and similar, activities, our cognitive engineers would not only learn about the others’ concerns and methods, but they may also create opportunities to explain their own. By using this working together strategy, our cognitive engineers would begin to establish themselves as present and trusted members of the team.

As the cognitive engineers become familiar with the design process and the dynamics of their design organization, strategies such as strategic leadership and intentional learning may be appropriate for a given system design project. Here, the cognitive engineers can move past deliberately seeking opportunities to work together to also explicitly creating the opportunities to help other designers learn about cognitive engineering concerns and to help shape the design process within the teams to directly incorporate more cognitive engineering methods and metrics.

Another factor shaping the cognitive engineers’ strategies for working within the cross-disciplinary teams is the structure of the group, particularly as it defines the role of the cognitive engineer as a fundamental member of specific design teams versus a separate specialist or resource. At one end of this continuum, the cognitive engineers may participate on a team with other members who share similar concerns or serve as resources (e.g., pilots on the design team for the flightdeck). At the other end, the cognitive engineers may be asked by design teams to consult as needed or as part of regular reviews. The “right” group structure for a given design is dependent on the culture and structure of the organization. Cognitive engineers could discuss different possible structures with project managers to determine the most appropriate for the particular project.

Finally, our cognitive engineers’ approach to design should account for the extent to which the design teams have available design team members (cognitive engineers and others) capable of cross-disciplinary work. Some of this capability we would expect of the other design team members, yet they may require further training to understand how to integrate cognitive engineering concerns into their cross-disciplinary capabilities. Thus, our cognitive engineers themselves may also need to consider—and extend—their own capabilities in cross-disciplinary design.

This call to join in cross-disciplinary design efforts represents several interesting challenges for the discipline of cognitive engineering. Beyond the discipline’s internal discussions about appropriate design methods and models framed within our own constructs and values, can we also use these methods and models to engage with those we might consider untrained (or obtuse or naïve in their beliefs) in designing for human performance? Or perhaps we should look at our own domain, which unlike most engineering domains, does not consistently and explicitly require some measure of cross-disciplinary design of our students. Aerospace engineering students, for example, undertake design projects in which they are explicitly taught how to balance tradeoffs between disciplines like aerodynamics and structures, all framed within a request for proposal and cost-benefit analysis. Should we, in cognitive engineering, also seek further to articulate and institutionalize the mechanisms by which our cognitive engineering concerns can be addressed using common goals, trading zones, boundary objects, shared language, and CDPs that do not depend on the “other” to understand us?