my blog

Most generally, task analysis is a way of systematically describing
human interaction with a system to understand how to match the
demands of the system to human capabilities. Task analysis is
a broad term that encompasses many other techniques such as
use cases, user stories, and user journeys. All of these techniques
focus on understanding the users’ goals and motivations, the tasks
and subtasks to achieve these goals, the ordering and timing of
these tasks, and the location and situation where tasks occur. Task
analysis consists of the following steps:

1. Define the purpose and identify the required data

2. Collect task data

3. Interpret task data

4. Innovate from task data

We describe this process as sequential, but in practice it is often
iterative. As an example a hierarchical task diagrammight be drawn
during an interview andmight be revised and adjusted as part of
the interview process. This diagram might be further refined based
on observations of work being performed. The observations and
analysis that make up a task analysis help focus on the activity
details that matter for the user. A deep, empathetic, and obsessive
understanding of these details is what makes designs succeed.

2.3.1 Step 1: Dene Purpose and Required Data

The first step of task analysis is to define the design considerations
that the task analysis will address. Because a task analysis can be
quite time consuming, it is critical to clearly define the purpose of
the analysis. Typical reasons for performing a task analysis include:

• Redesigning processes

• Identifying software and hardware design requirements

• Identifying content of the human-machine interface

• Defining procedures, manuals, and training

• Allocating functions across teammates and automation

• Estimating system reliability

• Evaluating staffing requirements and estimating workload

As an example, a task analysis for entering a car, adjusting settings,
and starting the engine could provide important information
to re-imagine the car key and create a new system for entering and
selecting vehicle settings. The task analysis could also be used to
define features of the interface to adjust settings, and could even
be used to define the content of the owner’s manual.

Both the purpose of the analysis and the type of task will influence
the information gathered. Tasks can be physical tasks, such as
opening the car door, or they can be cognitive tasks, such as selectingmusic
to listen to while driving after entering the car. Because
an increasing number of jobs have a large proportion of cognitive
tasks, the traditional task analysis is being increasingly augmented
to describe the cognitive processes, skills, strategies, and use of
information required for task performance. There are methods
specifically developed for cognitive task analysis [40, 41], but we
will treat these as extensions of standard task analyses, referring
to all as task analysis. However, designers should pay particular
attention to the cognitive components in conducting the analysis
if any of the following characteristics are present:

• Complex decision making, problem solving, diagnosis, or
reasoning

• Conceptual knowledge is needed to performtasks

• Large and complex rule structures that are highly dependent
on the situation

• Performance depends on memory of information that needs
to be retained for seconds or minutes

Whether the task analysis is focused on the physical or cognitive
aspects of the activity, four categories of information are typically
collected:

• Hierarchical relationships: What, why, and how tasks are
performed

• Information flow: Who performs the task, with what indications,
and with what feedback

• Sequence and timing: When, in what order, and how long it
takes to performtasks

• Location and environmental context: Where and under what
physical and social conditions tasks are performed

Hierarchical relationships

describe how subtasks combine
into tasks, and how tasks combine to achieve people’s goals. With
the car example, a goal is to keep the car secure, a task is to lock
the door, and subtasks include inserting the key, turning the key, or
press the lock icon on a keyfob. Moving up the hierarchy describes
why a task is performed—secure the car—and moving down the
hierarchy describes how a task is performed—turn the key/click
lock on keyfob. Describing the hierarchical relationships between
goals, tasks, and subtasks makes the reason for the many subtasks understandable. These hierarchical relationships help us focus
on the underlying goals of people and can prompt innovations by
identifying new and more efficient ways of achieving people’s goals,
such as securing the car using a keyfob rather than a key.

Y Hierarchical relationships
identify new ways of doing
things.

Information flow

specifies the communication between people
and the interactions between people and technology. This
information flow can also include stored information needed to
complete the task, such as knowledge and skills or information
on a display. With the car example, the flow of information might
include a signal to identify that the doors are unlocked. For some
systems, a complex network of people and automation must be
coordinated. In other systems, it may be only a single person and
the technology. However,most systems involve coordination with
multiple people. Defining their roles and their information needs
often identifies important design considerations that might otherwise
go unnoticed, such as how to get passenger preferred music
into the car.

Y Information flow helps specify
interface content.

Sequence and timing

describe the order and duration of tasks.
In the car example, the driver must first turn the key, then lift the
door handle, and finally pull the door open. Performed in a different
order, these tasks would not achieve the goal of opening the
door. In other situations, tasks could be performed in parallel. Task
sequence often determines howmuch time a set of tasks will take
to complete. Specific task sequence information includes the goal
or intent of task, sequential relationship (what tasks must precede
or follow), trigger or event that starts a task sequence, results or
outcome of performing the tasks, duration of task, number and
type of people required, and the tasks that will be performed concurrently.
Eliminating tasks, reducing their duration, or assigning
them to different people can make systems easier to use and more
efficient.

Sequence and timing specifies
efficient interactions.

Location and environmental context

describe the physical
and social world in which tasks occur. In the car example, important
location information might be the physical layout of the
vehicle interior that can make it difficult to insert the key to start
the car. Specific location information might include places people
work and the paths people take from one place to another, as
well as the location of equipment and the physical barriers such as
walls and desks. Location of equipment can greatly influence the
effectiveness of people in production-line settings. The physical
space can also have a surprisingly large effect on computer-based
work, as anyone who has had to walk down the hall to a printer
knows.

Physical layout can strongly
affect task difficulty.

The purpose of front-end analysis is to understand the users, their
needs, and the demands of the work situation. There are many
front-end analyses and they differ substantially in the time they
require. Hence, the analysis method needs to be matched to the
development timelines and priorities of a project. Not all activities
are carried out in detail for every project, but in general, the
designer will need to answer the following questions before design
solutions are created:

1. Who are the users? This includes not only users in the traditional
sense, but also the people who will install, maintain,
monitor, repair, and dispose of the system.

2. Why do users need the product and what are their preferences?

3. What are the environmental conditions under which the
system or product will be used?

4. What is the physical and organizational context of the users’
activity?

5. What major functionsmust be fulfilled by a person, team, or
machine?

6. Whenmust tasks occur, in what order, and how long do they
take?

Y “If you want to improve a
piece of software all you have
to do is watch people using it
and see when they grimace,
and then you can fix that.”
D. Kelley [38]

These questions are answered with various analyses that begin
by collecting data, often by observing and talking with people.
These data are then analyzed to support design decisions. We use
the term task analysis to describe this process, which can vary
substantially in its level of detail. In general, the more complex and
critical the system, such as air traffic control, the more detailed the
task analysis. It is not unusual to spend several months performing
this analysis for a complex product or system.

Although direct observation is the primary technique for collecting
information about tasks and activities, it is not always the
most effective. Accident prevention is a major goal of the human
factors profession, especially as humans are increasingly called
upon to operate large and complex systems. Although human
factors experts rarely observe accidents directly these critical incidents
can be analyzed to determine the underlying causes. In
Chapter 1 we discussed how Fitts and Jones interviewed pilots after
crashes and near crashes to identify opportunities to improve aircraft
design. Accident analysis has pointed to several cases where
poor system design has resulted in human error. As an example, in
1987 Air Florida Flight 90 crashed into the 14th Street Bridge on the
Potomac River shortly after taking off fromWashington National
Airport, killing 74 of the 79 passengers and crew. Careful analysis of
the events leading up to the crash identified training and decision
errors that led the pilots to take off even though snow and ice had accumulated on the wings. Accidents usually result from several
coinciding breakdowns, and so identifying human error is the first
and not the last step in understanding accidents.

The “Five Whys” help identify
the multiple causes of
accidents.

Practicing the “Five Whys” by tracing back the causes of an
event by asking “why” at least five times can be useful in going beyond
human error as the cause of an accident. For the Air Florida
Flight 90, this might mean asking why the aircraft had inadequate
lift? (ice accumulated on the wings). This leads to the question:
why did the aircraft take off with ice on its wings? (aircraft accumulated
ice as it waited in taxi line for 49 minutes before takeoff),
which then leads to the questions: why did the pilots decided not to
return for de-icing? (production pressure and lack of experience),
why did the pilots did not notice the severity of the icing problem as
they began taxied for takeoff? (captain failed to address concerns
of first officer). These series of questions typically show multiple
unsafe elements associated with training, procedures, controls and
displays, that should be considered before rather than after an accident.
This requires a proactive approach to system safety analysis
rather than a reactive one such as accident analysis or accident
reconstruction. This safety analysis is one particular example of
understanding users, their operating environment, and the tasks
they must performand is addressed in greater detail in Chapter 16,
where we discuss system safety.

In contrast to accident analysis, which typically focuses on systemsafety,
time-motion studies developed by Taylor (Chapter 1), focuses
on improving performance of manual work. Taylor’s detailed
observations dramatically improved steelworker productivity by
precisely recording the movements and timing of actions of workers
on assembly lines. These time-motion studies continue to be an
important technique to improve efficiency and avoid injury associated
with manualmaterials handling, which we discuss in more
detail in Chapter 13 (biomechanics). Human factors engineers can
incorporate knowledge gained in time-motion studies to understand
user needs, the context that the work is to be conducted, and
the sequences of tasks.

Time-motion studies identify
ways to improve worker
efficiency

Understanding users’ needs for computer systems and consumer
products often benefits from an approach termed contextual
inquiry [39]. Contextual inquiry provides an understanding
of users’ needs by going to users’ workplace or wherever the systemwould
be used, and adoptingmaster-apprentice relationship.
The interviewer acts as an apprentice learning from the master
regarding how to perform a particular activity. As an apprentice,
the interviewer asks the master to verify his or her understanding
by commenting on task descriptions and prototypes, as simple as
a series of sketches to show screens of a potential application.

Y Contextual inquiry reveals
user needs through careful
observation.

Understanding tasks is essential, whether the goal is to prevent
accidents, make assembly lines more efficient, or create delightful
products. This understanding goes beyond simply documenting
activity, but involves establishing a deep empathy for the user.
Without some formof front-end analysis, designers and engineers often find it hard to create systems that serve peoples’ needs effectively.
Depending on how the data are collected and analyzed,
the methods take on many names, but they all aimto understand
users, their environment, and the tasks they must perform. Here
we describe them under the general termof task analysis.

The overriding principle in human factors engineering is to center
the design process around people, thus making it a humancentered
design process [32]. In other words “honor thy user.” The
human-centered design of a system or product revolves around
the users. It mustmeet their needs and be compatible with their
abilities [33].

We put this principle into practice involving users in all stages
of the design process. That is, the human factors specialist will
study the users’ job or tasks, elicit their needs and preferences,
ask for their insights and design ideas, and collect data on their
response to design solutions. User-centered design does not mean
that the user designs the product. The goal of the human factors
specialist is to find a systemdesign that supports the user’s needs
rather than designing a system to which users must adapt.

A holistic perspective or systems thinking is an important part of user-centered design. Rather than considering elements of the
design as independent, unrelated parts, systems thinking focuses
on the interaction and relationships of parts—a focus on the whole
rather than just the parts. Such holistic thinking can identify important
benefits for integrating elements of a device, such as making it
possible to place a call from a smartphone by touching (rather than
dialing) a number on a webpage. Systems thinking can also avoid
unintended consequences. For example, shortening the shifts of
healthcare workers to reduce fatigue and improve healthcare quality
can have the unintended consequence of increasing the need
to handoff a patient from one healthcare worker to another. More
handoffs can undermine healthcare quality [34].

major phases: understand users, create a prototype, and evaluate
the prototype [35]. Understanding users involves careful observations
of people and the tasks they perform to the point of
establishing empathy for their situation. Creating a prototype involves
designers combining this understanding with a knowledge
of human characteristics, interface guidelines, and principles of
human behavior, which we will discuss in later chapters, to produce
initial design concepts. Soon after these initial concepts are
developed, designers evaluate these prototypes. Evaluating can
include heuristic evaluations and usability tests with low-fidelity
mock-ups or prototypes. Usability tests are particularly useful because
they often help designers better understand the users and
their needs. This enhanced understanding provides input to the
next cycle of creating an improved prototype.

Figure 2.2

The Understand, Create, and Evaluate cycle describes design
as an iterative cycle that repeatsmany times at multiple time scales.

Figure 2.2 shows the cycles of the design process, gravitating
from inside to out, as the prototype evolves into a final product.
The cycles vary in how long they take to complete, with the outer
cycles taking months or years and inner cycles taking minutes. In
the extreme, onemight complete a cycle during an interview with
a user where the designer creates a simple paper prototype of a possible solution, and the user provides immediate feedback. Taking
hours rather than seconds, a heuristic evaluation, where the
design principles and guidelines are applied to the prototype, can
quickly assess how design might violate human capabilities. Usability
tests typically take days or weeks to collect data from how
end users respond to the system, and so provide amore detailed
and precise understanding of how people will react to a design.
The inner elements of the design cycle provide rapid, but approximate
information about how a particular design might succeed
in meeting people’s needs, and the outer elements of the cycle
are more time consuming, butmore precise. This speed-accuracy
tradeoff means that the time and resources needed to understand,
create, and evaluate should be matched to the system being developed.
Rapidly changingmarkets place a premiumon fast and
approximate methods.

Y Human factors experts conduct
heuristic evaluations
and involve no end users; usability
tests collect data from
end users.

Usability tests are conducted multiple times as the interface
design goes through modifications. Each repetition of the testing
and modification cycle can produce significant improvements, and
many iterations of design should be expected. At the beginning,
it is not necessary to worry about the details of screen design or
making the screens look elegant. Rather, the emphasis should
be on identifying useful functions, and how the user responds
to those functions. This iterative process has been shown to be
incredibly valuable in refining software, hardware, and even work
process designs. Although each usability test typically includes
only five people (see Chapter 3 for more detail), as many as 60
cycles of testing can provide benefits that outweigh the costs [36].
At a minimum, three to five iterations should be considered and
one can expect improvements of 25–40% for each iteration [37].

Y Iterative design is central to
understanding and meeting
people’s needs.

When the system design nears completion, it may be placed in
an operational environment for comprehensive testing and evaluation
(see Chapter 3). This evaluation can be considered the final
step of product development. It can also be considered as the first
step in developing a better understanding of the user for the next
version of the product. The outermost cycle in Figure 2.2 indicates
that even after the product is released, the cycle continues with
data being collected to understand how people use the system.
For many consumer products, early beta versions of products are
released for this purpose, but this is not the case for high-risk systems.
For high-risk systems post-release surveillance to detect
design flaws is important. In the automotive industry, post-release
surveillance occasionally results in recalls to fix design flaws that
were not detected during the design process. The remainder of this
chapter describes critical elements of each of these three phases—
Understand, Create, and Evaluate—with a focus on understanding
the user.

Many products and systems are designed without adequate consideration
of human factors. Designers tend to focus on the technology
without fully considering its use from the human point of
view. In a book every engineer should read, Norman [23] writes:
Why do we put up with the frustrations of everyday
objects, with objects thatwe can’t figure out howto use,
with those neat plastic-wrapped packages that seem
impossible to open, with doors that trap people, with
washing machines and dryers that have become too
confusing to use, with audio-stereo-television-videocassette-
recorders that claim in their advertisements
to do everything, but that make it almost impossible
to do anything?

Even when designers attempt to consider human factors, they
often complete the product design first and only then hand off the
blueprint or prototype to a human factors expert to evaluate. This
expert is then placed in the unenviable position of having to come
back with criticisms of a design that took several months to develop.
It is not hard to understand why the design team would be less than
thrilled to receive the results of a human factors analysis. Designers
clearly believe in the design, and so are often reluctant to accept human
factors recommendations. Bringing human factors analysis at
the end of the design process places everyone involved at odds with
one another. Because of the initial investment and the designer’s
resistance to change, the result is often a product that is not particularly
successful in supporting human safety, performance, and
satisfaction. Effectively integrating human factors considerations
depends on understanding the system design process.

Y Considering human factors
at the start of the design
smooths the design process.

2.1.1 System Design Processes
Systematic design processes specify a sequence of steps for product
analysis, design, and production. Even though there are many
different design processes, they generally include stages that reflect
understanding the users needs (pre-design or front-end analysis activities),
creating a product or system (prototypes, pre-production
models), evaluating how well the design meets user’s needs; all of
which is an iterative process that cycles back to understanding the
user’s needs. Product lifecycle models, are design processes that include
product implementation, utilization andmaintenance, and
dismantling or disposal. Design processes differ to the degree that
they are defined by sequential steps or by iteration, flexibility, and
adaption to uncertainty.

Vee process

Figure 2.1 shows three common design processes,
the first is the Vee process, which is often used in the design of
large, high-risk systems, such as the design of a new aircraft, where
sequential development is possible and verification, validation,
and documentation are critical. The Vee shape starts with a broad
system description and design requirements, which are decomposed
into detailed requirements. For the dashboard of a car, these
detailed requirementsmight include information elements, such
as speed and level of the gas tank. Design of these components
are then integrated and verified by comparing them to the original
system requirements. In the Vee process, the general specifications
are well-defined at the start and emphasis is given to documenting
a successful implementation of those specifications.

Plan-Do-Check-Act cycle.

A second design model is the Plan-
Do-Check-Act cycle (PDCA), which is commonly used to enhance
workplace efficiency and production quality [30]. The cycle begins
with the target improvement. The Plan stage describes objectives
and specifies the targeted improvement. The Plan is then implemented
in the Do stage where a product, prototype or process
is created. The Check stage involves assessing the intervention
defined by the Do stage to understand what effect it had. Act completes
the cycle by implementing the intervention or developing a
new Plan based on the outcomes. This cycle reflects the scientific
management approach of Taylor in that each plan represents a
hypothesis of how the system or product might be improved.

Scrum process

A third design model is the Scrum approach,
which is more typical of consumer software products, such as
smartphone and web applications, where an iterative and incremental
approach is needed to resolve uncertainty in design requirements.
The Scrum approach focuses on creating products
and using those products to discover requirements [31]. Early prototypes
reveal design opportunities that are visible only after the
technology has been implemented. Central to the Scrumapproach
is delivering systemcomponents quickly and accommodating requirements
discovered during development. “Sprints,” which are
short duration efforts, typically 24 hours to 30 days, focus effort

Figure 2.1

Three system design processes that correspond roughly to
design of high-risk systems, the work-place, and consumer products.

on quickly producing new iterations of the product. The Scrum
approach is well-suited to situations that demand high degree
of innovation, such as those where technology changes rapidly
and potential applications emerge abruptly. This flexibility is why

such techniques are sometimes termed agile design The Scrum
approach relies on close interaction between co-located workers
to develop solutions in an ad-hoc manner and therefore, the approach
tends to place less emphasis on standardized work processes,
documentation, and testing.

As noted in the introduction, cars are increasingly becoming
highly computerized consumer products. Consequently, one might
think a Scrumapproachmight be appropriate for designing a car
given the rapidly changing technology and the associated need
for innovation to stay ahead of competitors. Rapid technology
change makes it difficult to specify detailed requirements in advance.
Cars also have elements of high-risk systems that intensify
the demands to verify and validate critical safety features,making
the “Vee” model more appropriate. Such design situations demonstrate
the need for a hybrid approach that combines elements of
the Vee, Plan-Do-Check-Act, and Scrum.

Vee process focuses on methodical
implementation,
PDCA guides incremental
improvement, and Scrum
focuses on fast iteration.

Integrating Human Factors into design processes.

Effectively
integrating human factors considerations depends on matching
the methods to the demands and opportunities of the particular
design process. For example, with a short development timeline
there may be no opportunities for time consuming human factors
methods. Some of themethods described in this chapter, such as a
comprehensive task analysis, provide an accurate description, but
require weeks to months to complete. Such comprehensive methods
best fit the Vee model. Other methods that provide a less accurate
description, such as an informal observations or an Internetbased
survey, might be completed in days. These rapidmethods
best fit the Scrum model. Human factors methods trade accuracy
for speed. Understanding how to make this speed-accuracy tradeoff
is critical for inserting human factors considerations into design.

Y Select human factors methods
that fit the demands of
the design process.

At the end of this chapter you will be able to...

1. identify appropriate design process for high-risk systems, the work place, and consumer products

2. apply human-centered design using the understand, create, and evaluate iterative cycle

3. identify the role of human factors in system design processes

4. identify design opportunities using focus groups, observations, and accident investigation

5. define design requirements using task analysis 6. create prototypes using iterative design and refinement

Thomas Edison was a great inventor but a poor businessman. Consider the phonograph. Edison invented it, he had better technology than his competitors, but he built a technology-centered device that failed to consider his customers’ needs, and his phonograph business failed. One of Edison’s failings was to neglect the practical advantages of the disc over the cylinder in terms of ease of use, storage, and shipping. Edison scoffed at the scratchy sound of the disc compared to the superior sound of his cylinders. Edison thought phonographs could lead to a paperless office in which dictated letters could be recorded and the cylinders mailed without the need for transcription. The real use of the phonograph, discovered by a variety of other manufacturers, was for prerecorded music. Once again, he failed to understand the real desires of his customers. Edison decided that big-name, expensive artists did not sound that different from the lesser-known professionals. He is probably correct. Edison thought he could save considerable money at no sacrifice to quality by recording those lesser-known artists. He was right; he saved a lot of money. The problem was, the public wanted to hear the well-known artists, not the unknown ones. Edison bet on a technology-centered analysis and lost. The moral of this story is to know your customer. Being first, being best, and even being right do not matter; what matters is understanding what your customers want and need. Many technology-oriented companies are in a similar muddle. They develop technology-driven products without understanding their customers (Adapted from Norman [23]). The goal of a human factors specialist is to make systems successful by enhancing safety, performance, and satisfaction. This is achieved by applying human factors principles, methods, and data to the design of products or systems. The concept of “design” is very broad and can include activities such as: • Creating new products, systems, and experiences • Improving existing products to address human factors problems • Ensuring safety in the workplace, car, and home • Implementing safety-related activities, such as hazard analyses, industrial safety programs, and safety-related training • Developing performance support materials, such as checklists and instruction manuals • Developing methods to train and assess groups and teams • Guiding team and organizational design In this chapter, we review some of the methods that human factors specialists use to support design, with particular emphasis on the early stages of design. Human factors methods and principles are applied in all product design phases: front-end analysis, prototyping, technical design, and final test and evaluation.

Although interface design may be the most visible design element, human factors specialists go beyond interface to design the tasks, interaction, overall experience, and even the organization of people and technology. Cooper [28] argues that focusing solely on interface design is ineffective and calls it “painting the corpse.” Making a pretty, 3-D graphical interface cannot save a system that does not consider the job or organization it supports. Reflecting this need to go beyond user interface (UI), is the increasing prominence of user experience (UX) design, which extends beyond the interface to include all aspects of users’ interaction with a system [29]. This chapter provides an overview of the process needed to address these broad considerations, and later chapters provide the basic content necessary to carry out those processes. Later chapters also provide specialized processes needed to address considerations beyond user experience design, such as organizational design.