my blog

5

COMMUNICATIONS AND INFORMATION INFRASTRUCTURE

As shown in Table 1, the communications and information infrastructure of an agile enterprise
differs greatly from that of traditional enterprises. “Virtual Corporations” (Nagel
and Dove, 1992) and availability of electronic data communications lead to coworkers
collaborating from geographically dispersed locations. Concurrent engineering within a
fast-paced product development environment favors collaborative work between engineering
disciplines over “meet and disperse” work patterns (Forsythe and Grose, in press).
Emphasis is placed on seamless and direct information flows. With agility, many of the
traditional bottlenecks that provided time buffers to the product development process are
no longer present, due to automation and streamlining. Consequently, changes to product
and related artifacts occur much faster, leading to increased demands for information and
product data management. Finally, as enterprises focus on core competencies and opportunistically
enter Virtual Corporations, it is no longer practical to maintain and rely on
internal sources of information. Instead, the need arises for mechanisms that enable the
accessibility and efficient utilization of diverse, external sources of information.

TABLE 1.

General Differences Between Traditional and Agile Enterprises

Traditional Enterprise

Agile Enterprise

• Geographical colocation • Geographical separation
• Solitary work • Collaborative work
• Sequential information flow • Parallel information flow
• Time is negotiable • Time is critical
• Standardization of technology • Opportunistic technology use
• Artifacts relatively static • Artifacts change rapidly
• Information flow correlated with
organizational structure
• Information flow correlated with
project structure
• Extensive use of hard media • Extensive use of electronic media
• Constant, known, internal sources
of information
• Diverse, often unknown, external
sources of information
• Many indirect lines of communication • Mostly direct lines of communication

5.1

Electronic Data Communications

Agility introduces a dynamic, fast-paced environment that requires extensive collaboration
between widely dispersed team members who must work together with an efficiency
comparable to their being located in the same building, if not the same room (Virtual
Colocation). In the development of an agile product realization process for custom electromechanical
devices, information flow requirements for an agile enterprise have been
analyzed (Forsythe and Ashby, 1994). This analysis provided an understanding of the
roles filled by each participant in the enterprise, their information needs and sources, the
timing of information needs and information availability, and restrictions on the ability of
participants to use information once it had been received.
The information flow analysis followed the sequence illustrated in Figure 1. In the first step, team members were surveyed to determine their information needs. Before this survey
could take place, measures were necessary to heighten team member’s awareness of
their information needs. This was accomplished through a series of team meetings during
which the team jointly developed the project plan, including objectives, strategies for
meeting objectives, a detailed task network, schedule, and resource and funding projections.
Initially, team members completed paper surveys describing their roles and activities,
followed by in-depth interviews utilizing techniques from information requirements
analysis. Based on the information needs survey, the seven categories of information exchange
shown in Table 2 were developed. Subsequently, a matrix was developed showing
the information exchange categories relevant to each pair of team members.

To allocate technologies to various modes of information exchange, it was necessary to
develop functional requirements for each category of information exchange. The nature
of these requirements is illustrated by the following example of functional requirements
identified for the General Knowledge or Requests category:

TABLE 2.

Categories of Information Exchange

General Knowledge or Requests Transfer of Work/General Level of Skill
Meetings and events Documents
Memos and letters Figures and tables
Schedules Presentation graphics
Agendas Spreadsheets
Forms (surveys, progress reports) Project management materials
News, reports and announcements (e.g., PERT charts, Gantt charts)
Policies
Requests for information Collaborative Work
General Information (e.g., phone lists) Design and design analysis
Brainstorming
Person-to-Person Discourse Group planning
Communications requiring unequivocal Process documentation
and immediate confirmation or response Computer code development
Communications where a need exists to Document and presentation development
assure understanding of information content Project management
Communications in which a spontaneous
dialogue is essential Urgent Communications
Communications where concern exists Changes in schedules or availabilities
for emotional connotations or responses Meetings
Communications where socialization is Demonstrations
part of the implicit or explicit intent Important visitors
Demonstrations and tours Events, cccurrences, or other situations
Team building Requests for information
Transfer of Work/Specialized Level of Skill Casual or Informal Communications
CAD, CAM and solid model files Lunch or hallway discussions
Computer code Casual exchanges before and after meetings
Numerical control programs Discussions to break-up work sessions
FYI conversations
Authorized Gateway Customer Bull sessions

• It should be relatively easy (a few simple steps in addition to creating the message)
to transmit the message to every intended recipient.
• After receiving the message, each recipient should have a clear understanding of
what action is expected on their part and any needed details regarding how to accomplish
this action (e.g., meeting place and time.
• Given the occasional urgency of this type of communication, messages should be
available to recipients almost immediately following transmission and some mechanism
should be provided to alert recipients of the presence of the message.
• Most often the message content may be readily captured verbally or with alphanumeric
characters; however, there may occasionally be a need to include limited tables
or figures (e.g., maps, calendars, charts, etc.).

Alternative technologies were identified and assessed relative to the functional requirements
of each category. Based on these assessments, technology solutions for each information
exchange category were developed. These solutions were then incorporated into a
communications infrastructure design, which allocated technologies to meet the needs of
each team member. This infrastructure included e-mail, voice-mail, file sharing, product
data management, and collaborative work tools.Aproject-wide infrastructure was implemented
through these technologies, the success of which was demonstrated by the design
and production of custom, precision, electromechanical devices in 24 days or less (Forsythe
et al., 1995).

:Human Factors in Agile Manufacturing
A Brief Overview with Emphasis on
Communications and Information Infrastructure

Chris Forsythe
Sandia National Laboratories, MS 0829, Albuquerque, NM 87185-0829

ABSTRACT
Agile manufacturing has been promoted as a national strategy for improving industrial competitiveness.
Agility refers to the capability to very rapidly go from a set of unique customer requirements
to a quality, finished product. An appreciation of the human factors inherent to agile product
development is pivotal to the successful integration of agility-enabling technologies, as well as the
coordination of personnel working within a concurrent engineering environment. This article briefly
summarizes human factors contributions to: (1) development of agile business practices; (2) design
of enabling technologies; and (3) management of the introduction and fielding of new technologies
and business practices. More detailed discussion is offered for human factors related to the communications
and information infrastructure essential to an organization making the transition from
traditional to agile product development. © 1997 John Wiley & Sons, Inc.

1. INTRODUCTION
As industries position themselves for the competitive markets of today, and the increasingly
competitive global markets of the 21st century, agility, or the ability to rapidly develop
and produce new products, represents a common trend (Kovac, 1993; Levary, 1992;
Nagel and Dove 1992). Agility manifests itself in many different forms, with the agile
manufacturing paradigm proposed by the Iacocca Institute offering a generally accepted,
long-term vision (Nagel and Dove, 1992). In its many forms, common elements of agility
or agile manufacturing include: (1) changes in business, engineering, and production practices;
(2) seamless information flow from design through production; (3) integration of
computer and information technologies into all facets of product development and production
processes; (4) application of communications technologies to enable collaborative
work between geographically dispersed product development team members; and (5)
introduction of flexible automation of production processes.

Industry has rarely experienced as dramatic an infusion of new technologies or as extensive
a change in culture and work practices. In recognition of these emerging trends, a
panel session entitled Human Factors in Agile Manufacturing was held at the 1995 Human
Factors and Ergonomics Society Meetings in San Diego, CA, USA to discuss human
factors issues relevant to agile manufacturing and to present different perspectives on
those issues. The articles appearing in this special issue represent the perspectives presented
at that panel session and reflect the continuing evolution of thought concerning
these matters. This article briefly summarizes human factors related to the development of agile business practices, design of enabling technologies, and management of the introduction
of new technologies and business practices. Afterwards, more thorough discussion
is offered concerning human factors related to the communications and information
infrastructure essential to an enterprise fully realizing agility.

2

DEVELOPMENT OF BUSINESS PRACTICES

Implementation of agile manufacturing requires, at a minimum, extensive modification
of existing business practices, but often complete overhaul of existing practices (Greiss,
1993). In a market environment where corporate success hinges on rapid turnaround of
quality products, each new product development effort cannot begin from a blank slate.
Instead, corporations must maximize their ability to capture and utilize corporate history
and lessons learned (Goldman and Priess, 1992). Likewise, manufacturing processes fitted
to the demands of a given product must be replaced by flexible systems composed of
different pieces of equipment that readily accommodate a range of product parameters
(Brost et al., 1992; Staffend, 1992). Serial progression of designs through the product
development cycle is unacceptable. Concurrent engineering of designs is desirable, but
collaborative design is preferred for fast-paced design decisions in an environment that
offers little or no tolerance for error (Forsythe and Ashby, 1994). For the development of
agile business practices, there needs to be consideration of human factors affecting decision
making within fast-paced, dynamic environments (Eisenhardt, 1989). Likewise, knowledge
of team dynamics, individual information requirements and information flow,
information management and utilization, and monitoring and assessment of the status of
complex, dynamic systems is needed (Forsythe and Ashby, 1996). These areas have received
considerable attention from human factors within military, space, aviation, and
traffic domains, but little attention within business contexts.

Of comparable importance to accomplishing the goals of agile manufacturing as product
design and manufacture is the corporate administrative and infrastructure support structure.
Support for the communications and information infrastructure is of particular concern.
System and software compatibility is essential to the seamless flow of product data through
the agile enterprise (Forsythe and Ashby, 1996).With major vendors on update cycles of
6 months or less, this compatibility cannot be maintained without the coordination and
empowerment of administrative and support staff. With agile manufacturing, integration
and networking of information technologies occurs at all levels of the enterprise. As a
consequence, the enterprise must address the support needs of a complex infrastructure
and the numerous human points of failure in supporting such an infrastructure (Haney
et al., 1994). When information does not flow, due to technical or human causes, agility
is lost. For this reason, elimination of human points of failure in infrastructure support is
essential (Forsythe and Ashby, 1996).

3

DESIGN OF ENABLING TECHNOLOGIES

Agile manufacturing is possible primarily as a result of recent and projected technical
innovations. Human factors has an important role to play: first in technology development,
and second in defining technology systems and their usage (Karwowski, 1994).
Use of computer-aided design and manufacturing (CAD and CAM) systems to electronically
represent product design is fundamental to agile manufacturing (Bertoline et al., 1995). Currently, CAD and CAM technologies are advancing at a phenomenal pace, with
alternative vendors in a race to keep up with each other. Unfortunately, users express
frequent discontent with the usability of these systems. Furthermore, capabilities of CAD
and CAM systems are underutilized, partially because they have not been fully integrated
into existing work practices (Forsythe and Ashby, 1996). As CAD and CAM systems, as
well as related product data managers, are implemented at the enterprise level, human
factors should ideally be incorporated into improved user interface designs. At a minimum,
human factors and usability should play a large part in benchmarking and similar
assessments of alternative commercial products.

4

MANAGEMENT OF THE INTRODUCTION AND FIELDING OF NEW
TECHNOLOGIES AND BUSINESS PRACTICES

The above issues are significant, but the most significant challenges posed by agile manufacturing
are sociotechnical (Forsythe and Ashby, 1996). If users are unwilling or reluctant
to accept agile business practices and enabling technologies, agile manufacturing
will fail from the inability to overcome the inertia of traditional, often deeply ingrained
practices. With little exception, businesses that will adopt agile manufacturing over the
next 5 to 10 years are currently designing and manufacturing products, with some success.
Agile manufacturing poses threats to the comfort of managers and line workers
alike. For management, there is a substantial relinquishment of power by the empowerment
of product development teams and the increased openness of information. For the
designer, much control is lost in the collaborative development of designs. At the level of
the line worker, there is increased, often undesired, responsibility in being brought into
the product development decision-making process, not to mention the threats posed by
computerization and automation of fabrication and assembly tasks. All of these threats
occur within an often stressful, fast-paced environment in which cognitively demanding
decision-making tasks replace most mundane, largely undemanding tasks.

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.