4.1 Introduction

This book summarizes a process for designing and implementing op centers like the Water Detection System introduced in Chap. 1. As the work is performed, risks are assessed using a spiral development model that checks with stakeholders at each major phase, and adjusts the process based on the risks that can be perceived at that stage. The intermediate and final system can be assessed using simple usability tests as well as cognitive walkthroughs.

The process uses shared representations of the operators, their tasks, and the context of the work. An example of these is provided in Appendix 1. These shared representations are used to design and create an op center. Appendix 1, with its subsections, provides an example set of documents for describing your users and their tasks in a way that is useful for design. Larger systems will need correspondingly larger and more complex descriptions, while smaller systems will typically need less. Systems only used by their developers might not need anything, but systems that are designed without these documents are designed informally and solely for their designer ’s use, not for the operators. As architects would discuss blueprints particularly before building a project, op center designers should expect to prepare and discuss these documents during design with other stakeholders, such as managers, future operators, and funders. These discussions can reduce misunderstandings, lead to supporting all the tasks for all stakeholders, defend designs, and help keep the relevant goals, missions, and tasks in mind when designing a system. Using these documents reduces risks (Pew & Mavor, 2007).

Chapters 2 and 3 provide design principles that managers, designers, and implementers can be informed by. These stakeholders can also be informed by greater knowledge of the operators as a type of system component. Chapter 3 provides a short overview of the types of knowledge of operators that can help inform system design and implementation. Further sources for learning more are noted in each chapter.

This book should also be seen as an initial review. There is more to know about how to support operators than is covered here. Appendix 2 provides pointers to further information on how to support operators in control rooms and to support the designers who create them. Appendix 3 aggregates the most important design principles that we have described in this book. The rest of this chapter briefly summarizes the book, offers areas of future work, and responds to the set of design questions presented at the end of Chap. 1.

4.2 The Need for User-Centered Design

One of the difficulties with this approach will be investing the perceived additional time and effort to avoid the risks that this approach helps mitigate, ameliorate, or avoid. Typically, this approach takes additional effort, and organizations do not always see the risks until they arrive. There is evidence, however, that a mindful approach can overall reduce costs (Booher and Minninger 2005).

A problem that remains then is to provide evidence that there are risks and that this approach helps reduce risks and their impact . Pew and Mavor (2007) call for examples to help motivate the different team members to appreciate how usability can influence system performance. Table 4.1 notes a few examples. Support from management for this more engineering-based approach as well as further local examples could be useful to motivate implementers and technology designers to take operator tasks and their knowledge, skills, and abilities more seriously.

Table 4.1 Examples of usability problems leading to accidents (or extreme training or testing avoiding them). Further examples are available in Casey (1998)
Full size table

Keeping a list of known risks and accidents related to the design domain could also be helpful in several ways. The particular risks to op centers’ success may be difficult to quantify and will often arise from unexpected events. It may be worthwhile for an organization to keep track of misses and near misses to accidents, as NASA does for air traffic control in the NASA Aviation Safety Reporting System (asrs.arc.nasa.gov/).

4.3 The Need for Better Shared Representations

Another problem is the usability of the shared representations of users, tasks, and technology. Shared representations are documents about the design (e.g., types of users and tasks) that are shared across groups of stakeholders. The managers, designers, and implementers can come from different intellectual backgrounds, and have different assumptions. There is a need to translate some representations to “engineer speak,” and perhaps in the other direction. There is a young literature on how to prepare knowledge about design aspects to share with other team members. This is a problem noted by Pew and Mavor (2007), where it is called shared representations, and work remains to make sure the shared representations are as usable as they can be.

4.4 Open Problems

We can now revisit the questions in Table 1.4, presented here as Table 4.2. The responses are included in the table for convenience of reading and presentation.

Table 4.2 Questions addressed by this book
Full size table

As the material in Table 4.2 notes, there remain open problems with applying this approach. The degree of detail required for the documents will vary across particular op centers, and across different technologies, and thus should be adjusted accordingly to the needs of the proposed system. The risks that arise in the use of particular op centers will vary with the domain that the op center is supporting. This approach does not guarantee a perfect or even a better system, but it overall reduces risk and the probability of system failures.

4.5 Ways to Learn More

Designers of control rooms will need to know more about design and about operators than what is covered in this book. They will need to know more theory about design and human users, and they will need more details about the situations and operators and tasks that they are designing for. This appendix notes a few ways to learn more. These ways include reading , discussion, and formal and informal education. An hour a week of learning is not much in a week, but in a year, it can change how you think.

4.5.1 Readings to Learn More

Designers wanting to learn more about design and operators can most easily read more. There are numerous books on how operators (as people) think and learn. A good book of this type is Anderson’s Cognitive Psychology and Its Implications (2020). There are similar books for learning about perception (Sekuler and Blake 2005). Norman’s (1988/2013) book helped start the area of human–computer interaction but does not provide a unified theory of how to support design. It makes the case for paying attention to users and provides food for thought. As design moves in different directions, related books and textbooks can be found on broader topics such as the effects of emotions on our interactions with systems (Norman 2004).

There are also books describing operators in terms that support design. Our favorite is Foundations for Designing User-Centered Systems: What System Designers Need to Know about People (Ritter et al. 2014), but textbooks by Wickens (e.g., Wickens et al. 2012) and Lewis and Rieman (1994) are also useful . If detailed knowledge about users is required, one can try to find the information in Boff and Lincoln’s (1988) large compendium, but often the designer will be driven to reading more specialized papers, asking experts, running a study , or making an educated guess based on similar circumstances. Finally, the book Designing for situation awareness (Endsley et al. 2003) provides further useful advice. It will be familiar because we use it extensively in this book.

We also recommend Sommerville’s (2015) Software engineering (10th ed.) , and particularly the chapters on reliability engineering (Chap. 11), systems engineering (Chap. 19), and systems of systems (Chap. 20). While not directly addressed in this book, Baxter and Sommerville’s work on socio-technical systems brings a new perspective on the holistic design by integrating organizational change and system development into a unified framework.

There are also two final topics that we did not broach in this book: automation and the related topic of how operators use automation. Automation generally refers to the execution of some task that was formerly performed by a human. Eventually, some tasks will become fully automated with no future human interaction, at which point, these are simply machine tasks (Parasuraman and Riley 1997).

Designers should be careful not to rush into automating tasks, particularly for complex tasks that will continue to rely on human input. Under perfect conditions, automation seems like an easy way to reduce the workload for your operators; however, when faced with the complications that reality brings, you can quickly run into issues.

Operators use their trust in the automation to know how to use the automation and to then perform their tasks successfully with automation doing part of the task . Working with automation that is hard to calibrate can end up requiring more effort because the operator will need to monitor the automation to ensure success. Optimal performance can only be achieved when designers instill the proper amount of reliance and trust on the automated systems (Lee et al. 2004). The mental model of how the automation works and when it works should be accessible and easy to learn and easy to use. The process for automating tasks in complex systems is difficult and outside the scope of this book, but we recommend reading Lee et al.’s (2004) article Trust in Automation: Designing for Appropriate Reliance and Parasuraman and Riley’s (1997) article Humans and Automation: Use, Misuse, and Disuse if you wish to learn more. We also recommend reviewing NASA’s Automation Interface Design Development project (https://techport.nasa.gov/view/23597).

4.5.2 Reading Groups

One way to solidify knowledge from reading and to learn information not completely codified is to participate in a reading group. Sometimes these groups appear as graduate courses. They can also be organized around a work group or, better, across work groups. They take time, but a group can help digest a book, and even the social loafers who do not read the material can learn something. It is also a way to build a shared theory of design in a workplace.

4.5.3 Continuing Education

Finally, the most solid but expensive way to learn more is to take courses. Some will be available at local universities, and some are available online. Coursera and Lynda offer various courses that are related to these topics.