The UCD approach just looks beyond principles of physical design — beyond traditional ergonomics
— to consider more fundamental issues such as the structure of information presented, the degree of process automation, implications of skill transfer and retention, and training requirements. If operators and supervisors are involved only at the later phases of the design process, then the final product may be difficult to learn, and incompatible with the existing well-established working practices, while also trig- gering increases in vigilance tasks and diminished user acceptance and trust (Kontogiannis and Embrey, 1997).
The result is a set of integrated techniques, which combine users’ assertions with observations across several levels of the organization, and several classes of users and stakeholders. Damodaran (1996) has suggested a well-defined taxonomy of the roles of individuals involved in the design process and the identification and selection of the most representative users from the organization. In fact, users should be identified at several levels from within an organization, ranging from end users to middle- and top-level management. This focus on all stakeholders is because the outcomes of technical design decisions may have profound implications on job design, and subsequently working life (Damodaran, 1996; Damodaran et al., 1980).
7.2.2 Summary
This chapter will focus on the inclusion of users at the two phases in the design process during which user feedback can have the greatest influence on its eventual success. This includes, as illustrated by Figure 7.2, understanding the work system and the testing and evaluation of designs and prototypes. The integration of specifications into tangible designs will briefly be touched on, as a more complete explanation is out of the scope of a manuscript of this length. The actual design production step is best learnt through practice and case studies of the experiences of others. In a study of the efficacy of novice designers to UCD, Sugar (2001) investigated the challenges that novice designers face in the application of UCD principles and guidelines. These designers were observed to have incomplete mental models of the translation of requirements into creative design solutions and tended to focus on overt observations of user needs.
In this chapter, readers will be provided with guidance on how to incorporate users into and leverage their knowledge and insight during the UCD process. UCD is partly a structured methodology and partly a skillful improvization. Readers should recognize the importance of practical experience and reviewing actual design case studies, both grounded in empirically validated guidelines and underlying philos- ophies of UCD in order to achieve effective designs. In UCD, those designing the system are responsible for: (1) facilitating the task or work for the user; (2) ensuring that the user can use the product as it was intended to be; and (3) making certain that the training and learning required to use the product is minimized.
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 systemrefers 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 shareallgoals 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
User-Centered Design of Information Technology 7-9
implicate the work system stems from contextual computing, HCI, and cognitive engineering (Dourish, 2004; Kirlik, 1998; Oulasvirta, 2004;
Sears et al., 2003).
The work system, as it relates to UCD, involves:
(1) the human users and all of their capabilities, limitations, demographics, knowledge, experience, and skills; (2) the actual work and all related issues including allocation of functions, roles, responsibilities, complexity, and sequences; (3) the work tools and all related issues including hard- ware attributes, physical device attributes, nontech- nical artifacts; and (4) the work context and all related issues including organizational needs, environmental variables, social interaction, and communication.
In the context of UCD we must draw an import- ant distinction between a work system versus a system.While awork systemrefers to the compre- hensive view of components operating under similar constraints to achieve shared goals, a system is often used in UCD in reference to a general tool, application, or interface that the user interacts with to complete a task. Systems are also commonly referred to as tools, designs, interfaces, and ITs. In other words, the work system is what is being examined, while the system is what is being designed and developed.
Noyes and Barber (1999) present a similar view of the work system, within the context of the UCD of systems and tools.
This clarification of the work system is important, because it is the focus of UCD. The work system comprises of the users, their needs, and their work. It is the focus of the front-end work in the UCD process, which provides the boundaries and inspirations for the designs and system prototypes. As can be seen in Figure 7.3, the resulting outcome of the front-end work is a set of system requirements, which will ultimately serve as the guide for system design. This process, sometimes referred to as require- ments engineering (RE) (Kotonya and Sommerville, 1998; Nuseibeh and Easterbrook, 2000; Sommerville and Sawyer, 1997), is the manifestation of users, their needs, and their work. The following discussion will be dedicated to the process of RE and the common UCD methods and techniques used to collect and represented the user-centered data that will inform system design.
7.3.2.1.2 RE: The Overall Goal
Before getting into the details of the methods and techniques used, the underlying purpose of this process should be discussed. Whether taking a linear or iterative approach, or starting from a clean slate or a well- established work system, the process of UCD generally begins with the examination and formulation of the scope, nature, and needs of the work system. This process has been commonly referred to as the engineering, analysis, gathering, or specification of requirements. RE is the process of discovering, doc- umenting, and maintaining a set of requirements, or descriptions of system properties, attributes, beha- viors, or constraints, for a (computer-based) work system (Kotonya and Sommerville, 1998; Sommerville and Sawyer, 1997).
RE is the process of eliciting, analyzing, defining, documenting, validating, and managing require- ments for a system (Kotonya and Sommerville, 1998; Sommerville and Sawyer, 1997). This process FIGURE 7.3 The process of translating an understanding of the work system into design. This figure is expanded from Figure 7.2 to fully illustrate more of the initial steps in the overall UCD process.
7-10 Fundamentals and Assessment Tools For Occupational Ergonomics
involves a number of activities, such as discovering the purpose for which the system is intended, identifying the system stakeholders and their needs, and (finally) translating and documenting these needs into a form that can be communicated, validated, and implemented (Nuseibeh and Easterbrook, 2000). RE is, arguably the seminal activity in the UCD process, because it represents the initial step in involving the users (and their needs) into the design process and, ultimately, serves as the blueprints for the designs that are to be tested and evaluated in later phases of the system develop- ment process.
As alluded to, RE is a process, meaning that it is (necessarily) somewhat ill-defined, fluid, and complex.
This process involves any number of activities, ranging from simply defining the purpose of the system or goals of the customer or organization to diligently observing and modeling the actual work of the end- users. As all of the experts agree, there is no best way of conducting the RE process, just as there is no single or best way to define and document the requirements that result from the process.
While there are considerable issues regarding the practice of RE, such as requirements validation, change management, documentation styles, and traceability, this discussion falls outside of the scope of this chapter. Readers can be directed to any number of books and reports that deal with these delicate issues (e.g., Christel and Kang, 1992; Ransley, 2003; Rosenberg, 1999; Young, 2001). Some of these issues, such as insuring that representative users are chosen, will be discussed in relation to the activities at the various stages depicted in Figure 7.3. There are a number of good texts detailing the process of and con- siderations associated with the RE process, including those by Wiegers (2003), Robertson and Robertson (1999), and Young (2001, 2004).
The real purpose of the RE process is to minimize problems resulting from costly and destructive mis- understandings or misinterpretation between the stakeholders or users and the design and development team (Ransley, 2003; Sommerville and Sawyer, 1997). The RE process is able to limit these types of pro- blems by utilizing systematic and structured process from the start of the system development process before making definitive judgments or assumptions about design alternatives or work system needs.
Overall, RE is able to provide a better understanding of the system to be developed, help communication between users and the design and development team, minimize risk and maximize acceptance through good structuring, clear language, clear linkages between requirements and documented work system needs, and direct user involvement.
In more concrete terms, RE is the process of translating knowledge of users, their needs, and their work, and so on into specific, tangible requirements of the system to be designed and developed. As a simple summary, the RE process is utilized to produce system requirements in such a way that represen- tative, accurate, and complete work system data are provided in a feasible, affordable, and ethical manner.
We will now turn to the primary component or outcome of the RE process — the system and design requirements.
7.3.2.1.3 The Nature and Importance of Requirements
As suggested by popular models of design lifecycles [e.g., the usability engineering lifecycle (Mayhew, 1999, 2003)], requirements are defined during the early stages of system development, prior to any efforts in the design of system prototypes or implementation efforts. Requirements are generally described as descriptions or statements of system services, functions, properties, attributes, or constraints typically detailing how a system should behave within its context of use to help perform work (Kotonya and Sommerville, 1998; Nuseibeh and Easterbrook, 2000; Ransley, 2003; Sommerville and Sawyer, 1997).
Requirements are typically a mixture of some problem information, statements of system behavior and properties, and design and manufacturing constraints (Sommerville and Sawyer, 1997).
There is no best way to generate or communicate requirements. The process of creating requirements from the collected and modeled data of the work system is nebulous to characterize, often requiring con- siderable interpretation, rationalization, and translation of the raw data into concise, accurate, and com- municable ideas. There is also no set way to communicate system requirements. The requirements document, the comprehensive list of requirements, is the communication tool between the users and stakeholders, the UCD team, and the systems engineers and developers. Depending on the audience,
User-Centered Design of Information Technology 7-11
organizational culture, and work domain (e.g., medicine versus commercial logistics versus fast-food), the nature of the requirements and the language used to express them can vary considerably.
Regardless of the method of creation or language, there are some established criteria for system requirements. Good system requirements possess the qualities or properties of specificity, feasibility, testability, clarity, comprehensiveness, consistency, exclusivity, traceability, accuracy, and so on (Ransley, 2003). The properties comprise the basis for good systems requirements as they specify the guidelines to ensure that the requirements are appropriate and effective for guiding UCD. It should also be mentioned that there are also a number of different types of requirements.
Design requirements can range from general requirements, which set out what the system should do in broad terms, to performance requirements, which specify a minimum acceptable performance level of the system (Kotonya and Sommerville, 1998; Ransley, 2003; Sommerville and Sawyer, 1997). Traditionally, system requirements govern functional capabilities rather than nonfunctional requirements such as issues of human cognition and capabilities, usability, individual differences and preferences, and social and organ- izational concerns (see Dix et al., 1998, for a good overview of this philosophy and appropriate techniques).
Not surprisingly, there is little consensus on the number and nomenclature regarding the classification of requirements. Generally speaking, there are two major classes of requirements: (1) functional require- ments, which outline the things that the system must do (e.g., services and functionality to provide); and (2) nonfunctional requirements, which outline the properties that the system must have (e.g., usability, efficiency, reliability, etc.) (Robertson and Robertson, 1999; Young, 2004). Table 7.2 outlines some of these broad classes of system requirements. For a more comprehensive examination of requirement classification and delineation, readers can refer to texts by Young (2001, 2004) and Kovitz (1998).
As can be seen, requirements represent the collective set of issues, problems, needs, and constraints of the work system that need to be met by the new design or tool. With the concepts of the RE process and the requirements established, it is appropriate to discuss the specific activities of this process and how to equate it to requirements. These activities effectively supply the data on which the requirements are constructed.
7.3.2.1.4 UCD Methods and Techniques
The RE process consists of two basic classes of activities: (1) those that focus primarily on collecting data on the work system and (2) those that focus primarily on representing this data. The former approaches can be considered as requirement elicitation techniques, while the latter can be considered as require- ments analysis and modeling techniques (Nuseibeh and Easterbrook, 2000).
TABLE 7.2 Summary of the Different Classes of System Requirements
Requirement Class General Description
User requirements Based on the facets of the users — often in terms of user expertise, training needs, limitations, and capabilities Task requirements Based on the facets of the work — often in terms of artifact
requirements and sequence of steps
Work environment requirements Based on the facets of the nature of the work context, based on environmental conditions such as communication needs and physical constraints
Organizational requirements Based on the facets of the organization including cultural, technological, and legal needs and standards
Usability requirements Based on the usability needs and guidelines to be met by the design — often in terms of efficiency, effectiveness, satisfaction, learnability, and acceptability
Functional requirements Based on the services and functions provided by the design — often in terms of tasks, actions, and activities that the system must be able to accomplish or support the user in
accomplishing (sometimes accounted for under user requirements)
Performance requirements Based on the expectations of system functionality — often in terms of timeliness, reliability, and accuracy
7-12 Fundamentals and Assessment Tools For Occupational Ergonomics
While this division of approaches is not absolute, it does distinguish that there are clear differences between these two types of approaches. For example, elicitation techniques are generally (arguably) quick preliminary techniques, which involve direct interaction with the users to yield rough data that often requires considerable interpretation, refinement, and validation. On the other hand, analysis and modeling techniques are often more extensive follow-up efforts that are used to represent this rough data in a manner that can be more easily communicated and interpreted and applied. For these reasons, the following discussion will consider elicitation techniques (Stage 2: Examining the work system) and analysis and modeling techniques (Stage 3: Representing the work system and its needs) as independent stages in the RE process as shown in Figure 7.3.
Before talking about these approaches and techniques in greater detail, Table 7.3 outlines many of the popular techniques of requirements elicitation and analysis/modeling commonly employed by UCD professionals. For greater detail on these (and other) methods and techniques, readers should examine some of the literature (e.g., Beyer and Holtzblatt, 1998; Maguire, 2001; Sommerville and Sawyer, 1997) and Websites (http://www.usabilitynet.org; http://usability.jameshom.com/index.htm) that provide detailed insight into different UCD techniques.
7.3.2.1.5 Selection of UCD Methods and Techniques
It is well-known that the UCD approach taken and the methods and tools chosen heavily depend on the constraints of a given project-time, money, staffing, and accessibility to users. Readers will find that even expert practitioners adopt their own unique combination of the techniques, as suits the needs and work within the constraints of a project. In a recent article, Marcus (2005) summarized the factors that mostly affect collection of UCD techniques used. These factors include: (1) availability of testing labs and equip- ment; (2) availability of usability professionals; (3) availability of users; (4) budget; and (5) calendar schedule.
A survey of UCD professionals showed that the cost-benefit tradeoff was instrumental in the consider- ation of which UCD method, if any would be implemented in a given design process (Mao et al., 2001).
TABLE 7.3 Common Requirements Elicitation and Requirements Analysis and Modeling Techniques
Requirements Elicitation Requirements Analysis and Modeling
RE stage
Stage 2: Examining the work system Stage 3: Representing the work system and its needs Approach summary
Gathering or capturing system requirements through direct observation or interaction with stakeholders or end-users
Defining system requirements through the development of models based on the data collected using elicitation techniques and documentation
Characteristics
Ethnographic in nature Analytical in nature
Direct interaction with users Direct involvement with data
Results in rough data Refined representations of users, needs and tasks Relatively quick and simple Time and resource intensive
Requires more interpretation Requires less interpretation Preliminary activities
Common techniques
Surveys and questionnaires Use cases/scenarios
Interviews Visioning
Observation/ethnography Personas/user profiles
Contextual inquiry/user interview Error and critical incident analysis
Focus groups and brainstorming Affinity diagramming
Think aloud Work modeling
Laddering and card sorting Decision/action diagrams Documentation and product review Cognitive work/task analysis
User-Centered Design of Information Technology 7-13