my blog

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.

Task analysis reveals the potential to help people by creating new
systems or revising existing systems. Sometimes these insights
come immediately from observations of people interacting with an
existing system, such as a driver getting cold hands trying to unlock
her car in frigid winter weather. But often these insights come
from careful analysis of task hierarchy, flow or sequence, such
as feedback indicating when the door has been unlocked. This
analysis can be qualitative, with a focus on empathy and general
insights about the users’ experiences. It can also be quantitative,
where tasks are described in terms of frequency of occurrence,
probability of a failure, and task duration. This focus on task details
needs to be placed in the broader user experience and then linked
to design solutions. Here we discuss developing personae and use
scenarios as first steps in linking task analysis results to system
specifications.

specifications.
User identification and persona development describes the
most important user populations of the product or system. For
example, designers of amore accessible ATMmight characterize
the user population as people ranging from teenagers to senior
citizens, having at least a third-grade English reading level, and
a range of possible physical disabilities. After identifying characteristics
of the user population, designers should also specify the
people who will be installing or maintaining the systems.

It is important to completely describe the potential user population.
This usually includes characteristics such as age, gender,
education level or reading ability, physical size, physical abilities (or
disabilities), familiarity with the type of product, and task-relevant
skills. For situations where products or systems already exist, one
way that designers can determine the characteristics of users is to sample the existing population of users. For example, the ATM designer
might measure the types of people who currently use ATMs.
However, this will result in a description of users who are capable
of using, and do use, the existing ATMs. This is not an appropriate
analysis if the goal is to attract, or design for, a wider range of users.

A simple list of user characteristics often fails to influence design.
Disembodied user characteristics may result in an “elastic
user” whose characteristics shift as various features are developed.
Designing for an elastic user may create a product that fails to satisfy
any real user. Cooper [28] developed the concept of personas to
represent the user characteristics in a concrete and understandable
manner. A persona is a hypothetical person developed through
interviews and observations of real people. Personas are not real
people, but they represent key characteristics of the user population
in the design process. The description of the persona includes
not only physical characteristics and abilities, but also the persona’s
goals, work environment, typical activities, past experience,
and precisely what he or she wishes to accomplish. The persona
should be specific to the point of having a name.

Sequence diagrams help define personae by identifying roles,
tasks, and communications. The task hierarchy specifies goals
and motivations. For most applications, three or four personae
can represent the characteristics of the user population. Separate
personae may be needed to describe people with other roles in
the system, such as maintenance personnel. The personae exist
to define the goals that the system must support and describe
the capabilities and limits of users in concrete terms. Personae
describe who the design is for and act as the voice of the user,
preventing the natural tendency of the design team to assume
users are like themselves.

Because personae define several “typical” users, this method
runs the risk of neglecting the extremes, such as the 5th and 95th
percentiles of a population. Techniques to systematically accommodate
these extremes are discussed in the context of fitting designs
to the physical dimensions of people in Chapter 12.

Design Exercise:
Stanford wallet project
This exercise provides a brief exposure
to design thinking. The goal is to
practice designing and recognizing a
user’s need and then translating that
need into a protype product that is
then evaluated.
This exercise is an abbreviated
version of the StanfordWallet
Project [45]. Depending on time,
each step can be completed in less
than five minutes.
Step 1 Everyone. Design/draw the
ideal wallet.
(Recognize that your perfect wallet is
not perfect for others.)
Step 2. Pair up in teams of two. Person
1 acts as the designer. Person 2
acts as the user.
Step 3. Show NOT tell. Designer asks
user about the ideal wallet. Some
questions to consider: What should
it look like? How should it feel? What
should it be able to hold? How do you
want to carry it? What functions do
you want?
Step 4. Switch roles. Person 1 is now
the user. Person 2 is now the designer.
Step 5. Continue Show NOT tell.
Repeat Step 3.
Step 6. Self reflection Designer explains
the users needs in one sentence:
“[user] needs a way to [user’s
needs] because... (or “but”... or “surprisingly”...)

Table 2.2 Stanford design exercise

Scenarios, user journeys, and use cases complement personas.
Personas are detailed descriptions of typical users and scenarios
are stories about these personas in a particular context. Scenarios,
also termed user journeys, describe situations and tasks relevant
to the use of the system or product being developed. Scenarios
are a first step in creating the sequence of screens in software development,
and they also define the tasks users might be asked to
complete in usability tests. In creating a scenario, tasks are examined,
and only those that directly serve users’ goals are retained.
Two types of scenarios are useful for focusing scenario specification
on the design. The first is daily use scenarios, which describe
the common sets of tasks that occur daily. In the car example, this
might be the sequence of activities associated with entering the car
when parked in the owners’ garage. The second is necessary use
scenarios, which describe infrequent but critical sets of tasks that must be performed. In the car example, thismight be the sequence
of activities associated with entering the car during a snowstorm.
Scenarios can be thought of as the script that the personae follow
in using the system[28].

Scenarios typically support conceptual design, where the general
activities of people are described independent of technology.
Use cases help move from conceptual design to prototypes. Use
cases are a user-centered description of what the technology is
meant to do. At the simplest level, a use case is a sequence of tasks
that produce ameaningful outcome, such as entering and starting
a car. These tasks can be described in a more formal way in a flow
diagram and implemented in a software or hardware prototype.

Observations organized in task hierarchies, flows, and sequences
help define personae and scenarios. Personae and scenarios, in
turn, help define new task hierarchies, flows and sequences that
the new design will make possible. As an example, a flow diagram
associated with the new system, such as a keyless entry system
for a car, would document the intended interactions between the
person and new system. Often it is possible to use scenarios, use
cases and personae to create prototypes. Personae and scenarios
also provide a starting point for more specific task analysis, such
as those that focus on the environment, workload, safety, and automation.
The type of analyses needed depends on the scope of
the design and the particulars of the system.

Environment and context analysis describes where the tasks,
scenarios, and personae live. For example, if ATMs are to be placed
indoors, environmental analysis would include a somewhat limited
set of factors, such as type of access (e.g., will the locations be
wheelchair accessible?), weather conditions (e.g., will it exist in a
lobby with outdoor temperatures?), and type of clothing people will
be wearing (e.g., will they be wearing gloves?), issues considered
in more detail in Chapter 14 where we discuss the physiology of
work. Beyond the physical environment, the culture and norms of
workplace should be considered as discussed in Chapter 18.

Once task-related information has been collected, it must be organized,
summarized, and analyzed. At the simplest level, the task
analysis might be summarized as a list of challenges faced by people.
As an example, observing drivers trying to unlock their cars
during aWisconsin winter could show how fumbling for keys might
threaten drivers with frostbite. Sometimes these challenges can
inspire important innovations, but often a more detailed analysis
of tasks is needed to identify solutions and to avoid unintended
consequences. Some of the most common ways to organize task
data include:

1. Task hierarchy: Goal, task, subtask decomposition

2. Task flow: Control, decisions regarding the flow from one
task to another

3. Task sequence: Task duration and sequence, as well as communication
between system components

Task hierarchy data can be shown as an arrangement of tasks
where tasks are broken into more specific subtasks. Goals are at the
top of the hierarchy and the tasks at the bottom represent detailed
actions needed to accomplish those goals. The tasks higher in the
hierarchy are why the ones below are performed, and the tasks
lower in the hierarchy describe how the tasks above are achieved.
A task hierarchy makes it possible to organize a complex array of
many actions into a few general tasks, linking a detailed description
to a more general description.

Figure 2.3 shows a task hierarchy for unlocking a car prior to
driving. General tasks, such as “Car entry” are broken into more
specific tasks, such as “Unlock car” and “Open driver side door.”
These are further broken into very specific actions. For “Unlock car”
thismight include “Find key and key fob”, “Press Open on key fob,”
and so on. The level of task hierarchy should be aligned with the
purpose of the analysis and should avoid unnecessary detail. Figure
2.3 shows how the purpose of the analysis focuses attention on
describing unlocking the car and so the “Buckle seatbelt” activity
is not broken into subtasks.

A task hierarchy prompts innovation by identifying different
ways of achieving the same overall task with different subtasks. For
example, considering different ways you can perform“Car entry”
may lead to the use of a smart phone rather than keys. A task hierarchy
also makes it easy for the analyst to develop spreadsheets to
record information for each task or subtask. The spreadsheet contains
a row for each task, and columns for information describing
the tasks. This information might include task duration, conditions
thatmust be met to performthe tasks, why the task is difficult, common
errors, strategies, skills, or knowledge. One simple analysis
that might be part of a time-motion study is to use a spreadsheet
to calculate total task time and compare it with a new design with
different tasks

Figure 2.3 Task hierarchy for driving a car with a focus on unlocking the
door.

Task flow data from one task to another is captured by a flow
chart. Activity diagrams build on flow charts and also show tasks
that are performed concurrently (Figure 2.4). This diagramshows
the flow from one task to another and the decision points that
determine which task should follow. The flow from one task to
another can be sequential, shown as an arrow connecting tasks,
which are shown as rounded rectangles. The flow can also be
branched, where the decision to flow to one task or another is
indicated by a diamond. The flow can also be concurrent where
tasks can occur in parallel, which is indicated by a set of tasks
bounded on the top and bottom by horizontal bars.

Figure 2.4 An activity diagram shows task flow for entering and starting
a car.

Figure 2.4 shows an activity diagram for the entering and starting
the car. It begins with unlocking the door and finishes when
the settings are adjusted and the engine is started. The diamond
after the unlock door indicates that the door can be opened only
if the correct key is turned and loop from the diamond back to
unlock door indicates that keys are tried until the correct one is
inserted. After opening the door, the horizontal bar indicates that
the settings can be adjusted and the engine can be started in any
order.

Activity diagrams highlight decisions and the information required
to make them. Sometimes this information is trivial and
built into the interaction, such as the resistance experienced with
the wrong key is used to open a car door. In other situations, identifying
the cues that guide decisions can specify critical information
for an interface. Activity diagrams also indicate mandatory
ordering of tasks that need to be conveyed through the physical
configuration of the device, the interface, or through instructions.
In the case of a car, the physical configuration of the door and
key makes it impossible to start the engine before opening the
door. Positive locking of the door by a keyfob only outside the car
makes it impossible to lock ones keys in the car. Beyond inspecting
these diagrams, it is possible to “run” these diagrams as a computer
simulation and estimate the time it takes to performthese tasks.

Y Activity diagrams capture task
flow and information.
Sequence diagrams capture
task sequence and timing.

Task sequence data are shown in sequence diagrams that show
the order and duration tasks for each object and person in the
system. The activity of each person and object is represented as a
timeline that runs from the top of the diagram to the bottomand
rectangles on this timeline indicate when the person or object is
active in responding to other elements of the system. Horizontal
arrows indicate communication between people and objects. Solid
lines and arrows indicate synchronous messages, where a response
is required before other activities can proceed. Dashed lines with
open arrows indicate asynchronous messages, where activities can
proceed without a response. Responses are indicated by dashed
lines with open arrows at the of a rectangle.

Figure 2.5 Sequence diagram for unlocking and entering a car.

Figure 2.5 shows a sequence diagram for entering and turning
on a car. The left-most timeline begins with the driver inserting
a key into the door. The next timeline indicates the feedback provided
by the door that the door is unlocked. The driver then inserts
the key into the ignition and tries to start the car, which is indicated
by the engine being on. This figure shows a sequence diagram,
which focuses on one of many particular sequences of tasks. It
shows the sequence associated with inserting the correct key and
not what would have happened with the incorrect key or using
a key fob. Fault tree analysis (see Chapter 16 on system safety)
directly addresses how the probability of failure associated with
many tasks combine to influence safety. Sets of tasks with many
decision points are better represented by activity diagrams than by
sequence diagrams.

Sequence diagrams highlight communication, particularly the
responses that provide people with feedback regarding the success
or failure of their actions. Interaction design should ensure clear
and timely feedback. Diagrams that have manymessages that cross
several timelines indicate a need to reorganize and simplify the
communication so that each person or object communicates with
neighbors and that messages only occasionally cross timelines.
One way to avoid messages crossing multiple timelines is to ensure
that each object and person has a clear role that describes how it is
responds to messages. High activity for one person and low activity
for another might indicate workload that could be balanced by
adjusting the roles of each.

Task data are collected by observing and talking with multiple users.
The overall objective is to see the world through the eyes of the person
the system is being designed for, and to develop empathy for
the challenges, demands, and responsibilities they face. This empathy
helps focus attention to the details of the system that matter to
the user. These details might be very different than those that might
be noticed by the engineer implementing the design. The particular
way to understand users’ tasks depends on the information
required for the analysis. Ideally, human factors specialists observe
and question users as they performtasks in the place where they
typically perform those tasks. This is not always possible, and it
may bemore cost effective to collect some information with other
techniques, such as surveys or questionnaires. Task data collection
techniques include:

1. Observations and questions of people as they use an existing
system

2. Retrospective and prospective verbal protocol analysis

3. Unstructured and structured interviews including focus groups

4. Surveys and questionnaires

5. Automatic data recording

Observation involves watching users as they interact with existing
versions of the product or system. This is one of themost useful
data collection methods. If we were interested in car design, we
would find drivers who represent the different types of people the
car is to be designed for and then observe how they use their cars.
People are asked to performthe activities under a variety of typical
scenarios, and the analyst observes the work, asking questions as
needed. Observation should be performed in the environment that
the person normally accomplishes the task (See Table 2.1).

Source: Wikimedia Commons. 3
Probe questions for theMaster/Apprentice
observation approach:
Who and what is needed to perform
the task?
What happens before, what after?
What does the task change, how is
this detected?
What has to be remembered?
What is the consequence of failure to
complete the task?
When in the day, and when relative to
other events, is the task performed?
How do people communicate and
coordinate their activity?

Table 2.1 Observing people to guide
design.

The meaning behind users’ tasks is often revealed in their
thoughts, goals, and intentions, and so observations of physical
activity may not be sufficient to understand the tasks. This is particularly
true with primarily cognitive tasks that may generate little
observable activity. In such cases, it can be useful for people to
think out loud as they performvarious tasks. One approach is to
adopt a master-apprentice relationship, where the observer acts
as an apprentice trying to learn how the user performs tasks [39].
Adopting this relationship makes it easy for observers to ask questions that help users to describe their underlying goals, strategies,
decisions

Retrospective and prospective protocol analysis address important
limits of direct observations. Direct observations disrupt
ongoing activity or they can fail to capture rarely occurring situations.
For example, trying to understand how people deal with
being lost as they drive would be difficult to observe because talking
to the driver could be distracting and the analyst would have to
ride with the driver for many trips to observe the rare case that they
get lost. Talking about tasks is termed verbal protocol, and retrospective
verbal protocols require that people describe past events
and prospective verbal protocols require that people imagine how
they would act in future situations

Video recordings of users’ activity are an effective way to prompt
retrospective protocols. The human factors specialist and user can
watch the video together and the users can describe what they
were thinking as they performed the tasks. The human factors specialist
can pause the playback and ask probe questions. Because
users do not have to performthe task and talk about it at the same
time retrospective protocols can be easier on the user. Retrospective
protocols can even yield more information than concurrent
protocols.

Structured and unstructured interviews involve the human
factors specialist asking the user to describe their tasks. Structured
interviews use a standard set of questions that ensure the interview
captures specific information for all interviewees. Unstructured
interviews use questions that are adjusted during the interview
according to the situations. The analyst might ask about how the
users go about the activities and also about their preferences and
strategies. Analysts should also note points where users fail to
achieve their goals,make errors, show lack of understanding, and
seem frustrated or uncomfortable.

Unstructured interviews use probe questions similar to those
used for direct observation. These questions address when, how,
and why a particular task is performed, as well as the consequences
of not performing the task. Critical incident technique is a particularly
useful approach for understanding how people respond to
accident and near accident situations in high-risk systems. Because
accidents are rare, direct observation is not feasible. With
the critical incident technique, the analyst asks users to recall the
details of specific situations and relive the event. By reliving the
event with the user, the analyst can get insights similar to those
from direct observation [42].

Critical incident technique
makes it possible to “observe”
past events.

Focus groups are interviews with small groups of users, rather
than individuals [43, 44]. Focus groups typically consist of between
six and ten users led by a facilitator familiar with the task and
system. The facilitator should be neutral with respect to the outcome
of the discussion and not lead the discussion to a particular
outcome. One benefit of focus groups is that they cost less than individual interviews because they require less time for the analyst.
Also discussion among users often draws out more information
because the conversation reminds them of things they would not
otherwise remember.

Observations are typically more valuable than interviews or
focus groups because what people say does not alwaysmatch what
they do. In addition, peoplemay omit critical details of their work,
they may find it difficult to imagine new technology, and theymay
distort their description to avoid appearing incompetent. It is often
difficult for people to describe how they would perform a given
task without actually doing it—describe how you tie your shoes
without being able to touch and see your shoes.

Surveys and questionnaires are typically used after designers
have obtained preliminary descriptions of activities or basic tasks.
Questionnaires are often used to affirmthe accuracy of the information,
determine the frequency with which various groups of
users performthe tasks, and identify any user preferences or biases.
These data help designers prioritize different design functions or
features. See Chapter 3 for a more complete discussion of surveys
and their limits.

Automatic data recording uses smartphones and activity monitors
to record people’s activities unobtrusively. An example of such
a system is a data logging device that records the position of the
car, its speed, and any hard braking or steering events. Such a
device can show where drivers go, when they choose to travel, and
whether they travel safely. Such data has the benefit of providing a
detailed and objective record, but it lacks information regarding the
purpose behind the activity. This limitation might be avoided by
using automatically recorded data to prompt retrospective verbal
protocol.

Limitations of data collection techniques. All methods have
limits, but combinations of the methods can compensate. A more
general limit is that all of these methods document existing behavior.
Designing to support existing behavior means that new
controls, displays, or other performance aids might simply enable
people to do the same tasks better, butmight not produce dramatic
innovation. Innovation requires the analysis to focus on underlying
goals and needs, and identify different ways of accomplishing
these goals.