A Crew-Centered Flight Deck Design Philosophy for High-Speed Civil Transport (HSCT) Aircraft

Abstract

This report was written under the auspices of NASA's High Speed Research (HSR) program as part of the Flight Deck Design and Integration element led by Dr. Kathy Abbott. We greatly appreciate the substantial contribution of the many participants involved in the development and review of this document. This included HSR program participants at NASA Langley Research Center, NASA Ames Research Center, Boeing Commercial Airplane Group, McDonnell-Douglas Aerospace-West, and Honeywell. Special thanks are extended to George Boucek, Jeff Erickson, Jon Jonsson, Vic Riley, Marianne Rudisill, and Barry Smith. In addition to reviewing the document, Vic Riley and Marianne Rudisill also contributed text for several sections. The authors also extend their appreciation to the document review panel, which consisted of: Charles Billings of The Ohio State University; Richard Gabriel of Douglas Aircraft Company (retired); John Lauber of the National Transportation Safety Board; Thomas Sheridan of the Massachusetts Institute of Technology; Harty Stoll of Boeing Commercial Airplane Group (retired); Gust Tsikalas of Honeywell; and Earl Wiener of the University of Miami, Florida.

Full text

NASA Technical Memorandum 109171
A Crew-Centered Flight Deck
Design Philosophy for High-Speed
Civil Transport (HSCT) Aircraft
Michael T. Palmer
Langley Research Center, Hampton, Virginia
William H. Rogers
Bolt, Beranek, & Newman, Inc., Cambridge, Massachusetts
Hayes N. Press
Lockheed Engineering & Sciences Company, Hampton, Virginia
Kara A. Latorella
State University of New York at Buffalo, Buffalo, New York
Terence S. Abbott
Langley Research Center, Hampton, Virginia
January 1995
National Aeronautics and Space Administration
Langley Research Center
Hampton, Virginia 23681-0001

iiii
ACKNOWLEDGMENTS
This report was written under the auspices of NASA’s High Speed Research (HSR) program as part of
the Flight Deck Design and Integration element led by Dr. Kathy Abbott. We greatly appreciate the substantial
contribution of the many participants involved in the development and review of this document. This included
HSR program participants at NASA Langley Research Center, NASA Ames Research Center, Boeing
Commercial Airplane Group, McDonnell-Douglas Aerospace-West, and Honeywell. Special thanks are
extended to George Boucek, Jeff Erickson, Jon Jonsson, Vic Riley, Marianne Rudisill, and Barry Smith. In
addition to reviewing the document, Vic Riley and Marianne Rudisill also contributed text for several sections.
The authors also extend their appreciation to the document review panel, which consisted of: Charles Billings
of The Ohio State University; Richard Gabriel of Douglas Aircraft Company (retired); John Lauber of the
National Transportation Safety Board; Thomas Sheridan of the Massachusetts Institute of Technology; Harty
Stoll of Boeing Commercial Airplane Group (retired); Gust Tsikalas of Honeywell; and Earl Wiener of the
University of Miami, Florida.

iiiiii
TABLE OF CONTENTS
GLOSSARY OF TERMS......................................................................................................................... IV
1.0 EXECUTIVE SUMMARY ...................................................................................................................1
2.0 INTRODUCTION.................................................................................................................................2
2.1 Background and Rationale ................................................................................................................2
2.2 Users and Use of Document..............................................................................................................4
2.3 Organization of the Document ..........................................................................................................6
3.0 DESIGN PROCESS..............................................................................................................................7
3.1 The Overall Design Process ..............................................................................................................7
3.2 Where to Apply the Philosophy ........................................................................................................8
4.0 THE PHILOSOPHY...........................................................................................................................11
4.1 Performance Objectives ..................................................................................................................11
4.2 Pilot Roles ......................................................................................................................................12
4.3 Automation Roles ...........................................................................................................................13
4.4 Design Principles............................................................................................................................14
4.4.1 Pilots as Team Members........................................................................................................14
4.4.2 Pilots as Commanders............................................................................................................16
4.4.3 Pilots as Individual Operators ................................................................................................17
4.4.4 Pilots as Flight Deck Occupants.............................................................................................20
4.5 Framework for Design Guidelines...................................................................................................21
4.5.1 Crew Issue/Flight Deck Feature Guidelines............................................................................23
4.5.2 Flight Deck Feature/Flight Deck Feature Guidelines..............................................................28
4.6 Conflict Resolution.........................................................................................................................30
5.0 CONCLUDING REMARKS ..............................................................................................................31
6.0 REFERENCES....................................................................................................................................32
APPENDIX A: TEST AND EVALUATION ...........................................................................................35
APPENDIX B: HSR ASSUMPTIONS.....................................................................................................42
APPENDIX C: RESOURCES AVAILABLE ..........................................................................................44

iviv
GLOSSARY OF TERMS
Many terms contained in this document have meanings specific to flight deck design or are defined
differently by different organizations. They are defined here to help reduce confusion and ambiguity.
Anthropometrics: Measures of human physical dimensions, including not only static measures of body
dimensions (e.g., height or arm length) but also functional measures such as reach and grip span and
performance characteristics such as strength and viewing distance. Descriptions of the variability associated
with these measures are also included to cover the different potential user populations.
Assumption: An assumption is something taken for granted; a supposition. It is typically a statement whose
truth or falsehood is untestable, but is believed to be true. In the case of the HSCT, this occurs because many of
the assumptions pertain to future conditions or events.
Automation: Systems or machines which perform a function or task. For example, automation can replace
humans (perform an entire task), augment them (perform a part of some control activity), or aid them (provide
computation to assist human information processing, decision making, recall, etc.).
Cognitive Engineering: An applied cognitive science that draws on the knowledge and techniques of cognitive
psychology and related disciplines to provide the foundation for principle-driven design of person-machine
systems.
Control Display Unit (CDU): One of the flight crew interface devices used to communicate with the Flight
Management System (FMS). The CDU consists of numeric and alphabetic keypads, function and page select
keys, a small display screen, and line select keys arranged on the sides of the display screen to correspond to
specific lines on the display pages.
Crew Resource Management (CRM): Sometimes referred to as cockpit resource management or command
leadership resource management, this is a technique by which each crew member, especially the Captain,
effectively uses all available sources of information and assistance to handle abnormal or emergency situations.
Critical Flight Functions: Those functions which are essential for the safe and successful completion of the
flight. This term is used instead of “flight critical,” which can have a very specific legal meaning in some
contexts.
Design and Integration Element: One of the three main elements within the High Speed Research (HSR)
program’s Flight Deck effort. The other two Elements are External Visibility and Guidance & Control.
Design Philosophy: The design philosophy, as embodied in the top-level philosophy statements, guiding
principles, and design guidelines, provides a core set of beliefs used to guide decisions concerning the interaction
of the flight crew with the aircraft systems. It typically deals with issues such as function allocation, levels of
automation, authority, responsibility, information access and formatting, and feedback, in the context of human
use of complex, automated systems.
Dynamic Function Allocation: A methodology for allocating functions among various team members (humans
and automated systems) adaptively, as a situation develops, to make the best possible use of the resources that
each team member can contribute to the effort taking into consideration the other tasks that may be underway.
Engineering Psychology: A specialized area within the field of human factors research which focuses on basic
investigations into fundamental human capabilities and limitations.

vv
Error Correction: A capability, human or automated, to "undo" or reverse an action or response that was
erroneous and then perform the correct action or response.
Error Detection: A capability, human or automated, to determine that an error has occurred.
Error Prevention: A capability, human or automated, to prevent errors from occurring. For example, an input
device may only allow entry of numbers that are valid for the operational context.
Error Tolerance: A capability, human or automated, to compensate or adjust for the occurrence of an error so
that it has no significant consequences in terms of flight safety.
Final Integrated Design: At this stage in the design process the various flight deck systems are integrated into a
total flight deck. The flight crew interface with each of the aircraft subsystems is also designed.
Flight Deck Features: Aspects of the flight deck which are used by designers to differentiate and organize their
design experiences. These features have been categorized here as displays, controls, automation, and alerting.
Flight Management System (FMS): The total computer-based system for planning the flight of the aircraft and
providing guidance and autoflight control capabilities. It includes multiple Flight Management Computers
(FMC’s), the Mode Control Panel (MCP), and multiple Control Display Units (CDU’s), and is linked to many
other aircraft subsystems and controls.
Function Allocation: The process of determining which team members (flight crew or automated systems) will
nominally be performing specific functions and tasks. Specific function allocations may occur during the design
process, and others may be left to the discretion of the flight crew (see Dynamic Function Allocation).
Guideline: This is an indication or outline of policy or conduct. A guideline provides design guidance more
specific than a principle, such as at the system level, interface level, or specific factor level (e.g., lighting).
Guidelines are concerned with function and form of flight deck design. Quantification of and adherence to
guidelines is relative; in contrast, quantification of and adherence to requirements is absolute.
High Speed Civil Transport (HSCT): A proposed supersonic commercial airliner capable of long-range flights
at speeds of up to Mach 2.4.
High Speed Research (HSR) Program: A joint research program by NASA and the U.S. commercial aviation
industry, initiated with the goal of establishing the technological base needed to reduce the risk associated with
the design and development of the HSCT.
Human-Centered Automation: A concept of aircraft automation in which the flight crew members perceive
themselves to be at the locus of control of the aircraft and all of its systems, regardless of the current control
mode or level of automation in use (Billings, 1991).
Human Engineering: The practice of applying knowledge of the disciplines of anthropometry, psychology,
biology, sociology, and industrial design to the development of products or processes that involve human
interaction.
Inductive Reasoning: Inference of a generalized conclusion from particular instances.
Initial Design Concepts: This stage of the design process represents both the process and the product of
allocating specific functions to either the human pilots or the automated systems, and then developing alternative

vivi
design concepts to support that allocation of functions and selecting from among those concepts. For example,
initial design concepts related to the function of maintaining runway centerline during landing rollout may include
multiple types of control inceptors (rudder pedals or a hand crank) and control laws (different rates, gains, etc.)
for the pilot, and various control laws for the autoflight system.
Levels of Automation: The degree to which a function or task is performed by the human and automated
systems. The highest level of automation is characterized by automated systems performing the function
autonomously without any pilot input. The lowest level of automation is characterized by pilot performance of a
task or function with no assistance from automation.
Mental Model: An understanding on the part of the flight crew member of how a particular device or automated
system works in terms of its internal structure or processes. This understanding may be at a high level, dealing
only with general notions of how something works, or may be very specific, dealing with intricate details and
system knowledge.
Mode Control Panel (MCP): The collection of controls and displays used by the flight crew for entering speed,
lateral, and vertical control instructions to the autoflight system. This panel is usually mounted on the flight deck
glareshield, and, depending on the aircraft manufacturer, may be referred to as a Guidance and Control Panel
(GCP) or Flight Control Panel (FCP).
Multiple Resource Theory: The theory that humans have multiple input and output channels, such as vision,
hearing, smell, and speech, that can be time-shared most effectively when the different resources being used are
the most unrelated.
Next Generation Flight Deck: The next-generation flight deck is defined by a design process less constrained by
past design practices and more conducive to gathering and applying recent research findings and state-of-the-art
knowledge about the design and operation of complex man-machine systems. The next generation flight deck
also includes a greater focus on human-centered issues in the design process. This new approach may or may not
result in a flight deck that is radically different from current flight decks.
Objective: This is something that one’s efforts are intended to attain or accomplish; a purpose; a goal; a target.
Multiple objectives usually must be met, and the flight deck designer should understand the relationships among
these objectives, and their relative importance.
Operability: Operability is sometimes used synonymously with usability, that is, can a system be operated safely
and efficiently by a user such as a pilot. It is used more broadly here to include not only usability but also
functionality, that is, when the system is operated, does it meet the functional requirements?
Philosophy: In general, a philosophy is a system of beliefs or a doctrine that includes the critical study of the
basic principles for guidance in practical affairs. For the purposes of this document, the guidance in this case is
specific to flight crew issues relevant to commercial flight deck design.
Philosophy statements: High-level statements summarizing a general position or perspective, in this case, a
philosophy of flight deck design.
Principle: This is a fundamental, primary, or general law or axiom from which others are derived; a
fundamental doctrine or tenet; a distinctive ruling opinion. In this document, a principle provides design
guidance at the flight deck function level, and refers to general concepts such as authority, function allocation,
levels of automation, human information processing capabilities, etc.

viivii
Requirement: This is something that is necessary or essential. A requirement describes a specific condition that
the design must meet, and can be traced back to limitations imposed by various "outside" requirements or
constraints (e.g., what the customer wants or what the technology is capable of). The following different types of
requirements are often identified:
Aircraft Functional Requirements: These requirements identify and describe the functions that must be
performed to fulfill the aircraft operational requirements (i.e., those that have some identifiable flight
deck impact). Each functional requirement consists of three components: (1) the generic function that
must be performed; (2) the performance criteria which must be met; and (3) any constraints within
which the function must be performed. An example of a functional requirement is to maintain the
aircraft on the runway centerline during landing rollout, to within a certain number of feet of offset.
Aircraft Operational Requirements: These requirements summarize the total effects of the combined
mission, customer, flight crew, environmental, regulatory, and program requirements on the operational
characteristics of the aircraft as a whole. The goal is to define aircraft operational requirements as what
the aircraft needs to be able to do (from the skin out; i.e., without any consideration for who or what
inside the aircraft is making it work), although in practice some of these operational requirements
recognize that high-level decisions have been implicitly made. For example, the operational requirement
for the aircraft to be able to perform visual approaches and landings in visual meteorological conditions
(VMC) presupposes the presence of a flight crew with access to the appropriate information and controls
to make such approaches and landings. Due to practical limitations, the scope of the aircraft operational
requirements considered in a typical flight deck design process is usually restricted to those requirements
that have some identifiable flight deck impact.
Aircraft System Requirements: These requirements specify the generic high-level systems that will be
responsible for carrying out certain collections of aircraft functions. To the extent possible, design
decisions concerning the allocation of aircraft functions to either humans or automated systems are
deferred until later in the design process. For example, the flight deck as a high-level system is identified
as being responsible for the function of maintaining the runway centerline during landing rollout.
Whether humans or automated systems within the flight deck actually perform tasks which accomplish
this function is not yet decided.
Customer Requirements: These requirements are driven by the reality of the customer’s business, and
reflect the necessary characteristics of the aircraft from an airline operations standpoint. Examples
include such items as the minimum number of operating hours per day, the turnaround time between
flights, the ease of pilot transition both into and out of the aircraft, and both initial purchase and
recurring operational costs.
Environmental Requirements: These requirements are driven by the need to limit the impact of the
aircraft's operation on the surrounding environment. Examples include restrictions on where supersonic
flight can occur, and limits on the amounts of combustion emissions by the engines into the upper
atmosphere.
Flight Crew Requirements: These requirements are driven by the need to account for the basic
physiological and psychological limitations of the humans who will occupy and operate the aircraft.
Examples include oxygen and pressurization, radiation exposure levels, the effects of oscillation and
vibration, and ingress and egress from the seating provided.
Flight Deck Requirements: These requirements describe what the different components of the flight
deck are, and which functions are allocated to each of these components. For the example of maintaining
the runway centerline during landing rollout, this function is allocated to both the flight crew (for manual

viiiviii
landings) and to the automated systems (for automatic landings). This case demonstrates that a single
generic function may result in requirements placed on two different components within the flight deck.
Mission Requirements: These requirements are driven by the general configuration of the aircraft itself
and the mission it is expected to fulfill. Examples include cruise speed, range, payload capacity, and the
ability to use existing runways, taxiways, and ramp space.
Program Requirements: These requirements are driven by the airplane development program itself, and
include general configuration and performance data and high-level decisions based on the aircraft
manufacturer’s internal Design Requirements and Objectives Document (or equivalent). Examples of the
former include such items as length, wingspan, gear geometry, weight, and design cruise Mach number,
and examples of the latter include subsystem and communications capabilities, no preferential ATC
treatment, and a two-person crew.
Regulatory Requirements: These requirements are driven by the need to operate successfully within the
existing and future structure of U.S. and international airspace systems, and to comply with the
regulations which govern their use. Examples include noise abatement procedures, speed restrictions and
spacing compatibility with terminal area procedures, and the ability to operate in a mixed VFR/IFR
traffic environment.
Situation Awareness: The perception on the part of a flight crew member of all the relevant pieces of
information in both the flight deck and the external environment, the comprehension of their effect on the current
mission status, and the projection of the values of these pieces of information (and their effect on the mission)
into the near future.
Synthetic Vision: A method of supplying forward vision capability to the flight crew when forward windows
cannot be used because of the fuselage geometry.
Technology Constraints: These constraints are imposed by the expected state of advances in the core
technologies required to implement a specific system based on the system specification.
Test and Evaluation: This is defined here specifically as the process by which allocation decisions, design
concepts, design prototypes, and the final integrated design are evaluated on the basis of how well they meet the
design requirements and how usable they are from the flight crew perspective. The evaluation methods depend
upon the stage of design: for example, allocation decisions and design concepts may be tested using pen-and-
paper structured scenario walkthroughs, design prototypes may be evaluated using mockups or computer
workstation experiments, and the final integrated design may be tested using a partial- or full-mission flight
simulator.
Top-down Approach. This is an approach to design which is driven by both a hierarchy of cascading
requirements (e.g., operational, functional, systems) and a theoretically-based philosophy of what constitutes
good design.
Usability: The degree to which a design exhibits the following five characteristics (from Nielson, 1993): (1)
learnability, in that it requires minimal training for proficient use; (2) efficiency, in that it allows a high rate of
productivity once training is complete; (3) memorability, in that it requires minimal refamiliarization after a
period of nonuse; (4) error reduction, in that it prevents errors as much as possible and allows for error detection,
correction, and tolerance when prevention isn’t possible; and (5) satisfaction, in that it provides the operators
with a subjective feeling of satisfaction during use.

ixix
Utility: The degree to which the requisite functions, as determined by the appropriate requirements, are present
and supported by the design.
Workload: In the context of the commercial flight deck, workload is a multi-dimensional concept consisting of:
(1) the duties, amount of work, or number of tasks that a flight crew member must accomplish; (2) the duties of
the flight crew member with respect to a particular time interval during which those duties must be accomplished;
and/or (3) the subjective experience of the flight crew member while performing those duties in a particular
mission context. Workload may be either physical or mental.

1
1.0 EXECUTIVE SUMMARY
Past flight deck design practices used within the U.S. commercial transport aircraft industry have been
highly successful in producing safe and efficient aircraft. However, recent advances in automation have changed
the way pilots operate aircraft, and these changes make it necessary to reconsider overall flight deck design.
Automated systems have become more complex and numerous, and often their inner functioning is partially or
fully opaque to the flight crew. This raises pilot concerns about the trustworthiness of automation, and makes
crew awareness of all the intricacies of operation that may impact safe flight difficult to achieve. While pilots
remain ultimately responsible for mission success, performance of flight deck tasks has been more widely
distributed across human and automated resources. Advances in sensor and data integration technologies now
make far more information available than may be prudent to present to the flight crew. The High Speed Civil
Transport (HSCT) mission will likely add new information requirements, such as those for sonic boom
management and supersonic/subsonic speed management. Consequently, whether one is concerned with the
design of the HSCT, or a next generation subsonic aircraft that will include technological leaps in automated
systems, basic issues in human usability of complex systems will be magnified. These concerns must be
addressed, in part, with an explicit, written design philosophy focusing on human performance and systems
operability in the context of the overall flight crew/flight deck system (i.e., a crew-centered philosophy). This
document provides such a philosophy, expressed as a set of guiding design principles, and accompanied by
information that will help focus attention on flight crew issues earlier and iteratively within the design process.
The philosophy assumes that the flight crew will remain an integral component of safe and efficient
commercial flight for the foreseeable future because human skills, knowledge, and flexibility are required in the
operation of complex systems in an unpredictable and dynamic environment. The performance of the overall
flight crew/flight deck system depends on understanding the total system, its human and automated components,
and the way these components interact to accomplish the mission. The philosophy, therefore, seeks to elevate
design issues associated with the understanding of human performance and cooperative performance of humans
and automation to the same level of importance as the past focus on purely technological issues, such as
hardware performance and reliability. It also seeks to elevate flight crew/flight deck issues to the same level of
importance given other aircraft design areas, such as aerodynamics and structural engineering. The philosophy
includes the view that flight deck automation should always support various pilot roles in successfully
completing the mission. Pilot roles can be defined in many ways, but the philosophy suggests that it is important
to identify human roles which highlight and distinguish important categories of design issues that can affect
overall flight crew/flight deck performance. These roles are: pilots as team members, pilots as commanders,
pilots as individual operators, and pilots as flight deck occupants. Design principles are presented according to
these pilot roles. A framework for more detailed guidelines is presented which accounts for both pilot roles and
different categories of flight deck features (i.e., displays, controls, automation, and alerts).
This document is Part 1 of a two-part set. The objective of the document is to provide a description of
the philosophy at a level that is aimed primarily toward managers. It is intended to: (1) establish a common
perspective of crew-centered design, and the ways that perspective can be applied within the design process; and
(2) provide a framework for developing increasingly detailed flight deck guidelines which are consistent with the
guiding principles and philosophy statements. Part 2 of the document set will provide more detailed descriptions
of design guidelines, test and evaluation issues, recommendations for how to apply the philosophy, and methods
for identifying and resolving conflicts among design principles and among design guidelines.

2
2.0 INTRODUCTION
2.1 Background and Rationale
Past flight deck design practices used within the U.S. commercial transport aircraft industry have been
highly successful in producing safe and efficient aircraft. However, recent advances in automation have changed
the way pilots operate aircraft, and these changes make it necessary to reconsider overall flight deck design.
Automated systems have become more complex and numerous, and often their inner functioning is partially or
fully opaque to the flight crew. This raises pilot concerns about the trustworthiness of automation, and makes
crew awareness of all the intricacies of operation that may impact safe flight difficult to achieve. While pilots
remain ultimately responsible for mission success, performance of flight deck tasks has been more widely
distributed across human and automated resources. Advances in sensor and data integration technologies now
make far more information available than may be prudent to present to the flight crew. Consequently, the Air
Transport Association of America (ATA) established an industry-wide task force to consider aviation human
factors issues. This task force created the "National Plan to Enhance Aviation Safety through Human Factors
Improvements" in 1989 (ATA, 1989). The first element of this plan addressed aircraft automation. It
specifically expressed the need for a philosophy of aircraft automation: "The fundamental concern is the lack of a
scientifically-based philosophy of automation which describes the circumstances under which tasks are
appropriately allocated to the machine and/or the pilot." The plan further described specific research needs to
develop and apply a human-centered automation philosophy to systems, displays, and controls.
NASA’s Aviation Safety/Automation program also addressed automation and human factors issues
similar to those raised by the ATA task force. Flight deck automation philosophy was included as part of this
program (e.g., Billings, 1991; Norman, et al., 1988). Interest in automation philosophy has continued with
NASA’s High-Speed Research (HSR) program, which is aimed at providing a research and technology base to
support development of a high speed civil transport (HSCT) aircraft early in the twenty-first century. The HSR
program presents a unique opportunity (and challenge) for developing and applying a crew-centered philosophy
to flight deck design. One focus of the HSR program’s Design and Integration Element is to develop concepts for
a "next-generation flight deck." This next-generation flight deck is defined by a design process less constrained
by past design practices and more conducive to gathering and applying recent research findings and state-of-the-
art knowledge about the design and operation of complex man-machine systems. This will allow a more top-
down approach within which the philosophy can be applied more explicitly, thoroughly and systematically in
developing and selecting design solutions that may not be considered in the context of evolutionary design. In
addition to facing the automation issues described above, an HSCT flight deck will very likely have revolutionary
features such as sensor- and data-based synthetic vision to compensate for the lack of forward windows, and will
place greater demands on the pilot for tasks such as ground handling, sonic boom management and supersonic-
to-subsonic speed management. Human usability of complex system issues are imposed by both introduction of
new systems, as for the HSCT, and the fundamental lack of explicit, systematic design guidance and processes
that focus on the flight crew.
We believe that explicitly stated principles of crew-centered design (many of which are informally
applied in current flight deck designs), coupled with a design process which formally considers these principles at
a variety of stages during the design process, will help address these issues. It should be emphasized that the
philosophy described here is theoretically-based and is applicable to any new flight deck, or for that matter, to
any complex human-machine system. Although on occasion the philosophy will contradict past practices and
design constraints imposed by other considerations, making a philosophy explicit identifies those contradictions,
and can be used to trace design decisions back to theoretical versus practical rationales.

3
This document provides guidance by describing good attributes of the design product, and characteristics
of the design process that will facilitate their incorporation in future flight decks. It presents philosophy
statements, guiding principles, and a framework for organizing design guidelines, and it suggests where, within
the design process, they should be applied. This should help introduce flight crew issues earlier and make them
explicit and formal. It also describes test and evaluation (T&E) issues and methods. Evaluation, especially in
the sense of operability or usability testing, throughout the design process, complements a crew-centered design
philosophy. A good guiding philosophy alone can not assure good, human-centered design. Testing for usability
is not a process that follows design; it is part of design. Experts in the design of human-computer interfaces
(e.g., Gould, 1988), emphasize early and continual user testing as a fundamental principle of system design. We
consider it a fundamental element of a design process that will assure a crew-centered flight deck design.
This crew-centered flight deck design philosophy is by no means a new concept or approach. It borrows
heavily from previous research and practices in human factors and experimental psychology, and is consistent
with all approaches which focus on facilitating how humans interact with their environment, tools, automation,
and each other to improve overall performance of complex man-machine systems. This includes approaches
such as human engineering (e.g., Adams, 1989; Bailey, 1982; Sanders & McCormick, 1993; Van Cott &
Kinkade, 1972), cognitive engineering and engineering psychology (e.g., Helander, 1988; Norman, 1986;
Rasmussen, 1986; Wickens, 1991; Woods & Roth, 1988), and human-centered automation approaches (e.g.,
Billings, 1991; Norman, et al., 1988; Regal & Braune, 1992; Rouse, Geddes, & Curry, 1987; Wilson & Fadden,
1991). In addition, work on developing specific philosophies for flight deck design has progressed recently both
in the United States (e.g., Lehman, et al., 1994; Braune, Graeber, & Fadden, 1991) and in Europe (e.g.,
Wainwright, 1991; Heldt, 1985; Hach & Heldt, 1984).
The crew-centered flight deck philosophy described in this document is based on the perspective that the
flight deck is a complex system composed of equipment and the flight crew. The philosophy assumes that the
flight crew will remain an integral component of safe and efficient commercial flight for the foreseeable future.
While many accidents and incidents are attributed to "pilot error," these problems often arise due to specific
design decisions. Further, it is our firm belief that the flight crew is the most critical component of the flight
deck: human capabilities are absolutely mandatory for safe operation of complex systems in an unpredictable and
dynamic environment, and will be for the foreseeable future. We presume this is the fundamental rationale for
the flight crew’s ultimate legal responsibility for the safety of the flight. Also, the performance of the overall
flight crew/flight deck system depends on understanding the total system, its human and automated components,
and the way these components interact to accomplish the mission. The philosophy, therefore, seeks to elevate
design issues associated with the understanding of human performance and cooperative performance of humans
and automation to the same level of importance as the past focus on purely technological issues, such as
hardware performance and reliability. The philosophy includes the view that the flight deck automation and
flight crew interfaces should support the flight crew in accomplishment of the mission. Automation may aid the
pilot with information, augment the pilot by performing control actions, or substitute for the pilot entirely in
conducting some functions or tasks. But in each of these capacities, the automation should serve the flight crew.
This is based on the fact that since pilots are ultimately responsible for the flight, they should always have final
authority, and the information and means to exercise that authority.
Pilot roles can be defined in many ways. This philosophy identifies human roles which highlight and
distinguish important categories of design issues that can affect overall flight crew/flight deck performance. The
roles identified are: pilots as team members, pilots as commanders, pilots as individual operators, and pilots as
flight deck occupants. The role of team member highlights design issues that affect communication,
coordination, common functional understanding and resource management. The role of commander highlights
design issues that affect authority, responsibility and the allocation of functions. The role of individual operator
highlights traditional human factors design issues such as workload, anthropometrics, task compatibility with
human strengths and limitations, and interface design. The role of occupant highlights design issues such as

4
comfort, health, safety, and subsistence. Although human/machine system performance is affected by a wide
range of factors, including pilot training and procedures and organizational factors, this report presents a
philosophy for design. It focuses on design as a mechanism for complementing human abilities and
compensating for human limitations in the pursuit of overall flight safety, efficiency, and comfort. It does not
cover purely technological issues such as hardware performance and reliability, human factors issues related to
aircraft safety but specific to agents outside the flight deck such as air traffic controllers or company dispatchers,
nor many other important issues affecting flight deck design, such as cost and weight.
2.2 Users and Use of Document
This document is Part 1 of a two-part set. The objective of Part 1 is to provide a high level description
of the philosophy and its application to a generalized flight deck design process. Part 2 will provide more
detailed descriptions of design guidelines, test and evaluation issues, recommendations for how to apply the
philosophy, and methods for identifying and resolving conflicts among design principles and guidelines. Table 1
describes the users of this document and how the document supports their functions.
Table 1. Intended users and uses of the document.
Document User To Support By Means Of
Part 1 HSR managers High level program
funding/focus decisions
Informing, developing crew-centered
design mind-set
HSCT program
managers
High level design &
resource decisions,
formalize design process
Informing, developing crew-centered
design mind-set, institutionalizing
ideas
FAA managers Certification planning Informing, developing crew-centered
design mind-set
Airline managers Profitability &
operability
determination
Informing, developing crew-centered
design mind-set
Airline pilots Operability assessment Informing, developing crew-centered
design mind-set
Part 1 & 2 HSR researchers Design concept &
prototype development,
research issue
identification,
evaluation
Providing guidance, identifying
research issues through conflict
resolution, and providing test &
evaluation (T&E) methods
HSR engineers Requirements
development and design
concept and prototype
development
Providing rationale & guidance for
writing & checking requirements &
concepts through use of guidelines
and T&E methods
HSCT flight deck chief
engineer & chief pilot
Major flight deck design
decisions
Providing guidance in making
important flight deck design
decisions by using guidelines and
conflict resolution methods
HSCT lead designers Low level design
decisions
Providing guidance in selecting
design alternatives that embody
"good design practice" through use
of guidelines & conflict resolution
methods

5
FAA cert. pilots Flight deck certification Informing, providing
recommendations for methods of
evaluating design
Part 2 HSCT designers Low level design
decisions
Providing guidance in selecting
design alternatives that embody
"good design practice" through use
of guidelines & conflict resolution
methods

6
This document: (1) establishes a common perspective of what crew-centered design is, and where within
the design process it should be applied; and (2) provides a framework for developing increasingly detailed flight
deck design guidelines which can be supported by reference to specific guiding principles and philosophy
statements. The primary users of the document are managers, engineers, and researchers within NASA’s HSR
program. Secondary users are similar users within an HSCT airplane program and other participants within the
industry that will have a role in design through their interaction with the airplane program, such as Federal
Aviation Agency (FAA) and airline personnel. The better these participants understand a crew-centered design
philosophy, the better equipped they will be to contribute to the design process within the context of their
specified roles. For example, to the extent that certification is part of the process of assuring the "goodness" of
design, if FAA certification pilots understand crew-centered issues from the design perspective, and certify by
means similar to test and evaluation used throughout the design process, then perhaps certification of the flight
deck could be a more standard, expedient, and cost-effective process.
2.3 Organization of the Document
The remainder of this report is divided into four main sections (Sections 3-6), and three appendices
(Appendices A-C). Section 3 describes the design process, and where within that process the philosophy should
be applied. Section 4 describes the actual philosophy, guiding principles, and a framework for crew-centered
design guidelines, and begins to address how conflicts among principles and guidelines might be identified and
resolved. Section 5 provides concluding remarks, and Section 6 provides references. Appendix A describes test
and evaluation issues, including a representative sampling of tools and methods for evaluating the operability or
usability of design concepts. Appendix B lists the working assumptions about the HSCT environment and
aircraft currently listed by the HSR program. Appendix C identifies resource materials that can be used to find
sources for more details on issues described in this document. It includes a compilation of many standard
sources of relevant design guidance.
Part 2 of this document set will be developed within the next two years. It will include a more extensive
collection of design guidelines. It will provide more detailed information on how to apply the principles and
guidelines to flight deck design. It will also elaborate on tools and methods for measuring the effect of design
decisions on flight crew/flight deck performance earlier in the design process. A more detailed review of issues
relative to identification and resolution of conflicts and contradictions among principles and guidelines will also
be provided. A large database of relevant studies and materials will be compiled to serve as the rationale for
design decisions which can be traced through the guidelines and principles. Research issues related to the crew-
centered design philosophy will be identified.
Various users of the philosophy document may have quite distinct perspectives of and vocabularies for
design issues of interest. One method that will be pursued to provide multiple access and retrieval paths for the
philosophy statements, principles, and most importantly, the guidelines, is an electronic hypertext version of the
document. This electronic version could include the relevant links between the top-level philosophy statements,
the guiding principles, and the various guidelines, so that the justification and rationale for each principle or
guideline category can be traced back to the fundamentals of the philosophy itself. The initial method planned
for allowing multiple access methods will be to create access paths for: (1) HSR program managers and
researchers and others interested in the supporting documentation and theoretical rationale behind principles that
are structured by pilot roles; and (2) systems requirements writers and system designers that are based on the
flight deck features that are used to organize the design guidelines. These two different sets of access paths
should allow the different types of users to quickly retrieve the information they need using their own perspective
and vocabulary.

7
3.0 DESIGN PROCESS
3.1 The Overall Design Process
The process by which commercial flight decks are designed is complex, largely unwritten, variable, and
non-standard. The process is also overly reliant on the knowledge and experiences of individuals involved in
each program. That said, Figure 1 is an attempt to describe this process; it represents a composite flight deck
design process based on various design process materials that have been generated within, or provided to,
NASA’s HSR program. Although the figure is not intended to exactly represent the accepted design process
within any particular organization or program, it is meant to be descriptive of accepted design practice.
Definition of the terms used in the figure are included in the glossary. Note that the figure is purposely
oversimplified. For example, the box labeled "Final Integrated Design" encompasses an enormous number of
design and evaluation tasks, and can take years to accomplish. It could be expanded into a figure of its own that
includes not only the conceptual and actual integration of flight deck components, but also simulations, flight
tests, certification and integration based on these evaluations.
Test and
Evaluation
Aircraft
Functional
Requirements
Aircraft
System
Requirements
External
Requirements (Mission,
Customer, Flight Crew,
Environmental,
Regulatory, Program)
Previous Design,
Production, and
Operational Experience,
Technology Constraints
Flight Deck
Requirements
Other Systems
Requirements
Aircraft
Operational
Requirements
Flight Deck
Initial Design
Concepts
Other Systems
Initial Design
Concepts
Final
Integrated
Design
Figure 1. Simplified representation of the flight deck design process.
We believe that the crew-centered design philosophy presented in this document should affect the design
process in a number of places, which will be described in the next section. It is also important to note that we
believe the philosophy has implications for the design process itself. For example, the philosophy emphasizes
that total flight crew/flight deck performance is more important than performance of individual components,
suggesting that flight deck integration issues should be addressed prior to, or in parallel with, development of
individual flight deck systems or components (e.g., synthetic vision system for the HSCT). This appears to be
contrary to the way flight decks are traditionally designed. However, the inclusion of integration issues before
systems are completely specified is difficult. Also, while the philosophy includes a set of principles pertaining to

8
the flight deck as a product of design, it could also include principles of the design process. For example, we
could easily envision a principle stating that flight deck design, particularly issues pertaining to flight crew
operability, should be addressed as early as possible and with as many resources as other aircraft design areas,
such as propulsion, structures, and noise. Other "crew-centered" principles of the design process, such as
"simplify before automating," "perform pilot-in-the-loop evaluations early in design," and "test the corners of the
human performance envelope in evaluating man-machine systems," could also be generated. While some of these
design process issues will be discussed under other sections, generally, recommendations of ways that the design
process should be changed to be consistent with a crew-centered design perspective is beyond the scope of this
document. Several resources in Appendix C address these issues.
One particularly important aspect of the design process from the perspective of a crew-centered
philosophy is test and evaluation. Design changes are most costly once installed in an operational environment.
The earlier in the design cycle that problems and poor design decisions can be caught, the more easily and cost-
effectively changes can be made. Fully understanding and applying an explicit crew-centered philosophy of
design to highlight issues and potential design solutions that affect flight crew/flight deck performance is one way
good design can be assured early in the design cycle. But because the philosophy cannot be comprehensive and
completely unambiguous, there is no guarantee that a design which adheres to it will be good in every aspect.
Hence, a second aspect of crew-centered design is iteratively testing and evaluating preliminary concepts, with an
emphasis on pilot-in-the-loop evaluations, as an integral part of design. Adherence to the philosophy and specific
guidelines and requirements will assure a relatively good design, but test and evaluation provides the final
calibration (since aircraft systems are so complex, certification and line operation will for the foreseeable future
continue to provide the final usability testing). Many test and evaluation tools, methods, and evaluation
platforms are available. Appendix A provides more details about test and evaluation, especially concerning
aspects that are relevant to advancing a crew-centered perspective of flight deck design.
3.2 Where to Apply the Philosophy
One of the stated goals of this document is to help establish a common perspective among the different
researchers and managers participating in the HSR program with respect to the importance of a design
philosophy focused on the flight crew. Part of that perspective is where the implementation of this philosophy is
addressed in the design process. In the past, since a design philosophy and a design process have been largely
unwritten, the application of a philosophy to a design process has necessarily been informal and non-standard.
Figure 2 depicts where we believe the philosophy should impact the design process depicted in Figure 1.
The philosophy and its impact are shown with double lines to illustrate that this is prescriptive information based
on the views of the authors. As described in the footnotes at the bottom of the figure, there are some very
important points to make about where the philosophy affects the design process. First, the philosophy should
affect any step or stage of the design process where design decisions are made. For example, in an idealized
process, airplane functional requirements may strictly include only generic functions required of the aircraft to
operate within the mission environment, and thus should be affected minimally by crew issues such as function
allocation, interfaces and levels of automation. If functional requirements are not developed in this "pure" sense,
that is, they include flight deck functional requirements and/or function allocation decisions, then design decisions
are made implicitly within the process of developing functional requirements and the philosophy should affect
those design decisions. Second, although the philosophy is most commonly applied to "how to" decisions in
selecting design concepts that meet various requirements (i.e., the boxes labeled initial design concepts and final
integrated design), crew issues can also affect the "what" of design, that is, what the aircraft or the flight deck
must do, operationally or functionally. While the number of crew issues that can affect the operational and
functional "what" may be small compared to those that affect the "how to," especially at the aircraft level, they
are important. Obvious examples include habitat issues that affect aircraft operational requirements such as the

9
need to prevent bodily injury and preserve the health of the inhabitants of the aircraft. We believe that there are
other crew issues that affect hard operational requirements as well. For example, since the flight crew is
responsible for critical flight functions which require the pilots to perceive and respond to the external
environment, operational requirements exist for the aircraft to fly manual approaches and to follow "see and
avoid" procedures. While many of these crew-driven requirements overlap with regulatory and other
requirements, we believe that acknowledging the impact of crew-related issues such as the necessity of manual
flight, minimum flight deck size, and external vision requirements on the operation of the aircraft may highlight
conflicts with other constraints and requirements much earlier in the design process.
External
Requirements (Mission,
Customer, Flight Crew,
Environmental,
Regulatory, Program)
Design
Philosophy
Test and
Evaluation
Aircraft
Functional
Requirements
Aircraft
System
Requirements
Flight Deck
Requirements
Other Systems
Requirements
Aircraft
Operational
Requirements
Flight Deck
Initial Design
Concepts
Other Systems
Initial Design
Concepts
Final
Integrated
Design
Notes: (1) Philosophy should affect design process wherever design decisions are explicitly or implicitly made
For example, aircraft operational and functional requirements should be independent of design
decisions, but often they are not; function allocations, pilot interfaces, and flight deck
requirements are sometimes involved.
(2) Philosophy should affect the operation or function of the aircraft if pilot roles dictate that the
aircraft interact with the outside environment in certain ways (e.g., must be able to perform
a visual approach or manual landing because the pilot has ultimate authority over critical flight
functions).
Philosophy may affect
Philosophy definitely affects
Previous Design,
Production, and
Operational Experience,
Technology Constraints
Figure 2. Impact of philosophy on design process.
Generally, we believe the influence of a crew-centered design philosophy should be explicitly applied
earlier in the design process than is often acknowledged. Flight deck design is a complex and amorphous
process; design decisions, trade-offs, and resolution of conflicting constraints and requirements often are made
implicitly and early. If crew issues are not considered early, then design concepts can be carried forward and
major usability implications not discovered until they are very costly to isolate and change. Early introduction of
crew issues makes explicit that the philosophy, in part, includes requirements or constraints analogous to
requirements from other sources. In addition, the process of translating the philosophy into requirements, design
decisions and design concepts is ill-defined. The current understanding of human behavior necessitates that much
of the design guidance be soft rather than hard. The applicability of guidelines often depends on contextual

10
factors; there are many situations in which they must be overridden by some other consideration. Hence the
philosophy does not always translate into hard, quantifiable, requirements. This is why crew-centered principles
and guidelines are more often applied as general guidance in the "how to" of the design process rather than as
hard requirements.

11
4.0 THE PHILOSOPHY
The crew-centered flight deck design philosophy presented here begins with the explicit acknowledgment
that the flight crew, flight deck, and even the airplane itself are only parts of a much larger commercial air
transportation system. Other elements of this system include the airlines and their flight dispatchers and
maintenance personnel, weather forecasters, airport operators, air traffic controllers, and government regulators.
Mission success is the overall goal, and it depends upon the cooperation and performance of each of these
elements. Within this context, however, the philosophy contained in this document is limited to the operation of
the aircraft by the flight crew. Because human skills, knowledge and flexibility are, and will continue to be,
required in the operation of complex systems in the dynamic and often unpredictable aviation environment, flight
deck design should be crew-centered in the sense that it should support the flight crew in successfully
accomplishing the mission.
The crew-centered design philosophy espoused here can be described in its simplest form with the
following set of Philosophy Statements:
S-1. Each design decision should consider overall flight safety and efficiency. Combined flight crew/flight
deck system performance is more important than local optimization of the performance of any human or
automated component in that system.
S-2. Overall flight crew/flight deck performance and the performance of the human and automated
components are affected by qualitatively different sets of issues depending on the specific operational
roles in which pilots are viewed. Flight deck design should consider these different roles.
S-3. Humans and machines are not comparable, they are complementary (Jordan, 1963); that is, they possess
different capabilities, limitations, strengths and weaknesses, and there is a mutual dependence required
between humans and machines to successfully accomplish the mission. Safety and efficiency of flight
will be maximized by focusing on ways to develop and support the complementary nature of the flight
crew and the flight deck systems.
This philosophy is embodied in the following sections, which describe performance objectives, pilot
roles, principles, guidelines, and issues related to resolving conflicts among principles and guidelines. The
organization of the principles is determined by the various roles of the flight crew members, as described below.
The pilot roles also influence the organization of the categories of design guidance.
4.1 Performance Objectives
The general relationship between aircraft mission objectives, flight crew/flight deck performance
objectives, and flight crew and automation roles is depicted in Figure 3. The mission is to transport both
passengers and cargo from the departure to the arrival airport, and the objectives, in order of importance, are to
do this with safety, efficiency, and passenger comfort (although passenger comfort may outweigh efficiency in
certain cases, such as avoiding turbulence at the expense of a less efficient cruise altitude). The goal of the crew-
centered philosophy is to help in the design of a flight deck which assists the flight crew in accomplishing mission
objectives. Mission success depends on overall performance of the system formed by the flight crew and flight
deck automation. The philosophy suggests that overall performance of the flight crew/flight deck system is best
served by prescribing specific roles (not tasks) to the automation that support specific roles of the flight crew.
Defining the roles of the flight crew is useful in categorizing design principles as a way to highlight different sets

12
of crew issues. The test and evaluation measures by which flight crew/flight deck performance are assessed are
shown at the bottom of Figure 3, and are described in Appendix A.
Safety
Passenger
Comfor t
Efficiency
Flight Crew
Roles:
1. Team Member 2. Commander
3. Individual Operator 4. Occupant
Automation
Roles:
1. Substitute 2. Augmentor
3. Aid
Accuracy Workload
Situation
Awareness
Response
Time
Subjective
Assessment
Training
Efficacy
Measures
Test & Evaluation
Overall Flight Crew/Flight Deck Performance
(e.g., usability testing, pilot-in-the-loop evaluations)
Objective of Crew-Centered Flight Deck Design
Figure 3. The relationship between mission objectives and performance objectives.
4.2 Pilot Roles
The organizing scheme used for the generation and presentation of the guiding principles is based upon
the role of pilots as team members, the role of pilots as commanders, the role of pilots as individual operators,
and the role of pilots as flight deck occupants. These roles are nested rather than independent. That is, the pilot
is always an occupant, and is an operator while in the roles of commander and team player. Thus, there will be
some overlap in design issues related to the different roles. But we believe these roles highlight and distinguish
important categories of design issues that can affect human performance and overall flight crew/flight deck
performance.
With the complex systems, technologies, and operating environments that characterize modern
commercial aviation, how humans work with other "agents," human and automated, (e.g., in communication,
coordination, and allocation of functions) is a major design issue. The birth of Cockpit Resource Management
(CRM) was due to the realization that problems in communication and coordination among crew members were
contributing factors in a large number of accidents and incidents. Problems of communication and coordination
are not limited to between crew members; miscommunications between flight crew and air traffic controllers have
been well documented in Aviation Safety Reporting System incident reports. Further, automation "surprises"
reflecting pilot misunderstanding of automated systems such as the flight management system and autopilot

13
system are well documented (Sarter & Woods, 1992). The team member role addresses these issues. While
authority issues and the role of commander could be covered under the role of team member, we felt it was
important to call it out separately because of the significance of authority issues in defining the human-centered
philosophy. There is strong consensus that the pilot will continue to be ultimately responsible for safe operation
of the aircraft (e.g., Billings, 1991; Wilson & Fadden, 1991), and this should be a primary driver of function
allocation decisions. Supporting the pilot as an individual operator is the primary focus of most current human
factors guidance -- design must account for all that is known about how humans perform tasks. The role of
occupant was defined separately because it is easy to forget that the design must support the pilot in more than
the obvious mission functions; there are peripheral tasks and pilot needs that must be supported in the context of
the pilot as a human occupying a specific environment for a period of time. Each of these roles is described
below:
Pilots as Team Members: This reflects the role of pilots as members of a team that includes not only the
other flight crew members, but also elements of the flight deck automation, and in the larger context,
elements of a distributed system including air traffic controllers, airline dispatch, regulatory agencies,
etc. The issues involved include the need for communication, coordination, and shared functional
understanding among all team members to successfully accomplish tasks.
Pilots as Commanders: This reflects the role of each pilot, individually, as being directly responsible for
the success of the mission. The issues involved include the level of pilot authority over the flight deck
automation, and the ability of the pilot to delegate tasks.
Pilots as Individual Operators: This reflects the role of pilots as individual human operators working
within a complex system of controls and displays. The issues involved include many of the traditional
human factors disciplines such as anthropometrics, control/display compatibility, and cognitive
processing.
Pilots as Occupants: This reflects the role of the pilots as living organisms within the flight deck
environment. The issues involved include ingress and egress capability, protection from the radiation
and atmospheric conditions at the expected cruise altitudes, seating, lighting, and accommodation of
items such as food and drink containers.
A major benefit of organizing the guiding principles according to the pilot roles identified above, in the context of
the overall performance objectives framework, is that it serves as a bridge into the supporting research literature
on human factors and flight deck design; we believe that the roles represent distinctly different design concerns
and issues. The pilot roles also serve as one of the dimensions by which the design guidelines are categorized.
4.3 Automation Roles
As stated earlier, and as depicted in Figure 3 above, the philosophy suggests that overall performance of
the flight crew/flight deck system is best served by prescribing specific roles (not tasks) to the automation that
support specific roles of the flight crew. In this sense, the automation is always subservient to the flight crew. It
may substitute for the pilot entirely in conducting some functions and tasks, it may augment the pilot by
performing certain control actions, or it may aid the pilot in gathering and integrating information.

14
4.4 Design Principles
A fundamental purpose of constructing a set of principles to represent a philosophy, as defined in
Section 4.0, is for these principles to serve as practical guides and not merely abstract concepts. The difficulty
of accomplishing this balancing act between the practical and the abstract has long been recognized in many
fields. For example, in his classic work on strategy the military writer B.H. Liddell Hart (1967) observed that:
“... the modern tendency has been to search for principles which can each be expressed in a single word
-- and then need several thousand words to explain them. Even so, these ‘principles’ are so abstract that
they mean different things to different men, and, for any value, depend on the individual’s own
understanding... The longer one continues the search for such omnipotent abstractions, the more do they
appear a mirage, neither attainable nor useful -- except as an intellectual exercise.”
This document therefore strives to present the principles in a form that will result in consistent
interpretations, even though this may result in less elegant phrasing. The principles are listed below according to
the pilot roles described above, and are numbered as PT-x, PC-x, PI-x, or PO-x, for principles related to the
roles of team member (PT), commander (PC), individual operator (PI), or flight deck occupant (PO).
4.4.1 Pilots as Team Members
PT-1. The design should facilitate human operator awareness of his or her responsibilities, and the
responsibilities of the other human operators and automated flight deck systems, in fulfilling the
current mission objectives.
The flight deck design should ensure that each pilot remains aware of who or what system has been
allocated, and is actually performing, which functions or tasks. In addition, the human operators should be well
acquainted with the functional capacities of automated flight deck systems. This heightened level of awareness
of responsibilities and capabilities should help to prevent the problem of "nobody minding the store," which was
a contributing factor in the December 29, 1972 Eastern Airlines Flight 401 nighttime crash into the Florida
Everglades near Miami. In this accident, the flight crew became distracted while diagnosing the status of a gear
indicator light on the flight deck of the Lockheed L-1011, and didn’t notice that the autopilot had been
inadvertently disconnected and was allowing the aircraft to gradually descend.
PT-2. The design should facilitate the communication of activities, task status, conceptual models, and
current mission goals among the human operators and automated flight deck systems.
The flight deck automation should be designed to actively inform the crew of what it is doing, how, and
why, both to foster communication and to support the pilot's role as commander in determining whether
intervention is necessary. This includes feedback concerning mode status and human- or automation-initiated
mode changes ("pre-programmed" pilot inputs may result in mode changes that appear to be automation-
initiated). For example, the specific operating modes of the autoflight system need to be unambiguously
distinguishable to help prevent accidents such as the January 20, 1992 Air Inter crash near Strasbourg, France,
in which the Airbus A-320 flight crew is believed to have mistakenly selected a 3,300 feet per minute vertical
descent rate instead of a 3.3 degree descent angle. Because the HSCT could have even more complex autoflight
modes than modern conventional aircraft, communication of modes and autoflight system status may be even
more important. The automation should also, to the extent possible, observe human operator actions and changes
in aircraft state to infer the current goals, procedures, and tasks in progress. This could be as simple as
automatically displaying the checklists associated with active caution and warning messages, or as complex in
the future as monitoring crew inputs to suggest better ways of accomplishing a given task. In addition, the flight

15
deck design should support procedures and tasks which foster communication among the flight crew members
and aiding systems.
PT-3. The design should support the dynamic allocation of functions and tasks among multiple human
operators and automated flight deck systems.
The flight deck should be designed to facilitate the appropriate decomposition and dynamic allocation of
tasks. One example of how this is done in current aircraft is the separation of the autoflight system functions
into speed and directional control, so that the flight crew can easily choose to maintain manual control of the
aircraft’s flight path while delegating speed control to the autothrottles, instead of being forced into an “all-or-
nothing” use of the autopilot. The goal is to make sure that such allocations of functions are possible, and can be
performed quickly, easily, and unambiguously by the flight crew.
PT-4. The design should assure that team limitations are not exceeded.
Flight crew members working as a team are subject to fundamental group dynamics and human
limitations that affect their performance. For example, teams often suffer from group biases in problem solving,
conflicts in personality, and differences in leadership styles. Some of these issues have recently been addressed
by the airlines in the form of Crew Resource Management (CRM) training. However, the flight deck designer
should also acknowledge and accommodate such limitations, and should recognize that similar limitations often
exist when the flight crew and automated systems work together as a team. For example, designers need to be
aware that if caution and warning displays present information about the potential underlying cause of a
subsystem malfunction in an inappropriate manner, the flight crew may be induced to fixate on the proposed
diagnosis (which may be uncertain) to the point that they fail to consider other possibilities.
PT-5. Cooperative team capabilities (e.g. use of collective resources and cooperative problem solving)
should be used to advantage when necessary.
Just as the pilots as a team have inherent limitations, they also have inherent strengths. These include
such capabilities as brainstorming and cooperative problem solving. It is not the case that design should require
the use of such abilities; rather, it is important for the designer to recognize that these strengths exist and that
they should be used to maximum advantage when necessary. Similarly, the complementary nature of the flight
crew and the automated systems should be used to advantage when they work together as a team.
PT-6. The design should minimize interference among functions or tasks which may be performed
concurrently by multiple human operators or automated flight deck systems.
The design should assure that attentional, mental processing, or physical conflicts do not arise when
multiple flight crew members or automated systems are performing tasks concurrently. For example, the
monitoring required of an automated system while it is performing a task should neither usurp the flight crew’s
attention nor interfere with other tasks that the flight crew may be performing.
PT-7. The design should facilitate the prevention, tolerance, detection, and correction of both human and
system errors, using the capabilities of the human operators and the flight deck automation.
The primary concept represented by this principle is that the humans and automated systems on the flight
deck work in concert to assure that no one human mistake or system failure alone will cause a catastrophic event
to occur. The fact that mistakes and failures will indeed occur is acknowledged explicitly; the goal is to provide
error avoidance techniques, redundancy and error cross-checking among team members such that those mistakes
and failures are either prevented, or tolerated, trapped, and corrected before they have catastrophic consequences.

16
In addition, the designers should ensure that flight crew actions which may be inadvertent errors are reversible,
and that the flight deck design doesn’t obscure, compound, or exacerbate the presence or effects of mistakes or
failures. In some cases, failure detection and correction may be required so quickly that a purely human response
is not possible. For example, it is anticipated that a condition such as engine unstart on the HSCT will need to be
managed automatically because the inherent instability of the aircraft requires correction more quickly than could
be achieved by the flight crew.
4.4.2 Pilots as Commanders
PC-1. The human operator should have final authority over all critical flight functions and tasks.
The pilot is directly responsible for the safety of the aircraft, and given today’s technology, safety is
enhanced in a complex, dynamic environment if humans make final command decisions. This fact indicates that
the pilot should be able to manually intervene in any function or task which is potentially critical to the safety of
the flight. This may involve having active control, override capability, or the ability to command different levels
or modes of automated operation. For example, the Full Authority Digital Engine Controllers (FADEC’s) on
some current-generation aircraft have the authority to permanently shut down an engine, without flight crew
override capability, when the controller determines that continued operation may damage the engine. The risks of
taking this authority away from the flight crew were clearly demonstrated by the May 5, 1983 Eastern Airlines
Flight 855 emergency landing at Miami International Airport after maintenance personnel forgot to replace the
engine oil seals on all three engines of the Lockheed L-1011. In this case, the crew successfully restarted the
engine they had previously shut down due to oil starvation after the other two engines flamed out (also due to oil
starvation). A modern FADEC would have prevented the engine from being restarted, which may have resulted
in a forced ditching of the aircraft at sea. For the HSCT, a major implication of this principle is that the
requirement to see and avoid other aircraft when flying under visual meteorological conditions (VMC) dictates
that the pilots must "see" in front of the aircraft. If forward windows cannot provide this capability because of
fuselage geometry, some other means of forward vision must be supplied.
PC-2. The human operator should have access to all available information concerning the status of the
aircraft, its systems, and the progress of the flight.
Pilots should be able to access any available information that they believe is critical to safe flight. All
information useful during normal operations should be continuously displayed or readily available, and any
specialized information that might possibly be useful for detailed problem-solving should be accessible. No
sources of flight control information should be purposely withheld from the crew during flight. For example,
detailed subsystem information that is normally only used for maintenance, but which under rare circumstances
has implications for real-time operation, should not be withheld from the pilot, even if no checklists or procedures
explicitly call for its use. Accidents such as the July 19, 1989 United Airlines Flight 232 loss of all three
hydraulic systems on a McDonnell-Douglas DC-10 illustrate that unanticipated failure modes do indeed occur,
and that withholding available and potentially useful information from the flight crew may be imprudent.
PC-3. The human operator should have final authority over all dynamic function and task allocation.
Because the pilot is responsible for safety, and current automation is not capable of perfectly assessing
pilot intent or the external situation, the pilot should have the final authority over dynamic function allocation.
The automation should not be able to assign functions or tasks to the pilots, nor refuse to perform a function or
task assigned by the pilot unless it is unable to do so. It should also not be able to take tasks or control away
from the pilot without the pilot's approval. For example, automation must not take a task from the pilot's control
without consent simply because it detects that the pilot is in a high workload condition. Likewise, stick-pushers

17
(systems which automatically engage to decrease the angle-of-attack of the aircraft when it is close to stalling by
pushing forward on the control column) and other automated devices must not use control forces which exceed
the pilot’s ability to override them if necessary. It is acknowledged that the issue of dynamic function allocation
is controversial. There are many advantages of automated dynamic function allocation and adaptive aiding (e.g.,
see Rouse, 1994), such as management of pilot workload and task involvement (e.g., Parasuraman, 1993; Pope,
Comstock, Bartolome, Bogart & Burdette, 1994). If the complexity and predictability of system operation, from
the operator’s perspective, can be kept within acceptable limits, then perhaps automated dynamic function
allocation will become more viable on future flight decks.
PC-4. The human operator should have the authority to exceed known system limitations when necessary to
maintain the safety of the flight.
Since certain actions can cause physical damage to aircraft systems and components but can, under some
circumstances, save the aircraft from a catastrophic event, the pilot should be able to exceed known physical
damage limitations if he or she determines it is in the interest of overall safety. In some cases, such as the
February 19, 1985 China Airlines Boeing B-747 inflight upset and uncontrolled descent over the Pacific Ocean,
permanent structural damage may result from the subsequent recovery maneuvers which save the aircraft. Other
times the crew actions may only result in shortening the operating life of a component, such as exceeding the
rated temperature limits of the engines to get extra thrust during a windshear encounter. In both types of
situations the crew may exceed known limits and damage the aircraft, but in doing so may prevent a fatal crash.
4.4.3 Pilots as Individual Operators
PI-1. The human operator should be appropriately involved in all functions and tasks which have been
allocated to him or her.
Because situation awareness relies to some degree upon the operator being actively involved, the
designers must make sure that the level of engagement of the human operator is appropriate for all critical flight
functions and tasks for which he or she is currently responsible (based on the allocation of functions and tasks
determined by the human’s role as commander). If automation performs critical flight functions for which the
pilot serves as a backup, a level of involvement must be maintained under normal conditions such that the pilot is
prepared to take over the function under non-normal conditions. For example, in the previously mentioned China
Airlines B-747 incident in 1985, the flight crew was unaware of the actions of the autopilot as it compensated for
the adverse yaw created by a flameout on the number 4 engine. When the autopilot reached the limits of its
control authority and disengaged itself, the flight crew was unprepared to resume manual control and the aircraft
rolled over and began an uncontrolled descent.
PI-2. Different strategies should be supported for meeting mission objectives.
Different environmental, operator, and task factors may require that certain mission objectives be met
using different approaches, solution paths, and automation levels. The designers need to make sure that the
procedures and automation options available to the human operator are not so rigid that only one strategy exists
for fulfilling each goal or accomplishing each function or task. For example, the level of automation appropriate
for a function or task may depend on pilot workload: Lower automation levels (e.g., information aiding) may be
more appropriate in lower stress/workload situations, whereas very high stress/workload situations may require
more automated assistance. Further, the population of potential human operators for any aircraft contains
individuals with widely varying levels of operational experience, piloting skill, and cognitive style. The design of
the flight deck must take these differences into account, and not rely on a single definition of an "average" or
“worst case” pilot.

18
PI-3. The content and level of integration of information provided to the human operator should be
appropriate for the functions and tasks being performed and the level of aiding or automation being
used.
The information provided to the human operator should represent the correct level of processing and
integration of the raw data necessary to permit effective task performance. Although human operators often
exhibit better performance when they are able to operate perceptually using their manual skills and procedural
knowledge, deeper reasoning may be required and the information to support such reasoning may require
substantially different levels of abstraction or integration than what is appropriate for other tasks. Raw data
should be available for confirmation of processed information. An example of how important it is for the level of
information integration to be appropriate to the task is the failure of the flight crew to recognize insufficient
engine thrust during takeoff in the January 13, 1982 Air Florida Flight 90 crash into the 14th Street Bridge in
Washington, DC. In this case, the primary thrust-setting parameter was giving a false reading due to an iced-
over sensor probe on the Boeing B-737, but all other engine instruments correctly indicated that insufficient
thrust was being generated. Abbott (1989) demonstrated in a simulator experiment that better integration of the
engine parameter data in a manner appropriate to the task may have prevented this accident. For the HSCT, the
potential need for a synthetic vision system raises several questions associated with this principle. For example,
"how much processing of sensor data should be done before it is presented to the pilot?" "How should synthetic
vision information be integrated with other primary flight information?" "How should synthetic vision
information be different depending on whether it is used for active flight control or passive monitoring of the
autopilot?"
PI-4. Methods for accomplishing all flight crew functions and tasks should be consistent with mission
objectives.
The procedures and tasks of the human operator should make sense in terms of the mission objectives,
and should flow together in a logical order. For example, the human operators should not have to "trick" the
flight deck systems into performing a desired function, such as entering false winds aloft to move the top of
descent point.
PI-5. Procedures and tasks with common components or goals should be performed in a consistent manner
across systems and mission objectives.
The procedures and tasks that the human operator performs should be consistent when the goals are
common, so that a specific action does not have a completely different meaning or effect depending on the current
task or system state. For example, methods of disengaging the autothrottle or autopilot should be consistent
across autoflight modes. Failure to adhere to this principle may have been partly responsible for the April 26,
1994 China Airlines Flight 140 crash at Nagoya International Airport in Tokyo, in which the flight crew of the
Airbus A-300-600R inadvertently activated the go-around mode and was unable to disengage the autopilot using
the common technique of manually displacing the control wheel (since this method of disengaging the autopilot is
inhibited in the go-around mode). The autopilot then used its horizontal stabilizer trim authority to counteract the
flight crew’s control inputs, which created an unsafe trim condition of which the crew wasn’t aware.
PI-6. Procedures and tasks with different components or goals should be distinct across systems and
mission objectives.
The procedures and tasks that the human operator performs should be distinct when the goals are
different, so that unique actions are required to generate different effects. One example of how this principle can
be applied is the autoflight system interface of the McDonnell-Douglas MD-11, in which making a speed,

19
heading, or altitude intervention while the autopilot is engaged (by turning a knob), with the goal of departing the
current steady-state value, requires a distinctly different control input than invoking the respective hold mode (by
pressing a knob), with the goal of halting a transition in progress. An HSCT issue related to this principle
involves the flight control inceptor (wheel and column, center stick, or sidestick): since it is likely the flight
control laws will be different from conventional subsonic aircraft, should the control inceptor be distinctly
different than those used on previous aircraft to reinforce the fact that the underlying operation is different?
PI-7. The design should facilitate the development by the human operator of conceptual models of the
mission objectives and system functions that are both useful and consistent with reality.
The design determines, to a significant extent, how the human operator develops conceptual models of
the flight deck systems and automation and why they work the way they do. Designers should explicitly
recognize this fact, and facilitate the development of conceptual models that are both useful (i.e., they are
developed to an appropriate level of detail and support appropriate behavior with regard to the system), and
consistent with reality (i.e., they do not create misunderstandings about what the system is capable of doing and
how it does it). For example, flight crews on many current-generation aircraft have had difficulty understanding
some of the relationships between the various speed and vertical control modes of the autoflight systems, as
evidenced by the large number of deviations from assigned altitudes detected and reported. In the case of the
Boeing B-747-400, the mode annunciators on the primary flight display are organized by the autothrottle, roll,
and pitch control portions of the autopilot, while the mode control panel is organized according to the speed,
horizontal path, and vertical path interventions. Since both speed and vertical path are controlled by either pitch
or thrust in different autoflight modes, the disparity in organization between the mode annunciators and the mode
control panel doesn’t reinforce the conceptual distinctions that reduce the apparent complexity of possible mode
combinations. On the HSCT, an important design issue is whether the potential synthetic vision displays should
be conformal with the outside world as seen through the side windows. If a visual model inconsistent with reality
is formed by viewing a synthetic scene, and this inconsistency interferes with transitioning to using real world
information, then the design should attempt to make the synthetic scene information conform with the real world
information.
PI-8. Fundamental human limitations (e.g., memory, computation, attention, decision-making biases, task
timesharing) should not be exceeded.
Even though abilities vary between individuals, humans in general have fundamental characteristics that
limit their task performance. For example, limitations exist on the amount and endurance of information kept in
short-term memory, and on the ability to perform explicit complex computations, to make decisions involving
many interacting variables, and to complete several separate tasks simultaneously. However, tasks requiring any
amount of these activities should not be summarily allocated to automation (Fitts, 1951); rather, it is important
for the designer to recognize inherent limitations and to make sure that they are not exceeded. Design of systems
which are simple to understand and use is a fundamental method of assuring human limitations are not exceeded.
For example, an enormous amount of information will be available electronically onboard the HSCT, yet the
flight deck design clearly should not display all this information all the time because of human limitations in
perception and information processing. Another example is that humans have limitations in perceptual judgment
which may make it unreasonable to expect the flight crew to be able to judge the position of landing gear of the
HSCT on airport surfaces without some perceptual aid. Although flight crews can manage this task on
conventional aircraft, the unique geometry of the HSCT places the crew much further, physically, from the
landing gear.

20
PI-9. Fundamental human capabilities (e.g., problem solving, inductive reasoning) should be used to
advantage.
Just as humans have inherent limitations, they also have inherent strengths. These include such
capabilities as problem solving in novel situations, inductive reasoning, and error recovery. It is not the case that
tasks should be designed to require the use of such abilities; rather, it is important for the designer to recognize
that these strengths exist and that they may be used when necessary.
PI-10. Interference among functions or tasks which an operator may perform concurrently should be
minimized.
The procedural flow of tasks and the layout of equipment in the flight deck must be designed so that
conflicts do not arise when a human operator is performing more than one task concurrently.
At a physical level, flight deck controls such as thrust levers should be placed such that when a flight crew
member is using those controls his or her arm does not visually block any other display or control that may be in
use. And at a procedural level, task sequences that may likely or even possibly be completed in the same time
period should not call for conflicting actions (e.g., one procedure calls for activating a subsystem, while the next
procedure calls for deactivating the same subsystem).
4.4.4 Pilots as Flight Deck Occupants
PO-1. The needs of the flight crew as humans in a potentially hazardous work environment should be
supported.
Humans have basic physiological limitations, and the aircraft flight deck should protect them from the
hazards of the external environment. Examples include oxygen and pressurization, radiation exposure levels, the
effects of oscillation and vibration, and ingress and egress from the seating provided. Particular concerns for the
HSCT are protection from explosive decompression due to the high cruise altitudes, and protection from head
strikes due to the small cockpit size.
PO-2. The design should accommodate what is known about basic human physical characteristics.
Humans vary in physical characteristics, such as, reach, height, strength, etc. The flight deck design
should accommodate the variation among humans with respect to these characteristics, and the databases for
determining norms, variances and ranges should reflect the anticipated worldwide population of human operators.
For example, flight deck seating and control placement should not be designed merely to accommodate people
from 5’2” to 6’3” in height; rather, it should accommodate the differences in upper and lower leg lengths, torso
length, upper and lower arm lengths, and hand size and grip strength that exist between a 5th percentile Oriental
female and a 95th percentile African male. Of particular interest for the HSCT are potentially different pilot
vision and arm reach/manipulation requirements related to the higher than normal levels of oscillation and
vibration anticipated during taxi operations.
PO-3. Peripheral activities which are indirectly related to the mission objectives should be supported.
The flight crew engages in peripheral activities that may affect the safety, efficiency, or comfort of the
flight. Examples include preparation of passenger manifests, completing company paperwork, and making
public address announcements to the cabin crew and passengers. These should be identified and functionally
supported by the flight deck design, because paperwork or other items may obscure an important display if they
cannot be placed in a suitably designed location. Flight crew members also will be eating, drinking, and visiting

21
the cabin during the flight, so the flight deck design must accommodate food and drink containers and provide for
easy seat ingress and egress during flight operations. Any of these activities can interfere with pilot performance
if not properly accommodated by design.
PO-4. The design should account for major cultural norms.
An HSCT aircraft will be used by both multi-national and multi-cultural airlines. Conceptual models of
system function and methods for task performance, such as the inherent meaning of colors and accepted norms
relating switch positions to system status (e.g., in Britain it is common for room lighting to activate when the
associated switch is flipped down), often vary across cultures. These cultural norms should be recognized and
accommodated to the extent possible, and any violations must be identified as potential problem areas for
training flight crew members from those cultural backgrounds.
4.5 Framework for Design Guidelines
This section is provided as a bridge between the principles presented above and the functional
requirements, system requirements, flight deck requirements, initial design concepts, and final integrated design
as presented in the flight deck design process diagram in Figure 1. The current content of this section is also
intended to serve as an introduction to the planned collection and development of the complete set of guidelines,
which will be included in Part 2 of this document.
Because principles are general statements about functional design concepts that are theoretically driven
and in researcher’s language, they cannot necessarily be interpreted directly by the design engineer. The
principles provide the rationale for requirements and design concepts, but they must be translated into more
specific statements in language more appropriate for the design community. Guidelines, which are low level
statements intended to provide detailed guidance in making design decisions, are an effective way to make this
translation. Guidelines are more general than requirements, and thus adherence to them is often relative and
subjective rather than absolute and objective. Categories of guidelines are provided below to help the system
developer allocate functions and create initial design concepts that satisfy the principles and, thereby, embody the
underlying flight deck design philosophy.
Tables 2 and 3 show the categories of guidelines contained in this section. In Table 2, crew issues are
listed along the rows and flight deck features along the columns. Crew issues represent general classes of crew
centered constraints, and correspond to the following crew roles described earlier: Crew Coordination is an issue
relating to pilots as team members; Authority relates to pilots as commanders; Workload, Situation Awareness,
and Errors relate to pilots as individual operators; and Safety and Comfort relate to pilots as Occupants. Flight
deck features correspond roughly to a taxonomy identified through a scaling analysis of researchers' and
engineers' sorting of preliminary guidelines: Displays, Controls, Automation, and Alerting. In Table 3, these
flight deck features are combined to produce guideline categories specific to issues relating to these
combinations.
Guideline categories are generated for all combinations of crew issues and flight deck features (Table 2),
and all combinations of flight deck features (Table 3). This ensures that all pilot roles and the issues that are
relevant to them are addressed in all of the relevant design features of the flight deck, and that all issues relating
to how flight deck features interact are also represented. The guidelines related to flight crew issue by flight deck
feature combinations are organized by flight deck features since this should be more consistent with the way
designers think about these issues. Guidelines are stated in terms of the categories listed in the cells of the tables,
and these categories are underlined in the text to allow easier cross-reference to the tables.

22
Table 2. Guideline categories relating to combinations of crew issues and flight deck features.
Flight Deck
Features
Crew Issues Displays Controls Automation Alerting
Crew
cross checking cross checking clear retention
Coordination
interference interference responsibilities equal access
(pilots as equal access system state
team members)
Authority
information access limits automation levels error checking
(pilots as
commanders)
Workload
placement placement monitoring normal/non-normal
(pilots as ind. visibility visibility intervention importance
operators) response time response time complexity inhibits
task mapping procedure mapping content
integration effort integration
comparisons transcribing
mental
transformations
tactile cues
importance
clutter
access levels
Situation
system feedback process feedback automation feedback enabled status
Awareness
orientation prediction
(pilots as ind. units complexity
operators) labeling involvement
mode transitions
Errors
modes modes modes confusability
(pilots as ind. mental models mental models mental models
operators) actuation feedback actuation feedback states
prevention protections
detection consistency
symbol confusion distinction
orientation cues recovery
placement
stable reference
Safety
fatigue fatigue masking volume
(pilots as food/drink food/drink
occupants) inadvertent actuation
head strike
Comfort (pilots
fatigue environmental transients volume
as occupants) onset
To apply these guideline categories, it is recommended that the system designer consider the relevance of
each guideline category to specific design problems. The categories are explained in detail below, and sample
guidelines are provided for each one. Where possible, references to existing human interface guidelines and
standards are provided for further reference. This is intended to help the designer set quantities for specific

23
requirements based on the attributes of the system under consideration, and to trace the justification for specific
requirements to the appropriate literature.
These guideline categories and the high level guidelines provided comprise an initial attempt to describe
the crew-centered design philosophy at a more specific level than provided by the principles. While they are
intended to be fairly comprehensive, the process of collecting and/or developing lower level guidelines for Part 2
of this document may require modifications/additions to the material provided here.
4.5.1 Crew Issue/Flight Deck Feature Guidelines
Displays
Displays/Crew Coordination: For cross-checking, displays should be designed to allow both pilots to monitor
the activities of the other pilot, including data entry, mode selection, system management, and control tasks. To
reduce interference, displays should be designed to prevent the activities of one crewmember from conflicting
with those of another.
Displays/Authority: Information access should be allowed to any on-board information that could be used by the
flight crew in their decision making, because the full range of decision requirements cannot be anticipated by the
designers.
Displays/Workload: The placement of displays should minimize the amount of visual displacement required to
monitor multiple visual information sources. For example, the information required to perform common
combinations of tasks should be co-located or integrated. Displays that rely upon the relationship of the pilot’s
body with the axes of the aircraft should be located appropriately; for example, the primary flight display should
be located along the central forward axis of the pilot. To ensure visibility, displays should be easy to read from
normal pilot viewing angles and under the range of vibration and forces due to maneuvers, and pilots should not
be required to alter their position or posture to read a display. Display response times should provide positive
feedback of all flight crew inputs quickly enough that the pilot does not attempt to repeat the input, thinking that
the first attempt was unsuccessful, and quickly enough to prevent the pilot from having to perform tasks more
slowly than the natural pace or the pace required by other factors. If the system cannot provide the final result of
a commanded process within the required time, it should still indicate to the pilot that it is processing the
command. Displayed responses to flight control inputs should be rapid enough to prevent pilot induced
oscillations. To support appropriate task mapping, displays should be located and formatted to directly support
the pilot’s procedural task sequences. When a task or a common combination of tasks requires the use of
multiple pieces of information, these different pieces of information should be integrated into a common display
area. Such display integration is especially important when the crew needs to make comparisons between
multiple pieces of information. The need for the flight crew to perform mental transformations of information,
such as mental rotations, interpolations, extrapolations, or other calculations, should be minimized by presenting
the information in the form that is most immediately useful for the task or tasks at hand. In cases in which
information presentation order is not dictated by task sequences or natural relationships between the pieces of
information, the information should be ordered on the basis of importance, which should also be indicated by
visual coding methods. To prevent clutter, displays should not contain so much information that the pilot cannot
immediately find whatever information is needed. Issues include finding information again after the pilot has to
look away to perform another task, and accidentally confusing one piece of information for another because they
are too close together or are insufficiently differentiated. The number of steps or access levels required to get
information should be minimized. Those pieces of information that are needed frequently or needed to support
critical tasks should be accessible with the fewest steps.

24
Displays/Situation Awareness: To ensure appropriate system feedback, the flight crew should always have
access to information about what the various on-board systems are doing and that access should be appropriate
to the current pilot responsibilities. For example, during cruise flight, the crew should be able to monitor flight
control behaviors to verify that balance and thrust are symmetrical and that the autopilot is not correcting for any
undetected problems. The orientation of displays that depict an object with reference to another object should be
consistent with that relationship. For example, displays of the immediate external environment should be
oriented consistent with the relation of the aircraft’s major axes to the environment. Units of measure should be
provided for displays of values, particularly where multiple units may be possible, as in altitudes (feet vs.
meters), altimeter settings (inches of mercury vs. millibars), and fuel quantities (pounds vs. kilograms). Multi-
function display pages or windows should contain titles and labeling to indicate the page or window contents.
The crew should not have to scan the contents themselves to determine the function of the particular page or
window.
Displays/Errors: There are several types of mode errors associated with displays. In one, the display operates in
different modes itself and depicts information differently in the different modes. In another, the display indicates
the mode of some other device or system, such as the current autoflight control mode. In all cases, the display
should clearly and unambiguously indicate the current mode. For critical functions such as flight control, where
mode confusions can cause accidents, the mode indications should be given redundantly in several locations and
with several types of cues. For example, the designer should consider altering major elements of the primary
flight display in different flight control modes. The organization of display functions should support simple and
accurate mental models, to aid the pilot in figuring out how to access required information. Positive actuation
feedback should be displayed for all control inputs. To the fullest extent possible, displays should be designed to
prevent errors by supporting the natural sequences of actions required to perform tasks, providing the
information required with a minimum of display management, and ensuring that the information is unambiguous
and evident. Displays should also be designed to make the current state of the aircraft and all its systems
unambiguous and evident, to permit detection of errors immediately after they are made. Symbol confusion
should be reduced by designing symbology to be so distinct and distinguishable that it prevents any possible
confusion between different symbols and indicators. For spatially mapped displays, unambiguous orientation
cues should be provided to prevent map reversals. The designer may consider altering the whole appearance of
the navigation display, for example, depending on the display mode (heading/track-up or north-up). Generally,
display placement should prevent parallax, particularly when display locations must be matched to control
devices such as bezel button locations. In some cases, however, such as displays with a touch-screen overlay,
parallax may be used to advantage. Stable reference display elements should be provided on changing graphic
displays. For example, altitude indicators should depict altitude in reference to a stable point or scale.
Displays/Safety: Display design, placement, and visual characteristics (e.g., brightness, contrast) should reduce
pilot eye fatigue. Displays should be protected from food or drink
spills, and should not fail if such spills occur.
Displays/Comfort: Display design, placement, and visual characteristics should not cause pilot eye fatigue.
Controls
Controls/Crew Coordination: For cross-checking, controls should be designed to allow each pilot to determine
what control inputs are currently being made by the other pilot. To reduce interference, controls should be
designed to prevent the activities of one crewmember from conflicting with those of another while performing
different tasks. To ensure equal access, control devices that may need to be operated by either crewmember as
pilot flying or pilot not flying or during abnormal events, should be accessible by both pilots. Control devices
critical to safe flight should be placed so that either pilot can operate the devices without disrupting their other
tasks when operating the aircraft alone.

25
Controls/Authority: With respect to control limits, pilots should be able to command the full range of system
performance or capability. If protection limits are provided, the control devices should only prevent the crew
from unintentionally violating limits but allow the crew to do so intentionally without disrupting other tasks. The
protection systems should not be designed so they can override the flight crew’s inputs.
Controls/Workload: Control placement should minimize pilot physical resource conflicts. For example, it
should prevent the pilot from having to make simultaneous or nearly simultaneous control inputs in widely
separated locations. Also, those controls that relate to the position or orientation of a device (or the aircraft
itself) should be located consistently with that position or orientation. For example, flight control device
movement should be consistent with the movement axes of the aircraft. Control functions should have good
visibility and be readily apparent. If a device is used for multiple functions, all the available functions should be
indicated; however, the use of a single control device to perform multiple functions is discouraged due to the
increased risk of mode errors. The response time of feedback to control inputs should be rapid enough to prevent
multiple input attempts or pilot induced oscillations. For procedure mapping, if control device placement is not
dictated by such concerns as immediate access, popular use, or relation to pilot body position and orientation,
placement should be consistent with the order of pilot procedures. The amount of effort required to operate a
device should be such that inadvertent actuation is unlikely, use of the device does not cause fatigue, and the pilot
can override built in protections. For example, the input force required to counteract the automatic “stick
pusher” operation should not be greater than that possessed by the weakest pilot of the projected user population.
To reduce the workload associated with transcribing, the flight crew should not be required to enter the same
information into any one system multiple times, or to enter the same information into multiple systems. Once the
crew has entered the information into one system, it should be transferable to other systems. To make use of
tactile cues, the flight crew should be able to find and identify control devices by touch, and determine by touch
whether previous actions have actuated the devices.
Controls/Situation Awareness: To ensure that the flight crew has adequate process feedback, control devices
should reflect the states of the processes they are controlling. This allows the crew to determine process state
from observing or monitoring the behavior of the control device, and it facilitates graceful transfer of control
because the crew can assume control with the device in the proper position.
Controls/Errors: There are several types of mode errors associated with controls. In one, the device is in the
wrong mode for the input being attempted. An example is the wrong control display unit (CDU) page being
displayed for the operation desired. In this case, an input can have unintended effects. The system should be
designed to prevent this type of error by providing unambiguous indications of system state, and to allow easy
recovery from this type of error by ensuring that inputs can be canceled or reversed. In another, a single device
may be used to select multiple system modes, such as a single knob or push-button used to select multiple flight
control modes. In this case, the system should be designed to prevent the selection of an undesired mode.
Methods to accomplish this include requiring very different actions to select the different modes and clearly
indicating the selected mode at all times. The operation of control devices should be consistent with the simple
and accurate mental models the flight crew develop in training of the process being controlled. For example, a
mimic diagram of a process control system (such as the hydraulic system) might provide control points for valves
and actuators. Positive actuation feedback that a device has been activated should be provided. For functions
critical to safe flight, such as autopilot status, these indications should be salient enough that pilots cannot miss
them. Protections should be provided for potentially destructive actions, such as deleting a flight plan. For steps
that can delete data, a confirmation step should be required and the action should be reversible. All types of
protections should allow pilot override with unambiguously intentional action. Consistency should exist between
actions with similar goals. For example, if the same option appears on multiple display pages, it should always
appear in the same location on all pages with the same label, and it should work the same way. As another
example, one type of pilot action should always be used to de-select the current flight control mode so the pilot

26
does not have to determine the current mode and remember what specific action is required to de-select it.
Similarly, distinction should exist between actions with dissimilar goals. For example, the actions required to
select different types of autoflight modes should be different. For error recovery, the systems should be designed
to allow the pilot to easily correct any errors, assuming that the guideline above for rapid detection of errors is
followed and errors are detected quickly.
Controls/Safety: Control design, placement, and force requirements should not cause pilot fatigue. Controls
should be protected from food or drink spills, and should not fail if such spills occur. Control devices should be
designed to prevent inadvertent actuation due to ancillary pilot activities, such as seat ingress or egress or using
food trays, cups, documentation, or other objects. Control devices should be designed to prevent inadvertent
actuation from pilot head strikes, and to prevent such head strikes from injuring the pilot.
Controls/Comfort: The crew should be able to adjust environmental parameters to maintain a comfortable
working environment.
Automation
Automation/Crew Coordination: To ensure clear responsibilities, it should be conspicuous what activities each
crewmember and the automation are currently responsible for. The crew must be able to determine immediately
whether a function is under automatic, semi-automatic, or manual control, and if a function reverts from
automatic to manual control, that reversion must be annunciated unambiguously to the crew to ensure they are
aware of the reversion. The current system state of each subsystem should also be clearly indicated, so that if
control is transferred from automation to the pilot he or she can take control of the process without disruption.
Automation/Authority: Pilots should be able to select or command any automation level that the flight deck
systems can provide. If the automation is unable to perform at the selected level, it should inform the pilot that it
cannot do so and why, and operate at the highest level available.
Automation/Workload: To reduce workload associated with monitoring, automation should not be designed so
the pilot is required to continually watch it over long periods of time. The flight crew also should be able to
intervene directly, and at any time, in automated processes. This means that there should be feedback about what
the automation is doing, and the crew should be able to reassume control from the automation without unduly
disrupting the process being controlled. The complexity of a system should be balanced with the need to retain
simplicity so the pilot can readily understand how the automation functions, what the automation is doing, and
how to make the system performed desired functions. This is necessary because an overabundance of system
capabilities, functions, and modes can cause pilots to make errors, and many pilots do not use advanced features
of systems such as the Flight Management System because the benefits do not seem to outweigh the additional
training and workload required to use them.
Automation /Situation Awareness: The crew should always have access to automation feedback so they can
intervene, if needed, in the process the automated systems are controlling. There should be a clear indication of
what automated systems are currently programmed to do so the crew can predict automation behaviors
accurately. For example, a pilot should be able to determine quickly whether the aircraft will capture an altitude
in its current flight control mode. To reduce complexity, automation should be designed to support simple but
accurate conceptualizations of how it operates so pilots can easily determine what it is doing and what it is going
to do. Automation should be designed so pilots can retain an appropriate level of involvement in the process in
order to maintain situation awareness and skill levels. When automated systems begin a mode transition, that
mode change should be annunciated to the crew in a salient way to ensure that the crew is aware of it. This is

27
particularly important for mode changes that were the result of earlier flight crew programming or were not
commanded by the crew at all (such as mode reversions due to loss of a guidance signal).
Automation/Errors: The current automation modes should be readily apparent to both pilots. It should not be
possible to confuse modes, either by selection or by symbology of mode annunciations. Automation should
support simple and accurate mental models of its operation so the flight crew can easily determine what
automation is doing and anticipate what it is going to do. Feedback about the current states of the automated
systems and the process they are controlling should always be provided.
Automation/Safety: To prevent masking, automation behavior should not be made so smooth that the pilot loses
information about what the automation is doing. Any information that is masked kinesthetically should be
replaced by other means such as with visual displays, though the ability of the pilot to directly sense automation
control actions is often preferable.
Automation/Comfort: Automation actions should not produce disruptive transients. For example, transitions
between modes or transfer of control between crew and automation should not cause sudden changes in system
state, except when the crew forces such a sudden change intentionally.
Alerting
Alerting/Crew Coordination: Alerting systems should provide retention, with all alert messages retained in a log
so the crew can review them later. This is particularly important if one pilot can cancel or clear an alert message
before the other pilot has a chance to review it. To ensure equal access to alerts, they should be given in a way
that presents them equally to both crew members.
Alerting/Authority: To the extent that the flight deck systems can provide error checking of crew inputs, the
system should alert the crew of the condition or situation but should not override the crew if they persist.
Alerting/Workload: Status indications should permit the flight crew to quickly and easily distinguish between
normal and non-normal situations. For example, the designer may specify that many status indicators remain
quiet and dark during normal operations to avoid drawing the crew’s attention unnecessarily. Alerts should be
distinguishable based on importance and the immediacy of response required. Alerts that do not need to be
recognized by the crew immediately during highly critical flight phases, such as takeoff and landing, should be
inhibited until the crew can attend to them without disrupting critical tasks. Critical alerts should provide useful
content along with the alert itself (such as the voice annunciations of the Ground Proximity Warning System -
GPWS). When possible, alerts that are associated in a meaningful way should be integrated.
Alerting/Situation Awareness: The enabled status of alerting systems (i.e., whether the systems are active)
should be indicated to the crew. The crew should not be able to unknowingly operate the aircraft with an alerting
system disabled. For example, if the Ground Proximity Warning System has been disabled by pulling a circuit
breaker, this fact should be clearly communicated to the flight crew.
Alerting/Errors: To reduce the chance of confusability, alerts should be clearly distinct.
Alerting/Safety: Aural alert volume should be loud and clear enough that the crew cannot miss the alerts, but not
so loud as to disrupt other pilot responsibilities such as radio communications.
Alerting/Comfort: Aural alert volume should be loud enough that the crew cannot miss the alerts, but not so
loud that it causes discomfort. The onset of alerts should not be so sudden that it unnecessarily startles the crew.

28
Table 3. Guideline categories relating to combinations of flight deck features.
Flight Deck
Features
Displays Controls Automation Alerting
Displays
symbol consistency
format consistency
layout consistency
coding consistency
distinction
Controls
direction consistency symbol consistency
proportional
movement
layout consistency
contiguity motion consistency
feedback distinction
Automation
commanded/actual feedback interactions
display management override
pilot
review/confirmation
Alerting
content acknowledgment authority limits consistency
salience review faults conflicts
highlighting contradictions
consistency combinations
display access distinction
4.5.2 Flight Deck Feature/Flight Deck Feature Guidelines
Displays/Displays: For symbol consistency, different displays should not use different symbols to represent the
same thing. For format consistency, similar functions of different displays should have a common format. For
example, latitude/longitude coordinates should be represented in the same way across all devices and information
sources (including paperwork) that use or display them. For layout consistency, similar functions should appear
in similar locations on all displays that use them. For example, if an Enter function is provided on multiple
displays, pages, or windows, it should appear in the same place every time. To maintain coding consistency,
different displays should use the same visual coding techniques to represent the same intention. For example,
color, size, and highlighting should have consistent meanings across all displays and information sources,
including paperwork. For distinction, different functions should have readily apparent differences in appearance
to prevent the crew from selecting a different function than intended.
Displays/Controls: To maintain direction consistency, control devices that affect the movement of an object on a
display should cause movement of the object that is consistent with the direction of control movement. Control
devices that affect the movement of an object on a display should use proportional movement to ensure that
movement of the object is consistent with the magnitude of control movement. For contiguity, display indications
related to control actions should if possible be placed close to the control device. For example, if keyboard input
causes text to appear on a display far removed from the keyboard, a secondary display should be provided next
to the keyboard so the pilot does not have to look far away from the keyboard to check the input. Positive
feedback should be given for the operation of every control device. Tactile feedback should be provided to
indicate that the control has been actuated, and positive feedback of system acknowledgment should be provided
to prevent the pilot from attempting multiple inputs due to lack of response. For example, if the pilot attempts to
select a flight control mode and the system is not properly configured for that mode, an indicator to this effect

29
should be provided; having the system simply not assume the selected mode may imply that the control actuation
was not received by the system, and the pilot may attempt multiple inputs.
Displays/Automation: To help the crew effectively monitor automation control actions, indications of
commanded and actual values should be provided for functions under automated control. If automation is
authorized to perform display management, such as switching display pages or windows under certain conditions,
such management should not disrupt ongoing pilot activities.
Displays/Alerting: For alerts that require an immediate response, the content of the message should be contained
in the alert itself; the pilot should not have to refer to multiple display sources before taking action. Critical
alerts should be presented aurally, since sounds don’t require directed attention. The salience of alerts presented
on visual displays should be sufficient to draw the crew’s attention to the display. However, flashing messages,
for example, are not recommended because they can be hard to read; instead, any flashing should be applied to
the background or to display elements such as highlighting that the crew does not have to read. In keeping with
the previous guideline, important or new information associated with an alert should be displayed using
highlighting techniques so the crew does not have to search a display to find the information needed. For
consistency, an alerting philosophy should be applied to the overall flight deck so the crew does not have to
remember what type of action is required to access a specific alert message. Also, when information associated
with an alert is contained on a display page or window that is not currently shown and the alerting system has the
authority to automatically display that page or window, the designers should take care that such display
reconfiguration does not restrict flight crew display access or disrupt ongoing crew activities.
Controls/Controls: To maintain symbol consistency, different control devices should not use different symbols
for the same thing. For layout consistency, different control devices that support the same functions should have
the same layouts. For example, all keyboards should have the same key layout. For motion consistency, control
devices that are intended to behave the same way should employ consistent motions. For example, if a clockwise
rotation is used to increase a particular system value, then all rotary control devices of the same type should work
the same way. To maintain distinction, different control devices that are intended to behave differently should
appear and feel dissimilar.
Controls/Automation: Control devices should provide feedback as to the effects of automation on the states of
the processes they are controlling. This allows the pilot to determine process state from observing or monitoring
the behavior of the control device, and it facilitates graceful transfer of control because the pilot can assume
control with the device in the proper position. To allow for overrides, an unambiguous means should be provided
for the crew to take manual control of an automated process. To allow for pilot review and confirmation, lengthy
commands constructed by the crew should not be sent to the automation for execution until the crew has had the
opportunity to check the commands for accuracy.
Controls/Alerting: The crew should be able to acknowledge alerts without erasing or deleting the information
contained in the alert. The crew also should be able to review the contents of previous alerts by accessing them
from a message log.
Automation/Automation: Automation features should not have complex or subtle interactions that prevent the
crew from effectively monitoring automated actions or intervening in automated processes. Automation features
should also not interact in ways that create seemingly unpredictable system behavior.
Automation/Alerting: When an automated function nears its control authority limits, the crew should be alerted
in time to intervene effectively. The crew should be alerted whenever automation encounters faults that call into
question its ability to perform at the required level of reliability and accuracy.

30
Alerting/Alerting: For consistency, alerts with similar intentions should have similar presentations. To reduce
conflicts for crew attention, multiple alerts should not be given simultaneously unless they are clearly prioritized.
Alerting systems also should be integrated to avoid contradictions in information given to the crew. For example,
it should not be possible for one on-board system to tell the crew to climb and another to tell the crew to descend.
Multiple alerts should be integrated into a single higher level combination alert when doing so would give the
crew the most direct insight into the nature of the underlying problem. For distinction, different alerts with
different intentions should sound and appear dissimilar.
4.6 Conflict Resolution
Those involved in the flight deck design process know that design decisions involve compromise.
Economic, regulatory, safety, and operational constraints continually conflict. In the sense that human-centered
design principles and guidelines are flight crew constraints that help shape functional, flight deck design and
integration, and systems requirements, they may conflict with other constraints, such as market, regulatory,
physical, etc. More important, at least within the scope of this document, is the fact that these principles and
guidelines will sometimes create conflicts among themselves in the process of developing design concepts and
making design decisions. It is the belief of the authors that guidance on identifying and resolving these conflicts
may be one of the most useful services this document can provide.
We believe that there may be a general priority order assigned to classes of principles and individual
principles. For example, those that involve the pilot as team member may generally be higher priority than those
that involve the pilot as commander, which may generally be more important than those that involve the pilot as
an individual operator and so forth. There may be generally applicable fixed priorities among individual
principles as well. For example, principle PI-1 states that the pilot should be appropriately involved in all critical
flight functions and tasks for which he or she is responsible. Yet in certain conditions, this involvement may
exceed attentional and information processing capacity of the pilot (a violation of PI-10, i.e., fundamental human
limitations should not be exceeded), leading to high workload and pilot errors. Hence, one might argue that PI-
10 has a higher fixed priority than PI-1.
But in the final analysis, which principle or guideline takes precedence over another in regard to
developing a specific design concept or making a specific design decision, is usually context- and issue-specific.
Therefore, methods and metrics are needed to identify and resolve conflicts among principles and guidelines.
Often, resolution among competing principles or guidelines is left to the individual developing the design concept
or making the design decision. A multi-disciplinary team using consensus management techniques to maintain
consistency of design concepts and design decisions with various guidelines and to resolve conflicts is often used,
and is recommended here as a more reliable and consistent method by which to make such trade-offs. We
advocate, where possible, that some objective criteria be used to resolve conflicts. This may be the same set of
criteria that is used to validate requirements or evaluate initial concepts. Test and evaluation will ultimately
determine if the trade-offs that were made during the design process were appropriate. It is important to note that
conflict resolution should be guided by the performance objectives shown in Figure 3; that is, the effects of the
trade-offs among principles and guidelines on overall flight crew/flight deck performance, flight crew
performance, and individual pilot performance, in that order, should be assessed. Where major differences of
opinion or controversy surround conflicts among principles or guidelines, trade studies to evaluate different
design solutions derived from different weighting of the importance of competing principles or guidelines might
be appropriate. Part 2 of this document will address the issue of conflict resolution in greater detail.

31
5.0 CONCLUDING REMARKS
A crew-centered flight deck design philosophy has been described which seeks to elevate human
performance and system operability design issues to the same level of importance as the past focus on
technological issues, such as hardware performance and reliability, and to give them the same prominence as
other major aircraft design areas such as aerodynamics and structural engineering. A conventional design
process is first outlined, and points in this process at which it is appropriate to apply the crew-centered design
philosophy are identified.
The philosophy itself is expressed as a set of design philosophy statements, guiding principles, and high-
level design guidelines focused on issues related to the respective roles of the flight crew and the flight deck
automation. The philosophy casts the pilots in the roles of commander, team member, individual operator, and
occupant, which helps to identify major categories of design issues important to a crew-centered approach. The
philosophy casts the flight deck automation in the role of a tool whose single purpose, regardless of the level of
sophistication and complexity, is to aid the pilot in accomplishing the mission. Note that the philosophy
explicitly assumes that the flight crew will remain an integral component of safe and efficient commercial flight
for the foreseeable future. The basis for this assumption is that human skills, knowledge, and flexibility are
required in the operation of complex human/machine systems in the unpredictable and dynamic air transportation
system environment. The philosophy also suggests that the success of the overall flight crew/flight deck system
depends on the designer understanding the total system, including its human and automated components and the
way these components interact to accomplish the mission.
Two matrix structures are presented to organize the large number of design guidelines that exist in the
literature and to aid the process of identifying design areas/issues for which design guidelines are lacking. These
matrices account for both the roles of the flight crew and for different categories of flight deck features (i.e.,
displays, controls, automation, and alerts). High-level guidelines were provided for each cell of both matrix
structures, primarily to serve as descriptors of the classes of specific guidelines that will eventually be identified
relevant to each cell.
Whenever design decisions are made, they involve trade-offs among benefits and risks associated with
different design solutions. In terms of the philosophy, trade-offs will be required between human-centered
priorities and other priorities such as costs, weight, and hardware reliability. Further, there will be trade-offs
between competing principles and guidelines within the philosophy. General guidance and methods for resolving
such conflicts are presented as an important part of the overall approach, although further work is planned to
provide more specific assistance. Finally, it is argued that adhering to a human-centered design philosophy is
necessary but not sufficient to assure a good design. To improve total system performance, early and continuous
test and evaluation of design concepts, using pilots representative of the actual airline flight crews who will
routinely fly the aircraft, is a necessary complement to a solid "up-front" set of design principles and guidelines.
Proposed test and evaluation methods, experimental measures, scenario development guidance, etc., are described
in Appendix A.
Many engineers and designers would claim that they already perform human-centered design. It is
important to note, however, that we do not define human-centered design as simply applying "human factors" to
the design process. Rather, we believe that an explicit design philosophy must be clearly described and applied
systematically within the framework of a well-defined design process. This document is intended to be a first
step in this approach.

32
6.0 REFERENCES
Abbott, T. S. (1989). Task oriented display design: concept and example (NASA TM-101685). Hampton, VA:
NASA Langley Research Center.
Adams, J. A. (1989). Human factors engineering. New York: MacMillan.
Air Transport Association of America. (1989, April). National plan to enhance aviation safety through human
factors improvements. Washington, DC: Author.
Bailey, R. W. (1982). Human performance engineering: A guide for system designers. Englewood Cliffs, NJ:
Prentice-Hall.
Billings, C. E. (1991). Human-centered aircraft automation: A concept and guidelines (NASA Technical
Memorandum TM-103885). Moffett Field, CA: NASA Ames Research Center.
Braune, R. J., Graeber, R. C., & Fadden, D. M. (1991). Human factors engineering - An integral part of the
flight deck design process. AIAA Paper 91-3089. Presented at the AIAA, AHS, and ASEE Aircraft
Design Systems and Operations Meeting in Baltimore, MD, September 23-25, 1991.
Card, S. K., Moran, T. P., & Newell, A. (1983). The Psychology of Human-Computer Interaction. Hillsdale, NJ:
Lawrence Erlbaum.
Ericsson, K. A. & Simon, H. A. (1993). Protocol analysis: Verbal reports as data. Cambridge, MA: MIT Press.
Fitts, P. M. (Ed.). (1951). Human engineering for an effective Air-navigation and Traffic-control system.
Washington, DC: National Research Council, Committee on Aviation Psychology.
Gould, J. D. (1988). How to design usable systems. In M. G. Helander (Ed.). Handbook of human-computer
interaction (pp. 757-789). Amsterdam: North-Holland.
Hach, J. -P., & Heldt, P. H. (1984). The cockpit of the Airbus A310. In Luft- und Raumfahrt, Vol. 5, 3rd
Quarter, 1984, p. 67-76. Cologne, Germany: Deutsche Lufthansa A.G.
Hart, B. H. L. (1967). Strategy (2nd rev. ed.). New York: Frederick A. Praeger.
Helander, M. G. (Ed.). (1988). Handbook of human-computer interaction. Amsterdam: North-Holland.
Heldt, P. H. (1985). Control systems for the Airbus design and functional experience - cockpits. Presented at the
Fachgesparechs der Gesellschaft fuer Reaktorsicherheit in Munich, Germany, November 8, 1985.
Cologne, Germany: Deutsche Lufthansa A.G.
Jordan, N. (1963). Allocation of functions between man and machines in automated systems. Journal of Applied
Psychology, 47(3), 161-165.
Lehman, E., Rountree, M., Jackson, K., Storey, B., & Kulwicki, P. (1994). Industry review of a crew-centered
cockpit design process and toolset (Interim Report, Aug-Sep 1993). Dayton, OH: Veda, Inc.

33
Lewis, C. H., Polson, P. G., Wharton, C. & Rieman, J. (1990). Testing a walkthrough methodology for theory-
based design of walk-up-and-use interfaces. Proceedings of CHI’90 Conference on Human Factors in
Computer Systems (pp. 235-241). New York: Association for Computing Machinery.
Nielson, J. (1993). Usability Engineering. Cambridge, MA: Academic Press, Inc.
Norman, D. A. (1986). Cognitive engineering. In D. A. Norman, & S. W. Draper, User-centered system design:
New perspectives on human-computer interaction. Hillsdale, NJ: Lawrence Erlbaum.
Norman, S. D., Billings, C. E., Nagel, D., Palmer, E., Wiener, E. L., & Woods, D. W. (1988). Aircraft
automation philosophy: A source document, (pp. 163-198). In S. D. Norman & H. W. Orlady (Eds.),
Flight Deck Automation : Promises and Realities. NASA Conference Publication CP-10036. Moffett
Field, CA: NASA Ames Research Center.
North, R. A., & Riley, V. A. (1988). W/INDEX: A predictive model of operator workload. In G. R. McMillan,
D. Beevis, E. Salas, M. H. Strub, R. Sutton, & L. Van Breda (Eds.), Applications of Human
Performance Models to System Design. New York: Plenum Press.
Parasuraman, R. (1993). Effects of adaptive function allocation on human performance. In D. J. Garland & J. A.
Wise (Eds.), Human factors and advanced aviation technologies. Daytona Beach, FL: Embry-Riddle
Aeronautical University Press.
Polson, P. G. & Lewis, C. H. (1990). Theory-based design for easily learned interfaces. Human-Computer
Interaction, 5(2&3), 191-200.
Polson, P. G., Lewis, C. H., Rieman, J. & Wharton, C. (1992). Cognitive walkthroughs: A method for theory-
based evaluation of user interfaces. International Journal of Man-Machine Studies, 36
, 741-773.
Pope, A., Comstock, R. J., Bartolome, D. S., Bogart, E. H. & Burdette, D. W. (1994). Biocybernetic system
validates index of operator engagement in automated task. In M. Mouloua & R. Parasuraman (Eds.),
Human performance in automated systems: Current research and trends. Hillsdale, NJ: Lawrence
Erlbaum Associates.
Rasmussen, J. (1986). Information processing and human-machine interaction: An approach to cognitive
engineering. New York: North-Holland.
Regal, D. M. & Braune, R. J. (1992). Toward a flight deck automation philosophy for the Boeing high speed
civil transport (SAE Technical Paper 921133). Presented at the 22nd International Conference on
Environmental Systems, Seattle, WA.
Rieman, J., Davies, S., Hair, D. C., Esemplare, M., Polson, P. & Lewis, C. (1991). An automated cognitive
walkthrough. Proceedings of CHI ’91 Conference on Human Factors in Computing Systems (pp. 427-
428). New York: Association for Computing Machinery.
Riley, V. A. (1992). Human factors issues of data link: Application of a systems analysis (SAE paper 922021).
Paper presented at the meeting of Aerotech 92, Society of Automotive Engineers, Anaheim, CA.
Riley, V. A., Lyall, E., Cooper, B., & Wiener, E. L. (1993). Analytic methods for flight deck automation design
and evaluation, phase one report: Flight crew workload prediction (FAA contract number DTFA01-91-
C-00039). Minneapolis, MN: Honeywell Technology Center.

34
Rouse, W. B. (1994). Twenty years of adaptive aiding: Origin of the concept and lessons learned. In M.
Mouloua & R. Parasuraman (Eds.), Human performance in automated systems: Current research and
trends. Hillsdale, NJ: Lawrence Erlbaum Associates.
Rouse, W. B., Geddes, N. D., & Curry, R. E. (1987). An architecture for intelligent interfaces: Outline of an
approach to supporting operators of complex systems. Human-Computer Interactions, 3(2), 87-122.
Sanders, M. S. & McCormick, E. J. (1993). Human factors in engineering and design (7th ed.). New York:
McGraw-Hill.
Sarter, N. B., & Woods, D. D. (1992). Pilot interaction with cockpit automation I: Operational experiences with
the flight management system. International Journal of Aviation Psychology, 2
(4), 303-321.
Van Cott, H. P., & Kinkade, R. G. (1972). Human engineering guide to equipment design. Washington, DC:
U.S. Government Printing Office.
Wainwright, W. A. (1991). Advanced technology and the pilot. In Human factors on advanced flight decks;
Proceedings of the Conference, London, UK, March 14, 1991. London: Royal Aeronautical Society.
Wickens, C. D. (1984). The multiple resources model of human performance: Implications for display design.
AGARD Conference Proceedings No. 371 (pp. (17-1) - (17-6)). Neuilly sur Seine, France: Advisory
Group for Aerospace Research & Development.
Wickens, C. D. (1991). Engineering psychology and human performance (2nd ed.). NY: Harper Collins College.
Wilson, W. W., & Fadden, D. M. (1991). Flight deck automation: Strategies for use now and in the future (SAE
Technical Paper 911197). Presented at the 1991 SAE Aerospace Atlantic Conference, Dayton, OH.
Woods, D. D. & Roth, E. M. (1988). Cognitive engineering: Human problem solving with tools. Human Factors,
30(4), 415-430.

35
APPENDIX A: TEST AND EVALUATION
Objectives
Poor designs are costly to correct once installed in an operational environment. While changes to poorly
designed crew interfaces can be expensive, changes to systems because of poor function allocation, levels of
automation, or other functional design decisions, can be even more expensive. Understanding crew-driven
requirements, and what constitutes good design practice in terms of crew-centered design principles and
guidelines, can help assure that preliminary designs are good. But many design solutions may generally adhere
to the design philosophy and yet have major differences in degree of operability. Trade-offs must be made in
complying with different principles and guidelines, and the principles and guidelines can be interpreted in
different ways and applied differently depending on the context. Hence, a second aspect of a crew-centered
design approach is making usability evaluations an integral part of design. Usability refers to how easy a design
or a system is to use (operation can be learned and remembered easily, the system can be used efficiently and
with minimum error, and users are satisfied with it). Pilot-in-the-loop evaluations assess usability and total
system performance, that is, whether the overall man-machine system accomplishes the performance objectives.
This section provides test and evaluation guidance and recommendations, with reference to a variety of practices,
measures, tools and methods, and scenarios that can be applied throughout the design process. Test and
evaluation is an important complement to a crew-centered flight deck design philosophy. Part 2 of the document
set will elaborate in more detail on much of the material described here.
Practices
There are several important test and evaluation (T&E) practices to be followed to achieve successful and
cost-effective design. Each will be briefly described below.
(1) The most important T&E practice is to evaluate early. As soon as preliminary design concepts are
defined in accordance with the set of function, design and integration, and systems requirements, a variety of
usability testing methods can be applied. The earlier concepts are tested, both separately and as a whole, the
easier and more cost-effective it is to make changes. Early testing also can help refine and improve requirements
and determine if the trade-offs made among guidelines were appropriate. Testing flight deck design concepts as a
whole earlier in design is particularly important since it allows identification of "locally optimized" designs that
may not be optimal from the overall flight crew/flight deck perspective.
(2) The design process depicted in Figure 1 shows that test and evaluation, as with any design activity, is
necessarily iterative and serves as a feedback loop (design-evaluation-redesign). As each modification is made to
the initial concept, new evaluations must be performed to determine if: (a) the design change had the desired
positive effect and, (b) no new negative effects or interactions with other systems, procedures, or tasks were
inadvertently introduced. Formal and informal evaluations should both be conducted, with the goal of providing
diagnostic information for redesign. All evaluation methods can be used throughout the design process, although
some may be more appropriate to different stages of the design cycle.
(3) Crew-centered design focuses on pilots and their interaction with the flight deck, rather than on the
flight deck technology itself. Usability testing for flight deck systems should be done with users, that is, test
subjects drawn from the population of airline pilots who would fly the aircraft in the operational environment.
Experienced research test pilots and aircraft manufacturer “chief pilots” should not be used in this step, although
their input and advice, as well as that of the ultimate users, are valuable earlier in the design process. As each

36
modification is made to the initial concept, new evaluations with new test subjects should be performed. Human
Factors experts may be used for evaluation of certain aspects of the design, as appropriate.
(4) Test and evaluation from a usability and performance perspective should focus on measures that are
related to mission objectives. As described in Figure 3, pilot performance and overall flight crew/flight deck
performance, as measured by accuracy, response time, workload, situation awareness, subjective assessment, and
training efficacy, are assumed to relate to overall mission safety and efficiency. Different measures are
appropriate depending on the evaluation platform and stage of design.
(5) Evaluations should be conducted on representations of the system at several levels of fidelity. For
example, concept evaluations may be conducted with prototypes which can be developed as paper story boards
or in software using rapid prototyping tools. Other evaluations may be with interactive computer-based
prototypes or with a simulator exhibiting true vehicle flight characteristics. Different platforms (e.g., computer-
modeled prototypes, part-task simulators, flight test vehicles, etc.) allow different levels of fidelity in terms of
aircraft characteristics and operating environment.
(6) Evaluations should be conducted using a set of scenarios that span the range of normal and non-
normal situations that can occur and which test the limits of human performance and overall flight crew/flight
deck performance.
Measures
In evaluating operability and usability, as well as user acceptance of systems, a variety of measures can
be used. First, system design can be evaluated in analytical ways. Design concepts can be evaluated against the
guidelines and requirements: Do they meet the requirements and generally comply with good design practice as
embodied in design guidelines? If they do, and the requirements and guidelines are reasonable, then the design is
well on its way to being usable.
In the general sense in which we use "evaluation," typically there is some sort of actual use of the system
by an operator, so that his or her performance can be measured. The primary measure that is used in these types
of evaluations is performance accuracy (or conversely, errors). For evaluation of system interfaces and system
functionality, this can be accuracy in terms of tracking, decision making, manual input (e.g., button pushing),
problem solving, or any other aspect of performance of tasks and functions that the flight crew and the flight
crew/flight deck system must perform. Overall flight crew/flight deck performance can also be evaluated by
constructs such as workload and situation awareness, with the assumption that they are correlated with
performance. For overall performance, measurement of specific types of flight crew errors, such as those that
demonstrate confusability or interference among different systems, system functioning, or system interfaces, is
particularly useful.
Response times are also useful evaluation measures. When competing design concepts are good, it is
often difficult to demonstrate differences in error rates in most conditions (because so few errors are made), but it
is typically assumed that the faster humans can respond, the more accurate they will be when there is little time
or when other stresses are present. In human performance measurement, researchers refer to this phenomenon as
a speed-accuracy trade-off; under most circumstances, as one is forced to respond more rapidly, more errors are
made. If response times are faster in evaluations of one design over another while the accuracy levels are similar,
then it is assumed performance with that design will be better under time constraints.
Subjective measures are also used, particularly early in design before the systems are well defined.
Subjects can provide preferences and can judge the acceptability, general utility and ease of use of systems and

37
system interfaces. These types of measures may be collected in structured and formalized ways to reduce the
many sources of bias that can influence them. Training-related measures are also useful for evaluation purposes.
Measures such as training time and relearning or transfer of training time and accuracy are good ways to
evaluate the "intuitiveness" of system design.
Platforms
Platforms are the test environment and apparatus in which the evaluation is conducted. Concepts
modeled by computer or on paper are more naturally evaluated in those same environments, so the platforms are
computer workstations or paper. Paper evaluations can take many forms, including surveys, questionnaires, and
fairly formal evaluations of concepts that are described narratively and graphically on paper. In computer
evaluations, system functions and interfaces can be modeled, as can the environment, operational context, and the
user. Typically, computer-modeled prototypes are "operated" by a "real" user to collect performance data. The
fidelity of these platforms can vary greatly. With the sophisticated graphics and modeling capabilities available
today, rapidly developed interactive prototypes can be used early in design with a considerable degree of fidelity
and realism.
For many of the physical issues of design, such as reach, visibility, layout, display and control
configuration, etc., physical mock-ups are still very useful. The realism of mock-ups can vary from "drawings"
of displays and controls on a Styrofoam flight deck, to very realistic display, control, and panel surfaces on
actual flight deck hardware from a previous aircraft. One of the most important aspects of fidelity for mock-ups,
however, is spatial and dimensional realism; that is, the sizes and locations of displays and controls, etc., should
be accurate. This can be accomplished with any type of mock-up.
The highest fidelity evaluations are performed in simulators and flight test vehicles. Part-task and full
mission simulations are probably the most common methods for evaluating flight deck design concepts. Full
mission simulation, where the complete operational context and all the systems are simulated, is the most
important tool for evaluating the effect of design concepts on overall flight crew/flight deck performance. It is
not until full mission simulation that many subtleties of system and design concept interactions can be observed.
Conflicts, interference, and incompatibilities among design components, that were necessarily developed
independently, become apparent in full mission simulation. Since this is such an important platform and tool for
evaluating total flight crew/flight deck performance, the earlier system design concepts can be integrated in full
mission simulation, the better.
Flight test is the final method for evaluating design concepts. Because it is very expensive, however,
flight test should be reserved for issues that absolutely can’t be evaluated without the final aspects of realism and
fidelity that are provided by real flight. Of course, extensive flight tests associated with certification and final
development must be performed before the aircraft goes into line operation.
Methods & Tools
Current design practices already use many evaluation tools and methodologies. Chiefly, these include
computer aided anthropometric and biometric analyses to assess reach envelopes and other physical ergonomic
issues, function and task analyses to determine flight crew and flight deck automation requirements, and
workload analyses to evaluate the appropriateness of flight crew task loading. More extensive descriptions of a
number of the following methods can be found in Macleod (1992) and Whitefield, Wilson & Dowell (1991),
which are listed in Appendix C.

38
Methods vary with the platform used and stage of design. Methods can generally be divided into
analytical and observational methods. Analytic methods typically have either an underlying theoretical basis or a
complete or partial model of the user. Observational methods obtain data on actual operations of flight deck
systems including user performance. Some of the more common analytical and observational methods are briefly
described below.
Analytical Methods
Analytical methods are a class of evaluation methods providing a detailed examination of a system
design or of some aspect of the system’s design. The purpose is to provide detailed information which may then
be used in redesign to enhance system performance. Some analytical methods involve experts (as opposed to
users) to evaluate some aspect of the design; other analytical methods employ the ultimate users of the design to
perform the analysis. Some analytic methods have (1) an underlying theoretical basis with empirically-collected
data, and/or (2) a model or some other representation of a) the user or some aspect of user behavior and/or b)
the system being designed. These methods are often conducted with a computer-based tool by a human factors
specialist and typically provide predictions concerning specific human factors aspects of a design or user
performance.
Anthropometry/Biomechanics Analysis. Anthropometry/Biomechanics analysis examines the physical layout of
the environment and the "fit" of the users within that physical environment. There is typically an underlying
model of users (e.g., 5th percentile female to 95th percentile male) from a defined population (e.g., the U.S. Air
Force). The analysis focuses on such issues as the reach and viewing envelopes of individual crewmembers, the
physical layout and appropriateness of lighting, and crew physical movements required to perform specific tasks.
Attentional Conflict Analysis. Attentional conflict analysis is used to determine whether the systems or
configuration of the flight deck impose potentially serious attentional conflicts for the crew. Humans are, for the
most part, serial processors; they are only able to attend to, process, and perform one activity at a time.
Although certain tasks or combinations of tasks may require a pilot to manipulate multiple separate controls with
a single hand or divide attention between multiple displays, the flight deck design should prevent common
combinations of tasks from overtaxing the pilot’s attentional (e.g., visual, auditory, and cognitive) resources.
One method of analyzing the flight deck for attentional conflicts is to apply the Multiple Resource Theory of
human attention (Wickens, 1984), which rank orders different types of conflicts. For example, the theory, and
the model derived from it based on extensive dual task studies, indicate that visual/visual conflicts are more
difficult to manage than visual/auditory conflicts. Computer-based tools based on multiple resource theory, such
as W/INDEX (North & Riley, 1988; Riley, Lyall, Cooper, & Wiener, 1993), can be used to estimate the effects
of specific task sequences and procedures based on these conflicts.
Cognitive Task Analysis/Cognitive Engineering. Cognitive engineering applies theories of cognitive science to
design; that is, one attempts to systematically apply what is known from empirical studies of human cognition
and performance to the design of complex, computer-based human/machine systems (Rasmussen, 1986; Norman,
1986; Woods & Roth, 1988). Cognitive task analysis goes beyond a typical task analysis (i.e., one that analyzes
tasks and subtasks in terms of their occurrence in a sequence, duration, supporting information, etc.) and
includes consideration of underlying psychological factors (e.g., memory, decision making, complexity).
Cognitive Walkthrough. A cognitive walkthrough is a recently-developed, formally structured, analytical method
for evaluating user/system interfaces very early in the design process. The developers (Lewis, Polson, Wharton,
and Rieman, 1990; Polson, Lewis, Rieman, and Wharton, 1992) based this analytical method on CE+, a
cognitive theory of learning (Polson & Lewis, 1990). The method involves analyzing a user's task to a detailed
level, then answering a series of questions about the task which, in effect, evaluate the learnability of the

39
proposed system (e.g., what are the user’s current goals?; is the system’s response adequate?; can the user detect
when the task is completed?). The results of the analysis indicate problem area within the interface which should
be considered for redesign. One particular advantage of this method is that it may be conducted prior to having a
working prototype of the system. Rieman, et al., (1991) recently developed an automated tool to perform
cognitive walkthroughs.
Expert Walkthrough. Expert walkthroughs involve usability evaluations or judgments of systems by human
experts. These experts are typically drawn from a number of fields (e.g., pilots, human factors specialists). The
experts independently step through typical user’s tasks and critically evaluate the proposed design. This
"walkthrough" is often accomplished with a prototype of the system in design and with structured evaluation
instruments (e.g., a checklist of evaluation items).
Heuristic Evaluation by Designers. With heuristic evaluation by designers, members of the design team
independently (and, often, informally) assess the usability of a system and pool the evaluation results across the
team. These pooled results are then used to guide the redesign.
Keystroke-Level Model Analysis. Keystroke-level model analysis is an analytic method derived from the work of
Card, Moran, and Newell (1983) and is one of a class of GOMS (goals-operators-methods-selection rules)
analytical methods. A user model including a number of user performance and system response parameters and
associated times (e.g., keystroking, pointing), derived from empirical studies, underlies these analyses. The
method provides predictions about times required to complete a task, assuming error-free user performance.
Using this method, one may compare the actual keystrokes of users who have completed a task to a model of
predicted task completion times; the method may also provide a benchmark of predicted task completion times
against which to compare systems or design approaches.
Structured Interviews. Structured interviews allow members of a design team to step through a prototype of the
system and directly ask an user a series of questions about its use. A pre-determined series of questions is asked
and the user is led through the interview, which may be structured by use of an operations scenario. Often,
structured interviews are videotaped for later detailed review and analysis.
Survey Methods & Questionnaires. Surveys and questionnaires involve the structured collection and analysis of
users’ subjective opinions about a proposed design. They are usually conducted without the physical presence of
a system or prototype, so they are especially useful for evaluation of conceptual designs. Data are collected
when users are not actually interacting with the system. Users’ subjective opinions are probed with a series of
specific "closed" questions (i.e., the answers are constrained) concerning aspects of the system’s design and use.
In addition, open-ended questions (i.e., questions that allow a user’s free comments to a specific question rather
than choosing from a list of responses) are often used, especially in very early phases of design.
Function and Task Analysis. Function and task analyses have traditionally referred to the process of identifying,
decomposing, and allocating functions, and describing specific human tasks in terms of the sets of activities and
information that are required to accomplish them. These methods have been used primarily to develop task
timelines and to help determine crew interface requirements. In the revised crew-centered design process,
however, task analysis also incorporates an examination of how flight crew members perform their tasks in
existing aircraft to determine how they may need to do these same tasks in a new flight deck. The operational
environment is also examined to determine what functions must be provided, and flight crew activities in current
flight decks are examined to determine how the crew actually fulfills these functions. These analyses point out
two special kinds of problems: (1) the crew has to “trick” the flight deck automation to achieve the desired
result; or (2) the automation goes unused because the crew feels they have better control by completing the task
manually, or at a lower level of automation. Such areas indicate possible shortcomings in the functionality or
interface provided by the automation, and suggest how new systems can better meet the crew’s needs.

40
Trade Studies. Trade studies are analyses focused on answering specific questions within a design program by
systematically comparing alternatives with a set of cost and benefit criteria. They are usually paper-based and
involve collecting specific data that allow one to compare and choose among a set of alternatives (e.g., choosing
between specific implementation technologies) or a specific path of development.
Observational Methods
Observational methods involve viewing and analyzing user behavior with a system or prototype of a
system. Observational evaluations involve creating a situation similar to the operational environment and
observing users performing a set of representative tasks within this environment. These evaluations may be
formal and highly-structured (e.g., in the form of controlled experiments) or informal and less structured, and
may use individual or multiple users. The fidelity of the simulation of the operational environment varies and
may range from rapid prototypes to full flight simulators. Typically the user sessions are recorded (e.g., by
videotape or by keystrokes captured within a computer file) for later detailed analysis. In addition to videotaping
a user performing a task, direct user actions with the system may be automatically collected. All of a user’s
actions (e.g., keystrokes; mouse clicks; button pushes) may be accessed within the system itself, time-stamped,
and sent to a data file for later analysis. These data essentially allow an analyst to replay the user’s entire
interaction with a system after the task is completed.
Cooperative Evaluation. Cooperative evaluation actively involves users in the evaluation of the prototype system
design. Members of the design team observe users as they carry out tasks with the prototype system. Users may
be interviewed directly when they encounter difficulty, or to minimize interference, upon task completion. A
videotape of the user while performing the task may be used as a reminder during retrospective analysis. If
multiple users perform the task simultaneously, their conversations (especially when solving a problem with
system use) may also serve as useful data.
Direct Observation. In direct observation, the user carries out a representative task on a prototype of the system.
An expert (e.g., human factors specialist; pilot) directly observes the user and records problems that occur with
the user/system interaction. This information is then used in redesigning the system. Direct observation may be
used with other observation methods.
Experiments. Experiments allow deliberate manipulation of specific factors involving the user’s interaction with
a prototype system. Elements of the interface and the task may be manipulated, as well as operational and
environmental factors. Experiments allow the opportunity to collect user/system interaction data within a more-
controlled environment than that of other evaluation methods. User performance data (typically, a combination
of objective and subjective measures) are collected, analyzed, and related to the factors manipulated. Because of
the controlled nature of experiments, they are often used to test hypotheses concerning interface design. The
primary advantage of a controlled experiment is that it allows test of specific factors and their interactions; the
primary disadvantage is that a controlled experiment often doesn’t capture the complete set of factors that, in
combination, comprise the real-world operating environment. The results may, therefore, have limited generality
to the usability of the design in an uncontrolled operational context. Experiments are often complex and time-
consuming, although they need not be. This approach is typically useful in system design when evaluating user
performance with system components (e.g., window designs; symbol sets; fonts; control devices), rather than
when evaluating the system as a whole. Experiments may be carried out within a laboratory or simulator with
variable levels of fidelity.
Protocol Analysis. Protocol analysis evaluates user interaction with a system by analyzing the user’s utterances
during task performance (Ericsson & Simon, 1993). In this method, users are often asked to "think aloud" and

41
describe their activities while performing a representative task. This "think aloud" verbal protocol is recorded
and analyzed later for information concerning user difficulties with the system. There is some controversy with
this method. Users may be capable of describing their actions with great detail, but it is not clear that they have
access to the underlying psychological processes governing their performance.
Wizard of Oz Technique. The Wizard of Oz technique involves having a user perform a representative task with
a system while an expert acts as "the system" in the background. Two systems are linked: At one, the user
performs the tasks; at the other, a system expert hidden from the user’s view responds as the system would. The
system expert interacts with the user as though he or she were the actual system. The expert carries out all user
requests, responds to user queries, and controls screen output. In this way, the expert can actually respond
directly to the user during task performance (and, therefore, may follow interaction paths not available in the
prototype system). By evaluating the interaction, designers gain information concerning potential interface
problems which may be used in redesign.
Test Scenarios
Because it is impossible for designers to anticipate all the types of errors and failures that may occur
during actual operations, test scenarios are required which explore the limits of the performance envelope in
terms of overall flight crew/flight deck performance. By creating extreme conditions that lead to human errors
and allowing the consequences of such errors to develop, it is easier to identify some of the more subtle problems,
such as the loss of crew awareness of the current autopilot control mode, which may not be readily apparent until
a serious incident or accident occurs. Regal and Braune (1992) suggest that mission objectives must be
described in terms of normal and non-normal situations. For test of overall flight crew/flight deck performance,
human performance limits, and the ability of pilots to take over control from the automation under highly
demanding conditions, usability testing must include rare, but possible, non-normal scenarios. One difficulty in
using such scenarios is that their utility is greatly diminished once they have been experienced. The number of
times subjects fly each such scenario must be limited. If the aspect of performance being evaluated includes
decision making or problem solving that is influenced by experience, then only one exposure to the scenario per
subject is appropriate.
Scenarios for test and evaluation should be standardized so that multiple design teams, each working on
smaller pieces of the flight deck or system interfaces, can evaluate their work with the same set of conditions
even if the experiments are conducted in multiple, independent simulation facilities. This commonalty in the test
scenarios can aid in the later usability testing of the integrated flight deck concept.
One aid for developing such test scenarios is the Function Allocation Issues and Tradeoffs (FAIT)
methodology (Riley, 1992), which uses a general model of human-machine systems interaction to develop a
model of information flow for the flight deck. As human factors issues arise, the flight conditions that could lead
to the problems are also identified, which may aid in developing test scenarios. For example, a FAIT analysis
may suggest that an automatic mode reversion performed by the autopilot under certain conditions causes the
airplane to respond differently than the crew expects. If this mode reversion is required for operational reasons,
the designer must make sure that the mode annunciation cues are sufficient to draw the crew’s attention under
worst case conditions. Boeing Commercial Airplane Company is currently producing a set of standard scenarios
for the HSR program for testing pilot and flight crew/flight deck performance.

42
APPENDIX B: HSR ASSUMPTIONS
The following assumptions are drawn from the list currently maintained by the HSR Flight Deck Design
and Integration Element, and is a consensus collection of the assumptions generated by all the various elements
of the HSR Flight Deck program. The attention given in this document to the list of assumptions is warranted;
the assumptions provide the context for application of the philosophy statements, the guiding principles, and the
categories of design guidelines to requirements and system specification development for the HSCT. Without
this context, the translation of the principles into a specific set of requirements or a specific flight deck design
could become arguable. For example, the approximate year that the first aircraft may be manufactured helps to
establish the expected level of automation technology that should exist, which may influence the ability to adhere
to some principles.
New assumptions are constantly being added to the ones presented below. In addition, existing
assumptions are periodically scrutinized to ensure that progress in the research program has not invalidated them.
To receive the latest list of HSR assumptions, please contact Michael T. Palmer by telephone at +1 804 864-
2044 or via email (preferred method) at m.t.palmer@larc.nasa.gov.
A-1. The HSCT will nominally be operated by a two person crew, but either flight crew member alone
must be able to safely complete the flight.
A-2. The design of the aircraft will be completed in time for an approximate 2005 roll-out of the first
aircraft.
A-3. The HSCT will receive no preferential treatment with respect to traffic flow management in the
terminal area, with the following exceptions:
a. The HSCT may require special separation from other airplanes as it will climb out on departure
at significantly greater speeds than 250 KCAS below 10,000 ft.
b. The HSCT may require special separation from subsonic airplanes or other departure routing
from 10,000 ft. to 43,000 ft. due to steep climb angles and supersonic speeds during climb and
acceleration.
c. During subsonic cruise, the HSCT may require special separation due to slightly higher subsonic
cruise Mach numbers over subsonic airplanes.
A-4. The HSCT will not have a "drooped nose."
A-5. The HSCT will have "manual" flight controls (to the extent that the pilots can "hand-fly" the
airplane).
A-6. Improved capability technologies will be available in time to support the HSCT design. This is
explicitly assumed for computer hardware, especially with regard to memory size, cost, display
capability, and processing speed.
A-7. All aspects of the aircraft system, including hardware, software, procedures, and training, will be
designed concurrently, and the design process will allow each aspect to influence the other design
processes.
A-8. Minimum FAR Part 25 (certification) changes are expected from existing rules, except where
required for unique HSCT capabilities.

43
A-9. The projected 2005 environment for the 747-400 defines the baseline subsonic operational
environment for weather requirements, visibility requirements, airport characteristics, handling
characteristics, avionics capability, and CRAF/charter requirements.
A-10. The HSCT will carry reserve fuel, and will be subject to "ETOPS-like" considerations for over-
water flights.
A-11. The HSCT flight deck will incorporate an open architecture design, which means that the flight deck
will not be a single point design, but rather will be a framework for a family of flight decks with
differing functionality as dictated by individual airline customer requirements.
A-12. HSCT aircraft will have traditional subsystems, largely similar to current generation subsonic
transports, including: fuel, hydraulic, electrical power, avionics/computation, sensors (weather
and/or traffic radar), and communications (VHF voice and data link radio, ACARS or similar
follow-on data link).
A-13. Commercial and corporate aircraft will have Mode S transponders or equivalent, with discrete
addressing, altitude encoding, and data link capability. General aviation aircraft operating in Class
B and Class C airspace will be equipped with at least Mode C transponders; however, ATC-
authorized deviations from this requirement will still be available. In other airspace, general aviation
aircraft may not be carrying transponders.
A-14. All commercial and turbine-powered general aviation aircraft will be equipped with TCAS II, and
will likely be required to be equipped with a more advanced form of traffic/collision avoidance
system.
A-15. National Oceanic and Atmospheric Administration (NOAA) and Jeppesen IFR procedures and
reference data will be available in electronic form and will be legal for navigation in
national/international airspace systems.
A-16. Airline pilots will not be assigned to the HSCT for the duration of their careers; rather, pilots will
transfer into the HSCT with at least some experience flying subsonic jet transports, and will be able
to return to flying subsonic airplanes after flying the HSCT.

44
APPENDIX C: RESOURCES AVAILABLE
Bailey, R. W. (1982). Human performance engineering: A guide for System Designers. Englewood Cliffs, NJ:
Prentice-Hall.
Billings, C. (1992). Human centered automation: A concept and guidelines (NASA Technical Memorandum
103885). Moffett Field, CA: NASA-Ames Research Center.
Boff, K. R., Kaufman, L., & Thomas, J. P. (1986). Handbook of perception and human performance (Vols. 1 &
2). New York: John Wiley & Sons.
International Organization for Standardization. (1981). Ergonomic principles in the design of work systems (1st.
ed.) (ISO 6385:1981). Genève, Switzerland: International Organization for Standardization.
Department of Defense. (1989, March). Human engineering design criteria for military systems, equipment and
facilities (MIL-STD 1472D). Washington, DC: Department of Defense.
Department of Defense. (1987). Human engineering guidelines for management information systems (DOD-
HDBK-761A). Washington, DC: Department of Defense.
Department of Defense. (1986, April). Numerals and letters, aircraft instrument dial, standards form of (MIL-
STD-33558C) (Publication No. 1986-605-036/42638). Washington, DC: U.S. Government Printing
Office.
Gilmore, W. E., Gertman, D. I., & Blackman, H. S. (1989). User-computer interface in process control: A
human factors engineering handbook. San Diego, CA: Academic Press.
Harrison, M., & Thimbley, H. (1990). The role of formal methods in human-computer interaction. In M.
Harrison, & H. Thimbley (Eds.), Formal Methods in Human-Computer Interaction. New York:
Cambridge University.
Macleod, M. (1992). An introduction to usability testing. Teddington, UK: National Physical Laboratory.
National Aeronautics and Space Administration. (1993). Human-computer interface guide (rev. A) (NASA SSP
30540). Reston, VA: National Aeronautics and Space Administration.
National Aeronautics & Space Administration. (1987). Man-system integration standards (rev. ed.) (NASA-
STD-3000). Washington, DC: National Aeronautics & Space Administration.
Nielson, J. (1993). Usability Engineering. Cambridge, MA: Academic Press, Inc.
Price, H., Maisano, R., & Van Cott, H. (1982). The allocation of functions in man-machine systems: A
perspective and literature review (NUREG/CR-2623). Falls Church, VA: BioTechnolgy, Inc.
Price, H. (1985). The allocation of functions in systems. Human Factors, 27(1), 33-45.
Ravden, S. J., & Johnson, G. I. (1989). Evaluating usability of human-computer interfaces: A practical method.
New York: John Wiley & Sons.

45
Salvendy, G. (Ed.). (1987). Handbook of human factors. New York: John Wiley and Sons.
Sanders, M. S. & McCormick, E. J. (1987). Human factors in engineering and design (6th ed.). New York:
McGraw-Hill.
Schneiderman, B. (1987). Designing the user interface: Strategies for effective human-computer interaction.
Reading, MA: Addison-Wesley.
Smith, S. L., & Mosier, J. N. (1986). Guidelines for designing user interface software. Bedford, MA: The Mitre
Corporation.
Venturino, M. (Ed.). (1990). Selected readings in human factors. Santa Monica, CA: Human Factors and
Ergonomics Society.
Whitefield, A., Wilson, F. & Dowell, J. (1991). A framework for human factors evaluation. Behavior &
Information Technology, 10(1), 65-79.
Wiener, E. L., & Curry, R. E. (1980). Flight-deck automation: Promises and problems. Ergonomics, 23, 995-
1011.
Wiener, E. L., & Nagel, D. C. (Eds.). (1988). Human factors in aviation. San Diego, CA: Academic Press.