my blog

Questions for 2.1 Human Factors in Design and Evaluation

P2.1 What is the difference between user interface design and user experience design?

P2.2 Why is designing a beautiful interface often insufficient in creating a useful system?

P2.3 What type of product or system might be best suited to Vee, plan-do-check-act, and Scrum
development cycles?

P2.4 What is the difference between the plan-do-check-act, and Scrumdevelopment cycles?

P2.5 Why are observations and interviews of users important for designers and engineers?

P2.6 Describe how the speed-accuracy tradeoff would lead you to apply different human factors
methods to a smart phone app versus a commercial airliner.

P2.7 Describe the difference between user-centered system design and the user designing the
system.

P2.8 Why are observations generally preferred over focus groups for front-end analysis?

P2.9 Give an example of how the lack of holistic, systems thinking could lead technology development
to have unintended consequences.

P2.10 What alternatives to evaluation would be preferable to a comprehensive test and evaluation
because they are less resource intensive?

P2.11 Explain why understand, create, and evaluate activities are described as a cycle.

P2.12 Discuss how post-release surveillance would be used differently for consumer products and
high-risk systems.

Questions for 2.2 Understanding Users, Context, and Tasks

P2.13 Describe the role of the Five Whys in understanding the role of human error in system
performance.

P2.14 How does the master-apprentice mindset influence how onemight observe and interview
people as part of a contextual inquiry?

P2.15 How does a task analysis help designers develop a deeper empathy for those they design
for?

P2.16 What are the three basic elements of a task analysis?

P2.17 How does the iterative nature of task analysis affect how you would organize your data
collection and interpretation?

Questions for 2.3 How to Perform a Task Analysis

P2.18 Why is it important to identify the focus and purpose of a task analysis before you begin?

P2.19 What four types of data are typically collected and how might they be more or less relevant
to designing the layout of machines in a factory? Compare that to designing news feed on a
smartphone.

P2.20 What data recording technique or techniques would you use to design a route planning and
navigation app for pizza delivery?

P2.21 Why is the critical incident technique particularly useful for understanding the tasks people
performin high-risk environments?

P2.22 What general limitation affects all task analysis data collection techniques?

P2.23 If the focus of your task analysis is on coordinating the communication of baristas for a local
coffee shop, what task summary approach would you use and why: Task hierarchy, task flow,
or task sequence?

P2.24 If the focus of your task analysis is on supporting decisions with a checklist, which task
summary approach would you use and why: Task hierarchy, task flow, or task sequence?

P2.25 If the focus of your task analysis is on training operators on the concepts needed to control a
nuclear power plant, which task summary approach would you use and why: Task hierarchy,
task flow, or task sequence?

P2.25 If the focus of your task analysis is on training operators on the concepts needed to control a
nuclear power plant, which task summary approach would you use and why: Task hierarchy,
task flow, or task sequence?

P2.27 What is a benefit of defining a persona compared to simply listing user characteristics?

P2.28 How do scenarios differ from use cases in the context of moving from task analysis to system
design?

Questions for 2.4 Iterative Design and Refinement

P2.29 Is it possible to create prototypes based on use cases and scenarios? Explain.

P2.30 Describe a specific analysis that goes beyond the development of personas and use cases to
address a particular issue.

P2.31 Describe the difference in the two types of understanding that guides prototype design: user
tasks and general human capabilities.

P2.32 Apply two of the design heuristics to the re-design of the instrument cluster of a car.

P2.33 How might a design pattern speed the design of the payment system for the website of car
rental company?

P2.34 How does a decision matrix help justify the selection of particular product features for
inclusion in a product?

P2.35 You are designing a website for a local real estate agent, describe how you would use wireframes,
mockups, and prototypes. Describe the primary audience and purpose of each.

P2.36 Identify two elements of a system beyond the obvious focus of a prototype that often merit
attention in design.

As described at the start of this chapter, design is an iterative cycle
of understanding, creating, and evaluating. Understanding begins
with observations of people, task analysis, and knowledge of human
characteristics. This understanding informs the creation of
mockups and prototypes, which are immediately evaluated as designers
and users experience their creations. We have seen that the
human factors specialist performs a great deal of informal evaluation
during the systemdesign phases. These evaluations produce
a deeper understanding of the design problemwhich leads to revisions.
More formal evaluations are also required. These evaluations
must carefully assess the match of the system to human capabilities,
as well as the ability of the systemto support the tasks of the
person. Chapter 3 describes evaluation methods in detail.

Y Informal evaluation guides
the iterative design, but formal
evaluation is needed
to ensure design objectives
have been met

2.6 Summary

In this chapter we described some of the techniques used to understand
user needs and to create systems to meet those needs.
Designers who skip the front-end analysis techniques that identify
the users, their needs, and their tasks risk creating technologycentered
designs that tend to fail. The techniques described in
this chapter provide the basic outline for creating human-centered
systems: develop an understanding of people’s needs through observation
and then test that understanding with prototypes that
can be quickly adjusted to better meet people’s needs. A critical
step in designing human-centered systems is to define the human
factors requirements. Many of these requirements depend on cognitive,
physical, and social considerations.

“Indifference towards people
and the reality in which they
live is actually the one and
only cardinal sin in design.”
(D. Rams) [46]

Additional Resources

One of the best resources for task analysis is Guidebook to Task
Analysis [53], which describes 41 differentmethods for task analysis
with detailed examples. For a more general set of designmethods
an excellent source is Universal Methods of Design: 100 Ways to
Research Complex Problems, Develop Innovative Ideas, and Design
Effective Solutions [54], as is Guide toMethodology in Ergonomics:
Designing for human use [41].

TaskArchitect is a computer-based tool for implementing some
of these tasks analysis methods (http://www.taskarchitect.com).
Human factors specialists usually rely on many sources of information
to guide their involvement in the design process, including
previous published research, data compendiums, human factors
standards, and more general principles and guidelines.

Data compendiums provide detailed information concerning
human factors aspects of system design. One example is the fourvolume
publication by Boff and Lincoln [55], Engineering Data
Compendium: Human Perception and Performance.

Human Factors design standards are another formof information
to support design. Standards are precise recommendations
that relate to very specific areas or topics. One of the commonly
used standards in human factors is the Human Engineering Department
of Defense Design Criteria Standard MIL-STD-1472G [56].
This standard provides requirements for areas such as controls,
visual and audio displays, labeling, anthropometry, workspace design,
environmental factors, and designing for maintenance, hazards,
and safety. Other standards include the ANSI/HFES-100 VDT
standard and the ANSI/HFES-200 ANSI/HFES 200 Human Factors
Engineering of Software User Interfaces [57].

Human Factors principles and guidelines provide more general
information than standards. Standards do not provide solutions
for all design problems. For example, there is no current
standard to tell a designer where to place the controls on a camera.
The designer must look to more abstract principles and guidelines
for this information. Human factors principles and guidelines
cover a wide range of topics, some more general than others.
Rams, Nielsen, and Tognazzini provide general principles for
design [46, 47, 48], and Van Cott and Kinkade provide human factors
guidelines for equipment design [58]. The following chapters
reference specific guidelines related to physical facilities medical
devices, and vehicle design.

Prototype development is a central activity for many design teams.
The role of human factors engineers in prototyping is to ensure
the prototypes include functionality sufficient to understand how
users will experience the system and then provide rapid feedback
to the design team regarding how to improve the users’ experience.

Y Paper prototypes are more
of a tool to understand user
needs than an initial design
solution.

Early prototypes for software development are created by drawing
dialog boxes and other interface elements to create a paper prototype
as shown in the sidebar (Table 2.4). Paper prototypes of software
systems are useful because screen designs can be sketched,
thenmodified with little effort, making it possible to try outmany
design alternatives. For this reason, they are useful early in the
design process. Because paper prototypes are sketchy versions
of the system, users feel more open to identifying flaws. Paper
prototypes can even be created during the interviews and used as
props to clarify conversations with users. The main purpose of
paper prototypes is to guide interaction design and ensure that the
structure of the systemmeets the users’ needs.

After paper prototypes, wireframes are created, which are simple
layouts that show grouping and location of content, but which
omit graphics and detailed functionality. Wireframes are primarily
used to communicate with the design team (see Chapter 10 for
more details), and are helpful in documenting decisions and communicating
the essential interactions people might have with the
product. Wireframes lack details for the look and feel of the interface
or product; these are elements that are the focus ofmockups.
Mockups focus on the look and feel, and include color, font, layout,
and choices of the final product. Wireframes are limited to software
systems, but mockups are often created for hardware systems.
Wireframes communicate the system’s functional characteristics
to the design team, and mockups are used to communicate the system’s
physical features to the design teamand other stakeholders,
such as users and managers.

Building on wireframes andmockups, we create high-fidelity
prototypes so that users can experience elements of the final design.
Collecting information from these experiences leads to redesigning
the prototype. One analysis showed that user performance
improved 12% with each redesign iteration and that the average
time to performsoftware-based tasks decreased 35% from the first
to the final design iteration [51], while another analysis showed 20-
40% improvement per iteration [52]. This redesign and evaluation
continues for many iterations, sometimes as many as 10 or 20, or
more for complex products.

Rough, easily created and easily
changed paper prototypes invite
changes.
A refined, high-fidelity prototype
provides an experience that more
precisely matches that of the final
product.
Source: X. Lu and X.Mei. 4

Table 2.4 Paper prototype and highfidelity
prototype

To summarize, using paper prototypes, wireframes, mockups,
and prototypes in the design process has a number of advantages:

• Paper prototypes help understand user needs and if the early
design concepts meet those needs

• Wireframes communicate and document ideas for the design
team

• Mockups make ideas concrete to stakeholders and sponsors

• Prototypes support heuristic evaluation

• Prototypes support evaluation by giving users something to
react to and use

Beyond these specific uses, prototypes help build empathy
for the user by allowing designers to directly experience the use
of their system. However, simply using the prototype is often insufficient
for the designer to have the same experience as the actual
user because designers are often very different from the users.
One method for designers to have an experience thatmore closely
matches that of actual users is to use empathy suits. Empathy suits
can help a 30-year old feel what it might be like to be an 85-year old
to get into car, or what it is like to get into a car when nine months
pregnant.

Although this discussion has focused on software prototypes,
prototypes of hardware are equally important, as are prototypes of
new work processes. Important elements of the overall system design
that the prototyping process might neglect include the support
systems, such as instruction manuals, and the broader organizational
design. Human factors professionals can help design these
with a prototyping mindset, where they develop initial designs
based on a task analysis and understanding of human capabilities
and then evaluate and improve the designs in an iterativemanner
before a final version is delivered. Prototypes of support material,
such as manuals and help systems, and of the team and organizational
design are sometimes neglected if the team is too focused
on the physical and software elements of the system.

Dieter Rams (1932–) Highly inuential designer
who asked and answered the question,
What is good design [10]?
His answers to this question remains an important
touchstone for design thinking.
Source: Vitsoe, CC BY-SA 3.0. 5
Good design is innovative: The possibilities
for innovation are not, by any means, exhausted.
Technological development is always
oering new opportunities for innovative design.
But innovative design always develops in
tandem with innovative technology, and can
never be an end in itself.
Good design makes a product useful: A
product is bought to be used. It has to satisfy
certain criteria, not only functional, but also
psychological and aesthetic. Good design
emphasizes the usefulness of a product whilst
disregarding anything that could possibly
detract from it.
Good design is aesthetic: The aesthetic
quality of a product is integral to its usefulness
because products we use every day aect
our person and our well-being. But only wellexecuted
objects can be beautiful.
Good design makes a product understandable:
It claries the product’s structure. Better
still, it can make the product talk. At best, it is
self-explanatory.
Good design is unobtrusive: Products fullling
a purpose are like tools. They are neither
decorative objects nor works of art. Their
design should therefore be both neutral and
restrained, to leave room for the userâ€s
self-expression.
Good design is honest: It does not make a
product more innovative, powerful or valuable
than it really is. It does not attempt to manipulate
the consumer with promises that cannot
be kept.
Good design is long-lasting: It avoids being
fashionable and therefore never appears
antiquated. Unlike fashionable design, it lasts
many years—even in today’s throwaway
society.
Good design is down to the last detail:
Nothing must be arbitrary or le€ to chance.
Care and accuracy in the design process show
respect towards the user.
Good design is environmentally-friendly:
Design makes an important contribution
to the preservation of the environment. It
conserves resources and minimizes physical
and visual pollution throughout the lifecycle of
the product.
Good design is as little as possible: Less,
but better—because it concentrates on the
essential aspects, and the products are not
burdened with non-essentials.
Back to purity, back to simplicity.

Figure 2.6 shows a simplified house of quality for the car door
design. The rows represent the user needs. The columns represent
system features. The task analysis identifies the importance or
weighting of each need, which is shown in the left-most column.
These weightings are often determined by asking people to assign
numbers to the importance of each user need. The rating in each
cell in the matrix represents how well each system feature satisfies
each user need. These weightings and ratings are typically defined
using the 9/3/1 rating scale, where 9 is most important, 3 ismoderately important, and 1 is least important. The importance of
any feature can then be calculated by multiplying the ratings of
each feature by the weighting of each user need and adding the
result. This result identifies the features that matter most for the
users, separating technology-centered features from user-centered
features

Cost/benefit analysis builds on the QFD analysis, which calculates
the importance of features that best serve the user needs.
This importance serves as the input to cost/benefit analysis, which
compares different designs according to their costs relative to their
benefits. Costs and benefits can be defined monetarily or by the
9/3/1 rating scale. A decision matrix similar to Figure 2.6 can support
the cost/benefit analysis. The features are listed as rows on
the left side of a matrix, and the different design alternatives are
listed as columns. Each feature is given a weight representing importance
of the feature—the result of the QFD analysis. For the
features in Figure 2.6 this would be the total importance shown
in the bottom row of the decision matrix. Then, each design alternative
is assigned a rating representing how well it addresses
each feature. This rating is multiplied by the weighting of each
feature and added to determine the total benefit of a design. The
cost for each design is divided by this number to determine the
cost/benefit ratio. The design with the lowest cost/benefit ratio
represents the greatest value.

Tradeoff analysis identifies the most promising way to implement
a design. If multiple factors are considered (e.g., effort, speed,
and accuracy), design tradeoffs might be based on the design that
has the largest number of advantages and the smallest number of
disadvantages. Alternatively, a decision matrix can be constructed.
The matrix would assess how well systems, represented as columns,
compare according to the performance criteria, represented as
rows. For example, for the design of a new car, the performance criteria
of a key-less entry system could be represented in one row and
an existing key entry system could be another row. The columns
would be time to enter the car, likelihood of errors, and ease of use.

Although the decision matrix analyses can be very useful, they
tend to consider each product’s features independently. Focusing
on individual featuresmay fail to consider global issues concerning
the interactions of each feature on the overall use of the product.
People use a product, not a set of features—a product is more than
the sumof its features. Because of this, matrix analyses should be
complemented with other approaches, such as scenario specification
and user journeys, so that the product is a coherent whole
that supports the user rather than simply a set of highly important
but disconnected features. The overall objective of these analyses
is to identify a small set of the most promising alternatives
for implementing in prototypes for further evaluation. Chapter 7
on decision making provides a more detailed discussion for the
strengths and weaknesses of decisionmatrix analysis.

Once the front-end analysis has been performed, the designers
have an understanding of the user’s needs. This understanding
can be used to identify initial system specifications and create
prototypes. Creating prototypes depends on two types of understanding:
understanding tasks and understanding general human
capabilities. Prototypes must support user tasks in a way that is
consistent with how people see, hear, feel, comprehend and act on
the world. This understanding is often distilled into principles or
design heuristics and Chapters 4 through 18 describe these in detail.
As initial prototypes are developed, the design team begins to
characterize the product in more detail, and evaluates how people
respond to the evolving product. The human factors specialist usually
works to ensure that the tasks people will performfall within
the limits of human capability. In other words, can people perform
the tasks safely and easily with the proposed system?

Design Heuristics
Create useful innovation: Address a
need, solve a problem (Chapter 2).
Attend to details: Small changes to
the design can have a big effect on
people.
Simplify: Remove irrelevant information,
but do notmask essential
indicators and feedback (Chapter 8).
Honest and understandable: Functions
should be reflected in forms
that make their states visible,
changes predictable, and interactions
intuitive (Chapter 4, 9, and 11).
Provide flexibility: People should be
able to adjust, navigate, undo and
redo, adopt shortcuts (Chapter 10,
12).
Consistency: The same label or action
should mean the same thing
in different situations—don’t deviate
from well-defined conventions
(Chapter 6, 10 and 11).
Anticipate needs: Provide options
rather than require people to recall
them. Choose thoughtful defaults
because people often adopt initial
settings (Chapter 6 and 10).
Minimizememory demands: Interactions
with technology should not
disrupt the flow of activities unless
necessary (Chapter 6).
Consider adaptation: Adopt a systems
perspective to identify otherwise
unanticipated outcomes,
particularly as people adapt to the
changes in the system (Chapter 18).
Fit the task to the person rather
than the person to the task

Table 2.3 General design heuristics

2.4.1 Providing Input for System Specifcations

Design heuristics help human factors professionals provide design
teams with quick input on whether the design alternatives are
consistent with human capabilities. Design heuristics or principles
provide a response that is grounded in years of design practice
and much research on human behavior. Table 2.3 shows 10
design heuristics derived from those of Rams, Nielsen, and Tognazzini
[46, 47, 48]. The table also shows the chapters that contain
the specific information on cognitive, physical and organizational
characteristics that underlies these heuristics.

These heuristics suggest promising design alternatives, but
are not simple rules that can be applied without thought. In fact,
in many instances, the heuristics conflict. As an example, providing
flexibility is needed to accommodate differences between
people and environments, such as hearing impairment making it
impossible to define an optimal volume setting. At the same time,
providing too much flexibility burdens the user with finishing the
design, and might lead to the user designing a poor system. As
a consequence, the 11 heuristics are not a set of strict rules, but
instead should be thought of as a checklist to provoke conversation.
Chapter 3 describes how these and other principles can be
used as part of heuristic evaluations and cognitive walkthroughs.
In a heuristic evaluation, you assess whether the system design
is consistent with the heuristics. To apply any of these principles
effectively requires an understanding of the underlying human characteristics described in forthcoming chapters, as indicated for
each heuristic.

Design patterns are solutions to commonly occurring design
problems and are most typically associated with software, but also
apply to physical systems. A number pad for a phone is an example
of a design pattern. Using design patterns, such as a conventional
number pad for entering phone numbers, has the benefit of eliminating
many design decisions. It is also likely to present people
with a familiar interaction that is consistent with other systems they
might use. Design patterns for user interfaces include common
ways of navigating multi-page applications, getting user input, and
browsing data (http://ui-patterns.com). Design patterns provide
a ready-made shortcut to the final design, but should be carefully
assessed to determine whether previously developed patterns fit
the current situation.

Human Factors requirements and system specifications need
to be defined where design patterns don’t fit the current situation.
These requirements include the system characteristics that are
needed to achieve the desired levels of safety, performance, and satisfaction.
For software design, human factors requirements might
include error recovery, or the ability to support people performing
more than one task at a time. As an example, for an ergonomic
keyboard design,McAlindon [49] specified that the new keyboard
must eliminate excessive wrist deviation, eliminate excessive key
forces, and reduce fingermovement. The design that resulted from
these requirements was a “keybowl” that is drastically different
from the traditional QWERTY keyboard currently in use, but a design
that satisfied the ergonomic criteria.

Identifying system requirements is a logical extension of the
task analysis that draws on the task data to specify (1) the overall
objectives of the system, (2) performance requirements and
features, and (3) design constraints. The challenge is to generate
system specifications that identify possible features and engineering
performance requirements that best satisfy user objectives and
goals. The objectives should be written to avoid premature design
decisions. They should describe what must be done to achieve the
user’s goals, but not how to do it. The system objectives should
reflect the user’s goals and not the technology used to build the
system.

Detailed human factors requirements
are most critical
to the Vee design approach

After the objectives, designers determine the means by which
the system will help the user achieve the goals. These are termed
performance requirements and features. The features define what
the system will be able to do and under what conditions. The
performance requirements and system features provide a design
space in which the team develops various solutions.

Finally, in addition to the objectives and system features, the
specifications document identifies design constraints, such as
weight, speed, cost, abilities of users, and so forth. More generally,
design constraints include cost,manufacturing, development time, and environmental considerations. The constraints limit possible
design alternatives.

Translating the user needs and goals into system specifications
requires the human factors specialist to take a systems thinking
approach, analyzing the entire systemto determine the best configuration
of features. The focus should not be on the technology
or the person, but on the person-technology system as a unit. The
systems design approach draws upon several tools and analyses,
that we highlight in the following discussion.

Quality Function Deployment can help prioritize systemfeatures.
How does the human factors specialist contribute to writing
the system specifications? He or she compares the system features
with user characteristics, activities, environmental conditions, and
especially the users’ preferences or requirements. This ensures
that the design specifications meet the needs of users and avoids
adding features that people do not want. Human factors designers
often use a simple yet effective method for this process known as
the QFD (quality function deployment), which uses the “house of
quality” analysis tool [50]. This tool uses a decision matrix to relate
user needs to system features, allowing designers to see which

features will satisfy user needs.