C H A P T E R

6
Task analysis
Ashley French, Leah K. Taylor, Melissa R. Lemke
Agilis Consulting Group, LLC., Cave Creek, AZ, United States

O U T L I N E

1. Introduction 63 2.7 Example task analysis with risk

and task category delineation 74
2. Overall process 65
2.1 Step one: use case identification 65 3. Hierarchical task analysis 77
2.2 Step two: task identification 66
4. Task analysis as a design tool 79
2.3 Step three: sub-task breakdown 68
2.4 Step four: apply the perception, 5. Using task analysis for
cognition, and manual action instructional design 79
(PCA) model 71
6. Summary 80
2.5 Step five: potential use error
identification 73 Acknowledgments 81
2.6 Step six: potential harm identification 73
References 81

“Task analysis started by understanding the demands of tasks that need to be performed by an
operator, so that for each task the key human capabilities and limitations could be derived.” Bisantz
and Burns (2008)

1. Introduction
A task analysis is the process intended to identify a user’s goal, what steps must be done in
order to achieve the goal, what experiences (personal, social and cultural) users bring to the
tasks and how the environment might influence the user. It is an important design tool that
can be effectively used early in the design process (i.e., before the creation of device

Applied Human Factors in Medical Device Design

https://doi.org/10.1016/B978-0-12-816163-0.00006-2 63 Copyright © 2019 Elsevier Inc. All rights reserved.
64 6. Task analysis

prototypes) to help inform use-related design of the user interface (UI) components.
Throughout the design process, a task analysis can also be used as a fundamental framework
to the development of use-related risk documentation (e.g., uFMEA or Fault Tree Analysis),
human factors protocol development, and usability evaluation. It can highlight elements of
the user-device interactions that could be problematic for users, which provides designers op-
portunities early and throughout the product development process to implement risk mitiga-
tions proactively, ultimately saving time and manufacturing costs.
Additionally, a task analysis is a critical input for instructional designers while creating the
device’s instructional materials (e.g., Instructions for Use (IFU), quick reference guide (QRG),
user manual or training materials). The instructional materials accompanying a device aim to
guide accurate, safe and effective user performance. As the task analysis defines and de-
scribes what constitutes that performance, ultimately, good instructional materials cannot
be developed without a comprehensive task analysis.
As defined by HE75 3.94 (ANSI/AAMI HE75, 2009), a task analysis is, “a set of systematic
methods that produces detailed descriptions of the sequential and simultaneous manual and
intellectual activities of personnel who are operating, maintaining, or controlling devices or
systems.” The FDA recognizes that a task analysis is an important type of preliminary anal-
ysis that can provide insight into the following questions (CDRH guidance, 2016):
• What use errors might users encounter for each task?
• What circumstances might promote users to make use errors on each task?
• What harm might result from each use error?
• How might the occurrence of each use error be prevented or made less frequent?
• How might the severity of the potential harm associated with each use error be reduced?
A complete and accurate task analysis requires a systematic process to break down neces-
sary device operations into a hierarchical sequence of definable tasks that are intended to be
completed by the device user.
This chapter describes the process of conducting a task analysis, provides examples and
promotes its use as a fundamental requirement in the application of human factors in medical
device design. It is one of the most important tools in the Human Factors Toolkit and is rele-
vant to virtually all aspects of the design process including the following:
• Verification of function allocation is appropriate
• As input to the risk analysis process
• Analysis of errors, potential errors and critical incidents as part of post-market
surveillance
• Highlighting potential design problems and crafting solutions
• Developing formative and summative usability evaluations
• Designing instructions for use, quick start guides and training materials
The methods and techniques for conducting task analysis have been devised in almost
every field of endeavor involving human performance. Further, many techniques known
by other names (e.g., Fault Tree Analysis, Link Analysis, Failure Modes and Effects Analysis
(FMEA)) are often considered special types of task analysis by human factors professionals
with the main reference text being Kirwan and Aimsworth’s “A Guide to Task Analysis”
(1992).

II. Discovery & input methods

 2. Overall process 65

2. Overall process
Task analysis development is a systematic process that produces a coherent “road map” to
device-user interactions. A use case is the first input necessary for developing a task analysis.
Use cases are representative situations that describe how intended users will use the device in
actual use environments. These use cases provide input to and guide the development of the
task analysis by identifying specific tasks that users need to complete in order to successfully
use the device in those specific situations. The next steps for developing a task analysis
involve task identification, sub-task breakdown and application of the PCA model (i.e.,
Perceptual, cognitive, and manual action requirements model). The PCA model is recommen-
ded in CDRH guidance (2016) guidance however, this model can be limited for devices and
systems that have multiple simultaneous users where coordination and communication tasks
are involved (e.g., complex surgical systems or electrophysiology technologies).
Once the tasks and sub tasks have been accurately described, potential use errors are iden-
tified along with associated harms and severity. Fig. 6.1 illustrates the task analysis process
starting from identifying use cases (Step 1 in the process) and in some cases (uFMEA) ending
with determining potential harms and severity of harm (Step 6 in the process).
The terminology used in a task analysis may vary across device teams. The terminology
used in this chapter includes terms such as; “use cases,” tasks,” and “sub-tasks.” Although
terminology may change slightly or have somewhat different meanings across manufac-
turers, it is important for a manufacturer to use a systematic and consistent hierarchy
when creating and utilizing a task analysis and associated terminology. Table 6.1 helps illus-
trate the differences between use cases, tasks, and sub-tasks for an infusion pump.

2.1 Step one: use case identification

The first step in developing a task analysis is use case identification. Use cases are an
important input to the task analysis as they provide context for the various, sometimes over-
looked, uses of a device. Most medical devices involve numerous use cases. While some use
cases are related to the main purpose of the device such as drug delivery or running a diag-
nostic test, other commonly overlooked use cases for some devices that should be considered
in the task analysis if they are applicable include procedures such as maintenance, calibration,
reprocessing, cleaning, disposal, shut down, and storage.

FIG. 6.1 Process map of an example task analysis development process.

II. Discovery & input methods

66 6. Task analysis

TABLE 6.1 Example use case, task identification, and sub-task breakdown for an infusion pump.
Terminology definitions Examples

Use Case: High-level set of user-device interaction functions Use Cases:

• Device set-up
• Troubleshooting
• Programming Therapy
• Monitoring Status
• Maintenance
• Shut-down
Task: Individual task (s) for the high-level functions Tasks:
or
Action or set of actions performed by a user to achieve a • Enter patient data
• Enter dosage concentration
specific goal task (CDRH guidance, 2016)
• Enter start time
Sub-Task: Interaction steps (i.e. individual steps for carrying Sub-Tasks:
out a task in the order of their performance)
• Press power button
• Verify pump on
• Select dosage entry screen

Adapted from HE75, Section 5.6.3.

Different users of the device may encounter the same or different use cases. Consider the
previous example of an infusion pump. A health care professional may have a use case to
program the pump, and a lay patient may have a use case to initiate a pre-programmed bolus
of medication. When identifying use cases it is important to consider the different users
throughout the life cycle of a device. When user-device interactions differ across intended
user groups, the task analysis should include all tasks and specify the users who complete
specific tasks in the analysis.

2.2 Step two: task identification

Upon definition of the use cases, the tasks associated with each specific use case can be
established. Tasks may be determined from knowledge experts (e.g. clinical stakeholders)
input, FDA feedback on similar devices, observations of users with similar devices, human
factors experts interacting with the device, critical thinking, investigation into videos of de-
vice use or similar device use, instructional material, risk documentation, reverse engineering
and/or experience with similar devices. When identifying tasks, it is important to analyze the
user performance requirements, referencing that the device must support the user(s) toward
meeting their intended goal. This analysis may include a heuristic review or cognitive walk
through of the design for various use cases with the intended user in mind.
As a caveat, remember that relying solely on the IFU and risk documentation to develop a
task analysis will not produce a comprehensive task analysis. Instructional materials and risk
analyses are often created by engineers or the device developers and may not always account
for all aspects of user-device interactions. Instructions that do not include all of the necessary

II. Discovery & input methods

 2. Overall process 67
information may cause preventable use errors or difficulties for users who choose to use the
instructions. Additionally, a task analysis constructed solely from the instructions may inac-
curately identify use errors. For example, the instructions may direct a user to hold injection
for 15 seconds, but the medication may be administered after 7 seconds. The Task Analysis
needs to identify the 7 seconds, not the 15 seconds to avoid inaccurately identifying the inter-
action as premature removal. Another example is if the instructions state to hold the needle
perpendicular to the injection site, but in reality it is safe and effective use if the needle is at a
slight angle. The user can technically insert the needle between a 75e105 degree angle, which
is not evident from the instructions alone. Risk documentation that is incomplete may lead to
unanticipated problems and unacceptable risk during clinical trials and human factors
testing, as well as post-market issues that may not have been assessed or mitigated in the
design and development process. Sometimes the manufacturer develops the task analysis
and instructional materials at the same time. In these situations, the task analysis provides
an input for the instructional materials (see Chapter 9 Applying Design Principals to Instruc-
tional Materials and Training for more details).
A crucial strategy in the task analysis development process is observation of use of the de-
vice to understand in detail how tasks are performed, the order they are performed in, and if
the user is able to safely and effectively complete the task. A thorough and accurate
sequencing of tasks is crucial, if a specific order of tasks is necessary for a user to successfully
use a device. For example, consider an infusion pump that requires a user (i.e., a healthcare
professional) to setup the device prior to use by first positioning the tubing set in the tube
holder-clips that lock the tubing into place before closing the pump’s access door. If the
user closes the access door prior to ensuring that the tubing set is properly positioned in
the holder-clips, the tubing could become clamped and result in an under-infusion for the
patient.
Another strategy for task identification is for a stakeholder, who is not familiar with the
device, perform simulated use, cognitive walk through, and/or ethnographic observation
of the device. These can be done with and without using the instructional materials. If simu-
lated use is used, a mock user can note what they have trouble with, their first impressions of
the design, if the device works as anticipated and if he/she hears, feels or sees different cues
while working with the device. A cognitive walkthrough (See Chapter 10, Section 3 for full
details) can be a quick and inexpensive tool to understand the device’s usability from the
intended user’s perspective.
While creating the task analysis, the mock user can input the “obvious” use errors based
on these task identification techniques. It may also be helpful for the mock user to try to do
tasks incorrectly with the device to see what types of responses the device has, and what
additional potential use errors are induced. Similar observations can be made during an
ethnographic observation. These data should be incorporated into the task analysis. Below
are some questions that may be helpful to ask while creating a task analysis and may be
answered by observation or mock use:
• Is order of tasks important?
• The order of tasks may or may not be critical to the safe and effective use of a device.
If a task is completed out of order, it should be determined if the result would be a
use error or pose a potential harm.

II. Discovery & input methods

68 6. Task analysis

• If the order of tasks is important, sequencing should be documented in the task anal-
ysis. For example, most devices must be powered on before any other tasks can be
completed.
• What happens if someone skips a task? If the task is skipped, is the task optional?
• There may be a task that is inadvertently missed or intentionally skipped by a user.
Some tasks are critical to the safe and effective use of the device, while others are
included as steps in the logical workflow. Consideration for tasks that fall into these
categories should be documented in the task analysis. For example, an optional task
may be to pinch the skin around an injection site to administer therapy.
• Is timing a critical component?
• Some devices include timing as part of the safe and effective use of the device. The
timing may be related to warm up time of medication, length of holding an injection,
or wait time for a diagnostic result to appear. If timing is determined to be relevant
to the safe and effective use of the device, the time requirements should be integrated
into the task analysis in an observable and measurable way.
• Are there alternative ways/shortcuts to complete a task that are acceptable or
unacceptable?
• For some tasks, there may be multiple ways to accomplish the same end goal. An
ethnographic study may provide insight into these alternative paths or shortcuts. If
alternative methods are acceptable they should be reflected in the task analysis. If a
shortcut is unacceptable, it should be noted as a potential use error and mitigations
incorporated in an effort to eliminate the occurrence.

2.3 Step three: sub-task breakdown

During the sub-task breakdown stage, each task should be broken down into independent
actions or processes. Table 6.2 below illustrates an abbreviated task list for an infusion pump
with both tasks and sub-tasks identified. For example, the task of “Program Continuous Ther-
apy” consists of nine sub-tasks that delineate the specific sequence of actions that a user must
take with the UI to complete the task (i.e., “Navigate to Therapy Modes Menu,” etc.). Table 6.5
shows an example of a full task analysis excerpt for an infusion pump.
Most often it is important to avoid combining multiple tasks into a single line item of the
task analysis, as this introduces the possibility of misidentification or omission of associated
use requirements and potential use errors as well as “double counting” errors and losing
specificity in data reporting during usability testing. For example, in the infusion pump
example from Table 6.2, it may seem logical to combine Tasks #6 and #7 to be “Select
CONFIRM and Understand Confirmation Message.” However, each sub-task addresses
separate parts of the UI (i.e., on-screen option and popup confirmation message) and separate
required actions on the part of the user (i.e., select the on-screen option and understand mean-
ing of confirmation message content). Thus it is better to separate the two into sub-tasks.
When task analyses are used during the design process as the framework for human factors
testing, appropriately separated tasks and sub-tasks are also important because they guide
moderator observations and the debriefing interview so as to yield insights into root cause
analysis and reporting of any observed difficulties and use errors.

II. Discovery & input methods

 2. Overall process 69
TABLE 6.2 Abbreviated task list for an infusion pump.
# Device sub-tasks

Program a Continuous Therapy (i.e., constant programmed rate of infusion)

1 Navigate to Therapy Modes menu
2 Select “Continuous”
3 Enter prescribed drug concentration
4 Enter prescribed amount to be infused

5 Enter prescribed rate of infusion

6 Select CONFIRM
7 Understand Confirmation message
8 Select RUN to start continuous therapy
9 Wait for a minimum of 30 seconds before additional programming

Additionally, when breaking down tasks into sub-tasks, it is important to integrate order
and timing (when applicable) in an observable and quantifiable way. Verbiage should be
concise, consistent (with no ambiguity) and measurable (which becomes extremely important
when task analysis guides usability testing). For example, terms such as “after” and “before”
should be included when order is important. When timing is critical, measurable metrics
should be included. For example, instead of “hold until the medication has been delivered,”
provide a metric such as “hold for 5 s until the medication is no longer visible in the win-
dow.” While the above provides limited examples, the text “Taxonomies of Human Perfor-
mance” (1984) by Fleishman and Quaintance provides more comprehensive examples of
task descriptions.
The precision of wording included in task analysis can influence the quality of the analysis.
It is important to avoid using words that are ambiguous and will be difficult to observe or
measure (e.g., “adequate,” “well,” or “enough”). Instead define what is meant by ambiguous
words with as much detail as possible that describes the specific UI components and the ex-
pected user-device interactions. The more specific and stand-alone the sub-tasks can be, the
more useful a task analysis will be as an early design tool as well as a framework for subse-
quent human factors data collection and analysis. Table 6.3 provides examples of original
task phrasing and suggested improvements to task phrasing, which also includes the separa-
tion of tasks into more discrete sub-tasks. Note that the specificity and phrasing included in a
task analysis might lead to development of instructional materials that provide the user with
similarly concise instructions, although this is not always the case.
It is important to capture all tasks for a device, including tasks and sub-tasks that are asso-
ciated with observable performance data and those that are not observable (i.e., knowledge
tasks). For example, understanding instructions on proper storage and understanding an
expiration date may not be possible to observe during a simulated use scenario. However,
if the task is included in the task analysis and is identified as critical, it can be assessed

II. Discovery & input methods

TABLE 6.3 Example task identification improvement in specificity, phrasing, and separation into discrete
sub-tasks.
Original task phrasing Suggested improvements to phrasing and sub-tasks to reduce ambiguity

Hold the device horizontal with the Separate into sub-tasks:

button on top, press button to load
1. Hold device horizontally with the button on top.
dose, and do not turn upside down
when pressing the button. 2. Press the button all the way down to prepare dose.
3. Avoid tilting the device more than 90 while pressing the button.
Notes: Separated original task into discrete sub-tasks, added additional de-
tails about unacceptable device positioning.
Take a strong, deep breath and Separate into sub-tasks:
continue breathing until indicator
changes from green to gray 1. Take a strong, deep breath by inhaling for at least 3 seconds.
(after click). 2. Continue inhaling after a click is heard and indicator changes from
green to gray.

Notes: Separated original task into discrete sub-tasks, since some users
may have issues with the first sub-task that requires the user to perform
an action for a specific period of time (i.e., take a strong, deep breath for
3 seconds) and others may have issues with the second part which relies
on a specific design element to provide feedback to the user (i.e., continue
breathing until indicator changes from green to gray). In addition,
breaking into discrete sub-tasks will allow more detailed observations of
UI elements and user performance if usability testing is conducted.
Open the medicine. Define sub-tasks:
1. Tear off strip of foil along perforation (bottom of packaging).
2. Tear medication pack along perforation to separate one capsule
segment from the rest of the packaging.
3. Press capsule through foil to remove it from individual packaging.
Notes: Separated original task into discrete sub-tasks that focus on
different aspects of the packaging design that may impact user-device in-
teractions (e.g., perforations in the medication pack, individual package
segment containing the capsule).
Mix suspension well. Identify precise wording:
• Mix until no particles are visible in the suspension.
Notes: Updated wording to indicate how “well” is defined in the original
task wording.
Adequately press and hold green Identify precise wording:
button.
• Press and hold green button for 5 seconds until the light stops blinking
Notes: Updated wording to indicate how “adequately” is defined in
original task wording.
Decompress the guard deep enough. Identify precise wording:
• Decompress the guard so that yellow guard is no longer visible

Notes: Updated wording to indicate how “enough” is defined in the

original task wording.
Twist cap to close. Identify precise wording:

• Twist until a click is heard and the cap can tighten no more
Notes: Updated wording to indicate how “closed” is defined in the
original task wording.
 2. Overall process 71
TABLE 6.4 Task type examples in the PCA model.
Task types

Perceptual Cognitive Action (Physical/Motor)

Detecting Calculating Adjusting

Scanning Analyzing Aligning

Identifying Comparing Synchronizing

Locating Estimating Opening
Discriminating Planning Connecting
Categorizing Pressing
Deciding Bending

through a knowledge task question. Knowledge tasks are represented in the task analysis and
are often phrased as “Understand [critical information content]” (e.g., “Understand the de-
vice should be stored in the refrigerator” or “Understand the device should be stored in
the original carton”). If these critical non-observable knowledge tasks are omitted during
the task analysis process, gaps will exist with respect to use-related risk and the user
interface.

2.4 Step four: apply the perception, cognition, and manual action
(PCA) model
A complete task analysis is fundamental to user interface optimization, use error predic-
tion and prevention, and determination of the user’s interactions with the device relative
to task requirements. These user task requirements include user actions, user perception of
information and user cognitive processes (Sharit, 2006). A Perception, Cognition, and Manual
Action (PCA) model is an FDA recommended strategy for task analysis that is used to iden-
tify user-device interactions and characterize user capabilities. Applying PCA to a task anal-
ysis adds specific user requirements that lend support for identification of potential use errors
and root cause analysis during human factors testing. This model identifies user actions
related to the perceptual inputs, cognitive processing, and physical actions involved in the
task (CDRH guidance, 2016). Table 6.4 below highlights task types according to the PCA
model and is intended to provide examples though it is not an exhaustive list of types of
tasks.
In more complex systems, there may be a fourth category of tasks which is Communica-
tion (people to people). For example, this includes the following task descriptors: informing,
requesting, directing, advising, or querying.
Once sub-tasks are identified, the PCA model is used to further break down the sub-tasks
to identify user requirements to complete each sub-task. For each sub-task, user requirements

II. Discovery & input methods

72 6. Task analysis

FIG. 6.2 Model of the operational context between a user (PCA components), device, and user interface. Adapted
from FDA HF Guidance (CDRH, 2016).

related to perceptual inputs, cognitive processing, and manual actions necessary to perform
the sub-task should be documented.
Fig. 6.2 below describes the user-device interface relationship. Risk occurs when any of the
perception, cognition, or action tasks are difficult, confusing, or impossible for the user. For
example:
• If perceptual information, such as warning labels or directions, are not seen or heard by
the user (perceptual requirements), this information will not be available for the user to
understand (cognitive processing).
Consider a wearable cardiovascular device that includes an alarm to warn the user to
change the battery. If the user is unable to hear the alarm sound, he/she will not be alerted
to take the necessary action(s) to change the battery, which could have fatal consequences.
• If a user correctly perceives the information from the device or labeling, but has diffi-
culty understanding what that information means, the necessary action may be missed
or done incorrectly.
For example, if a user with a wearable cardiovascular device hears the alarm but does not
understand that it means to change the battery, the user may take no action or the wrong ac-
tion in response to the alarm.
• If the action step requires users to act quicker or more forcefully than they are physically
capable of doing, this interaction will not occur.

II. Discovery & input methods

 2. Overall process 73
For example, if the user with the wearable cardiovascular device hears and understands
the alarm to change the battery, the user may not be able to generate enough force to remove
the old battery.
Fig. 6.2 demonstrates that the safe and effective interactions of the user-device interface are
dependent on the user requirements outlined in the PCA process.

2.5 Step five: potential use error identification

The next step is to identify possible use errors and impacts of not meeting the use require-
ments. Use errors and difficulties observed during tasks can be traced back to the PCA re-
quirements for each task, which can assist in determining the root causes for issues and
the corresponding piece of the device user interface that may require redesign or additional
risk mitigation evaluation. Potential use errors may occur if the user is unable to understand
or carry out the user interface requirements. For example, refer to Table 6.2 Task 1, “Navigate
to Pump Modes.” If a user does not perceive, understand, or act on information, it could lead
to the use error of navigating to an incorrect menu option. If during testing a user navigates to
the wrong menu option, then the human factors moderators should probe the user to deter-
mine if the root cause is perceptual (i.e. user was unable to read the screen, or read the screen
incorrectly), cognitive (i.e. user thought the menu option labels meant something different
than intended), or manual action (i.e. user double-tapped the screen to select instead of a
single tap).
Another part of use error identification includes leveraging data from prior formative eval-
uations, literature (e.g., peer published articles, FDA news flashes, device recalls), customer
complaints, post-market data from similar devices and expert opinions of stakeholders
(including clinical experts) on the potential use errors and the consequences of those use er-
rors. If a user does not understand the tasks or is not able to complete the tasks, the device
may be used incorrectly or may not be used at all. This could lead to decreased treatment
efficacy or delay in therapy or treatment. Having input from multiple stakeholders with
regard to use errors and associated consequences is critical to understanding all of the risks
associated with the device use.

2.6 Step six: potential harm identification

Using task analysis as the foundation of risk analysis is a best practice. ANSI/AAMI HE75
defines harm as “(1) Physical injury or damage to the health of people, (2) damage to prop-
erty or the environment,” (ANSI/AAMI HE 75, 2009). A risk is defined as a, “Combination of
the probability of occurrence of the harm and the severity of the harm” (ANSI/AAMI 14971,
2010). The probability of occurrence is the frequency with which the harm would occur.
Severity is the measure of the possible consequences of a hazard. Although harm, probability
of occurrence, and severity should all be considered in determining the risk profile for a
particular device, probability of occurrence is not an FDA-accepted factor for determining
the criticality and corresponding categorization of tasks in human factors testing.

II. Discovery & input methods

74 6. Task analysis

TABLE 6.5 Example definitions of severity at the significant, moderate, and

negligible levels.
Example severity levels Example description

3dSignificant Death or loss of function or structure

2dModerate Reversible or minor injury

1dNegligible Will not cause injury or will injure slightly

The estimated probability of occurrence of a problem is not always accurate, and many use
errors are not anticipated until device use is simulated and user interaction with the device is
observed, or even later once the product is released and the manufacturer observes post-
market problems. Therefore, severity and potential harm are preferred measures for deter-
mining if user interface modifications are required to reduce or eliminate harm (ANSI/
AAMI 14971, 2010) and should therefore be included in a task analysis.
Severity levels are determined and justified by the manufacturer for a particular medical
device under clearly defined conditions of use (ANSI/AAMI 14971, 2010). An example range
of severity levels provided by ANSI/AAMI 14971 is described in Table 6.5.
Once severity levels are identified for all tasks or sub-tasks in the task analysis, tasks can be
assigned a task category. CDRH defines a critical task as, “A user task which, if performed
incorrectly or not performed at all, would or could cause serious harm to the patient or user,
where harm is defined to include compromised medical care.” (CDRH guidance, 2016).
Although the only category that is defined by CDRH is a critical task, it can be beneficial to
group tasks into a hierarchy to identify critical tasks and non-critical tasks. Task category
should be linked to severity rating, and a definition of how tasks are categorized should be
included in the task analysis. Note: CDER draft guidance defines a critical task differently
than CDRH, specifically “user tasks that, if performed incorrectly or not performed at all,
would or could cause harm to the patient or user, where harm is defined to include compro-
mised medical care.”
For the entire project team it is key to note that the task analysis is a living document.
Throughout the development, testing, and re-design process iterations are likely. These
iterations may include added, removed, modified, and/or re-ordered tasks. Additionally,
revisions may involve modifications to the PCA analysis, risk severity, use errors, and task
categorizations.

2.7 Example task analysis with risk and task category delineation
Table 6.6 below presents an example Task Analysis for an infusion pump including the
sub-tasks, PCA elements, potential use errors, potenetial harms, severity of harm and task
category.

II. Discovery & input methods

 TABLE 6.6 Task analysis example for an infusion pump.
Device use Potential harm Severity Task
# sub-tasks PCA elements Potential use errors (outcomes) of harma category

Program continuous therapy (constant programmed rate of infusion)

1 Navigate to therapy • P: See menu labels User does not navigate to Inaccurate infusion, 3 Critical
modes menu • C: Read and understand menu labels the correct menu delayed therapy,
• A: Select menu label or no therapy
II. Discovery & input methods

2 Select continuous • P: See menu labels User does not select correct Inaccurate infusion 3 Critical
• C: Read and understand menu labels option to program continuous
• A: Select menu label to program therapy

2. Overall process
continuous therapy

3 Enter prescribed drug • P: See editable field User does not enter the Inaccurate drug 3 Critical
concentration • P: See measurement units prescribed value correctly concentration
• P: See keypad
• C: Understand where to enter
concentration value
• C: Understand to select the correct
units of measurement
• A: Select editable field
• A: Use keypad to enter value

4 Enter prescribed • P: See editable field User does not enter the Inaccurate amount 3 Critical
amount to be • P: See measurement units prescribed value correctly to be infused value
infused • P: See keypad
• C: Understand where to enter
amount to be infused
• A: Select editable field
• A: Use keypad to enter value

(Continued)

75
 TABLE 6.6 Task analysis example for an infusion pump.dcont’d

76
Device use Potential harm Severity Task
# sub-tasks PCA elements Potential use errors (outcomes) of harma category

5 Enter prescribed • P: See editable field User does not enter the Inaccurate rate of 3 Critical
rate of infusion • P: See measurement units prescribed value correctly infusion
• P: See keypad
• C: Understand where to enter rate
• A: Select editable field
• A: Use keypad to enter value
6 Select CONFIRM • P: See option to CONFIRM User does not select the correct Delayed therapy or 3 Critical
• C: Read and understand option option to proceed with infusion no therapy delivered
labels
• A: Select option to CONFIRM
II. Discovery & input methods

7 Understand • P: See confirmation message User does not recognize or Inaccurate infusion 3 Critical
confirmation message • C: Understand confirmation message understand confirmation
message

6. Task analysis
8 Select RUN to start • P: See RUN button User does not select RUN Delayed therapy or 3 Critical
continuous therapy • C: Understand that RUN button to start delivering therapy no therapy delivered
delivery will start therapy
• A: Select RUN button
9 Wait for a minimum • P: See Program Pump confirmation User does not wait a minimum System error may 2 Essential
of 30 s before screen of 30 s before proceeding with appear
additional • C: Know to wait a minimum of 30 s any additional programming
programming • A: Wait 30 s before proceeding with
any other programming
a
Scale used for severity is as follow: 3dSignificant, 2dModerate, 1dNegligible.
 3. Hierarchical task analysis 77

3. Hierarchical task analysis

An alternate method of task analysis is a hierarchical task analysis (HTA), which describes
the activity or workflow to be analyzed in terms of a hierarchy of goals, sub-goals, operations,
and plans (Stanton et al., 2013). An HTA may stand on its own or be integrated with additional
task analyses. The end result of an HTA is a detailed description of a task or activity workflow.
A benefit of a HTA is to further describe the relationships between the use case (parent task)
and subtasks through a numbering scheme. This approach is extremely helpful in the design of
complex software systems (see description in Chapter 7) wherein different approaches to
describing user interactions can be broad and deep while maintaining a structured approach
to the use case. For example, in HTA there could be two different paths to complete the
same use case such as. If a new software introduced a login HTA, which could look like:
1. If a user is new to the system, complete Task 1
2. If a user has registered within the system, complete Tasks 1.1, 1.2 and 1.5
The benefits of HTA include the ability to compare different approaches to supporting the
same task, assuring the development team uses the same consistent approach and language
in order to compare the use case approaches. The results are an abstraction of the task which
enable designers to capture multiple implementations of a design pattern by expressing inter-
actions in a structured format.
An HTA is completed by focusing on a hierarchy of use cases, tasks, sub-tasks, and use
plans, as described in a process for any application laid out by Annett (2004).
1. Define the use case(s) under analysis.
2. Collect data about the use case, such as tasks involved, interactions, and constraints,
through observation, subject matter expert input, and walkthroughs.
3. Constructed the HTA with the starting point of the flow chart as the use case.
For the hand-held glucose meter example, the use case would be for the user to take a blood
glucose reading. Tasks can then be identified that need to be completed to achieve the overall
goal. For example, a task would be to turn on the blood glucose meter or load the test strip.
Tasks are then broken down further into sub-tasks, if required, so that the bottom level of
each branch is a stand-alone functional operation. For instance, one sub-task of the HTA
would be to press the power button or insert testing strip into BG meter. After all tasks
and sub-tasks are in place, then use plans are added to dictate the order in which the goals
are achieved. Use plans are numbered steps by which each task or sub-task will be carried
out. If tasks and sub-tasks must be completed in a specific order(s), it is specified via a use
plan. Fig. 6.3 shows individual use plans for different tasks. For example, for the task of
turn on the glucose meter (Task 1, Use Plan 1), the batteries must be inserted first before
pressing the power button, which would be dictated by a use plan.
The HTA can be completed in a hierarchical format and/or a tabular format. The hierar-
chical format is beneficial in visualizing interconnected tasks and the order in which they
need to be completed. The tabular format is typically used as a supplement to the hierarchical
format. Table 6.7 is the tabular format version of the HTA in Fig. 6.3. The tabular format
(Table 6.7) structures the tasks into a more linear framework that may not suit certain

II. Discovery & input methods

FIG. 6.3 Hierarchical task analysis for a handheld blood glucose meter (hierarchical format). Example plans are
included in Table 6.7 below.

TABLE 6.7 Hierarchical task analysis for a handheld blood glucose meter.
Hierarchical Task Analysis e Blood Glucose (BG) Meter

0. Take BG reading
Plan 0 - User must complete tasks in the following order to successfully take a BG reading:
1 e 2 e 3 e 4 e 5, or
2 e 1 e 3e4 e 5
1. Turn on BG meter
Plan 1 - User must complete tasks in the following order to successfully turn on BG meter:
1.1e1.2
1.1 Insert batteries into BG meter
1.2 Press power button
2. Load strip into BG meter
2.1 Insert strip into BG meter slot
3. Load blood sample onto strip
Plan 3 - User must complete tasks in the following order to successfully load blood sample onto strip:
3.1e3.2 e 3.3
3.1 Lance finger with a lancing device
3.2 Squeeze finger until a drop of blood appears
3.3 Place drop of blood on sample area of the test strip
4. Analyze blood sample
4.1 Press Test button
5. Interpret results
Plan 5 - User must complete tasks in the following order to successfully interpret results:
5.1e5.2
5.1 Read value displayed by BG meter
5.2 Determine if action is necessary
 5. Using task analysis for instructional design 79
applications but allows for easy conversion into a full task analysis (including PCA, use error
identification, and determination of severity level).
Using HTA as an analysis method has both advantages and disadvantages. Advantages
include that it is easy to create and implement and is a useful input to other analyses
including task analysis, PCA analysis and use error identification. It provides a high level
overview that can be beneficial as a reference while performing more detailed analyses. There
are also disadvantages to using HTA as the only task analysis because the HTA contains
mostly descriptive rather than analytical information and it might not be suited for complex
systems and tasks (Annett, 2004).

4. Task analysis as a design tool

A task analysis serves as a tool throughout the design process. In addition to providing
the foundation for task identification and task categorization, a task analysis can play a
crucial role in improving device design. Device designers can utilize the task analysis
and corresponding PCA to prioritize design features associated with critical tasks and
implement mitigations to prevent use errors from occurring. Additionally task analysis
can lead to a more efficient and effective design related to human performance, including
safety and productivity. When a task analysis is used early in the design process, there is
a two-way flow of information. Human factors requirements and limitations are fed into
the design process and design decisions and constraints are then fed into the task analysis
(Kirwan & Ainsworth, 1992). Examples of how a task analysis can be used as a design tool
are below:
• A task analysis identifies the task of receiving a full dose from an auto-injector as a crit-
ical task. The associated PCA analysis identifies auditory and visual cues to inform the
user of dose completion. This will inform the device designer that the auditory and vi-
sual cues are priority design features to be optimized for safe and effective use.
• A task analysis identifies the task of administering a dose using an auto-injector as a
critical task and a green bar appears in the medication window when all medication has
been administered. Because it was categorized as critical, early human factors testing
was conducted. Users provided feedback that the medication kept streaming from the
needle for a few seconds after the green bar appeared in the medication window and
were concerned that they would not have received a full dose. Designers used the task
analysis and testing results to revise the device design prior to validation testing.

5. Using task analysis for instructional design

The task analysis is a fundamental input to instructional material development. Instruc-

tional designers rely on the task analysis as an outline for the necessary steps, formatting
and structure of the instructional material. The goal of the instructional material is to guide
accurate, safe and effective user performance with a device, which is defined by the task anal-
ysis. This definition of performance includes identification of critical, non-critical, and

II. Discovery & input methods

80 6. Task analysis

knowledge tasks. Additionally, it may require that the task analysis include descriptions of
the tasks in terms of the knowledge, skills and abilities (KSAs) the user must have in order
to achieve successful performance of device use. It is important to note that KSAs are most
helpful when developed by instructional designers or professionals who are familiar with
performance-based training. Otherwise KSAs easily become an exhaustive list of, for
example, required user knowledge that is content heavy and may not necessarily be relevant
to performance descriptions or be useful in the development of instructions. Deficiencies in a
task analysis, such as a lack of clear KSAs, can lead to poorly designed instructions, which
can cause difficulties use errors, including incorrect performance and lack understanding
and ability to find critical information.
Often, when human factors experts are analyzing use errors that have occurred in a usabil-
ity evaluation, the instructional materials may be a potential source of the error. A robust and
thorough task analysis can help pinpoint the actual source of the use error and provide
insight into a potential mitigation.
Additionally, instructional designers may be required to look deeper and in more detail
when developing the task analysis. They may ask questions related to the importance of
timing and the consequences if a task is not performed correctly. These insights impact
how the instructional material is presented including warnings, cautions and format as it
is common for use errors to stem from knowledge comprehension aspects of a task. Much
of the cognitive load on a user comes from the processing of the instructional material.
The task analysis helps promote user performance expectations and clearly communicates
KSAs. Chapter 9 provides more insight into the development and role of instructional design
in overall device usability.

6. Summary

In summary, a task analysis is a fundamental process in early device design, instructional

material creation, formative testing protocol development and final usability evaluation pro-
cess. It is the development is a systematic process involving use case identification, task iden-
tification, sub-task breakdown. Providing key information in regards to device usability
through PCA analysis, potential use error identification and potential harm/outcome identi-
fication. In creating a task analysis, it is important to involve input from knowledge experts
(e.g. clinical stakeholders), MAUDE database research on similar devices, observations of
users with similar devices, expert review, investigation into videos of device use or similar
device use, instructional materials, risk documentation, reverse engineering and/or direct
experience with similar devices. Task analyses can take the form of a hierarchical task anal-
ysis, which is beneficial in visualizing interconnected tasks and the order in which they need
to be completed. When developed and used correctly, a task analysis is an invaluable tool for
improving device design, serves as a fundamental input to instructional material develop-
ment, provides insights into use-related risks and user-device interactions that could be
problematic for users.

II. Discovery & input methods

 References 81

Acknowledgments
Special thanks to Drs. Daryle Gardner-Bonneau, Deborah Billings Broky, and Jessie Huisinga for critical comments
and suggestions. Thank you to Elissa Yancey for editing.

References
Annett, J. (2004). Hierarchical task analysis. In E. Salas, H. W. Hendrick, N. A. Stanton, A. Hedge, & K. Brookhuis
(Eds.), Handbook of human factors and ergonomics methods (pp. 329e337). CRC Press. https://doi.org/10.1201/
9780203489925-9.
ANSI/AAMI HE75. (2009). Human factors engineering e design of medical devices.
ANSI/AAMI 14971. (2010). Medical devicesd application of risk management to medical devices. American National Stan-
dard, 2008.
Bisantz, A. M., & Burns, C. M. (2008). Applications of cognitive work analysis. CRC Press.
Kirwan, B., & Ainsworth, L. K. (1992). A guide to task analysis. University of Michigan, 16(2), 417. https://doi.org/10.
4324/9780203221457.
Sharit, J. (2006). Handbook of human factors and ergonomics. https://doi.org/10.1002/0470048204.ch27.
Stanton, N. A., Salmon, P. M., et al. (2013). Human factors methods: A practical guide for engineering and design. Ashgate
Pub. Co.
U.S. Department of Health and Human Services Food & Drug Administration Center for Devices and Radiological
Health (2016). Applying human factors and usability engineering to medical devices.

II. Discovery & input methods