Civil Engineering Reference
In-Depth Information
2003) or ISO 13407 (ISO, 1999) or 18529 (ISO, 2000)] to amalgamations of any and all approaches that
suit the needs and purposes of the UCD team. However, despite this considerable variability in the tech-
niques and approaches one might use or the design philosophy one might subscribe to, there are
common threads linking all of these methods and techniques to one common goal. This goal, of
course, is ensuring that the customers', users', and stakeholders' needs and goals are met in the design
of a system or tool.
One of the reasons that the UCD process is such a nebulous topic to summarize is the variability
among approaches and the differences imposed by context disparities. As is well known by all those
who practice UCD, the ideal circumstances for UCD, such as complete user buy-in, unlimited resources,
unlimited time, and unlimited access to users and their work never actually exist in practice. As such,
UCD practitioners often pick their preferred techniques or tools and go about the business of designing
or redesigning work systems for users. This being said, this chapter will discuss the UCD process in fairly
broad terms, focusing more on the general ideas, principles, purposes, and methods or tools of UCD.
As a preface to this discussion, readers should note that UCD practitioners (e.g., ergonomists, human
factors engineers, psychologists, ethnographers, designers, developers, etc.) often deal with a whole host
of constraints, limitations, and obstacles to overcome in real-world domains. This being said, we begin
the discussion of UCD and the process by which practitioners can translate an understanding of users,
their needs, and their work into appropriate and successful system design solutions.
7.3.2 Understanding Users, Their Needs, and Their Work
7.3.2.1 Setting the Stage(s)
As previously discussed, the UCD process can be depicted as a complex, iterative process with two prin-
ciple phases involving the users — the process of understanding the work system, which is used to define
the needs and develop design solutions, and then the testing and evaluation of the formulated design
solutions (see Figure 7.2). The present section will discuss this initial phase of the UCD process, in
which the users, their needs, and their work will be examined in order to develop an understanding
of the goals and requirements to be met by the system, application, or tool, which will culminate in
design solutions.
Figure 7.3 summarizes this initial front-end work of the UCD process including stages of defining the
needs, examining the work system, and then representing the work system and its needs. This infor-
mation and acquired knowledge is then used in the definition and development of system requirements
and specifications, which are used to develop system design alternatives. As discussed, these potential
design solutions (i.e., prototypes) must finally be tested and evaluated (to be discussed later). This
general conception of the UCD process has been the basis for many other models of systems engineering,
which have been neatly summarized in a recent paper by Samaras and Horst (2005).
This section on understanding users, their needs, and their work will focus on the steps of this process
from the work system analysis through the development of system requirements, ending with some dis-
cussion on the translation of these requirements and specifications into design prototypes. It should be
noted that this representation is extremely simplified, as it does not display the iterative nature of the
process or the numerous feedback loops that occur throughout the process to ensure the verification
and validation of the previous steps (see, e.g., Mayhew, 1999, 2003; Samaras and Horst, 2005).
7.3.2.1.1 The Work System
Awork system refers to the collective set of components that define a context under which goals are set and
actions are executed in an attempt to accomplish these goals. Work systems are dynamically evolving net-
works of components operating under a shared set of goals and constraints (although components, they
may not share all goals and constraints). An organization, or learning organization, is itself a work system,
but also comprises of several smaller work systems. The components of the work system consist of all
related facets of the users, stakeholders, environments, tools, artifacts, and facets of the tasks that have
been identified as the means to attain goals. This holistic notion of the user, tools, and context, which
Search WWH ::
Custom Search