In this view we pay attention to people based on psychological approaches (how do humans perceive, learn, remember, think, and feel), and to organization and culture (how do people work together and how does the work situation affect the people's work). Relevant disciplines are cognitive psychology, anthropology, and ethnography. These disciplines provide a theoretical base and associated techniques for collecting information on people's work as well as techniques for assessing newly designed tools and procedures. Designers of the virtual machine or user interface need some insight into the theories and experience with techniques from these disciplines. For example, in specifying what should be represented at a control panel, one may have to consider that less information makes it easier for the user to identify indications of process irregularity (the psychological phenomenon of attention and distraction). On the other hand, if less of the relevant information is displayed, the user may have to remember more, and psychology teaches us that human working memory has a very limited capacity.

Creative and performing artists in very different fields have developed knowledge on how to convey meaning to their public. Graphical artists know how shapes, colors, and spatial arrangements affect the viewer. Consequently, their expertise teaches interface designers how to draw the attention of users to important elements of the interface. For example, colors should be used sparingly in order not to devalue their possible meaning. Well-chosen use of colors helps to show important relations between elements on the screen and supports users searching for relevant structures in information. Design companies nowadays employ graphical artists to participate in the design of representational aspects of user interfaces.

Complex systems often need a representation of complex processes, where several flows of activity influence each other. Examples of this type of work situation are the team monitoring a complex chemical process and the cockpit crew flying an intercontinental passenger airplane. In such situations, users need to understand complex relations over time. The representation of the relevant processes and their relations over time is far from trivial. Representing in an understandable way what is going on and how the relations change over time is only part of the question. Frequently, such complex processes are safety critical, which means that the human supervisor needs to make the right decision very soon after some abnormal phenomenon occurs, so immediate detection of an event as well as immediate understanding of the total complex of states and process details is needed. Experts in theater direction turn out to have knowledge of just this type of situation. This type of interface may be compared with a theater show, where an optimal direction of the action helps to make the audience aware of the complex of intentions of the author and the cast (Laurel, 1990, 1993). Consequently, theater sciences are another source for designing interfaces to complex processes.

Another type of artistic expertise that turns out to be very relevant for interface design is cinematography. Film design has resulted in systematic knowledge of the representation of dynamics and processes over time (May and Barnard, 1995). For example, there are special mechanisms to represent the suggestion of causality between processes and events. If it is possible to graphically represent the causing process with a directional movement, the resulting event or state should be shown in a location that is in the same direction. For example, in an electronic commerce system, buying an object may be represented by dragging that object to a shopping cart. If the direction of this movement is to the right of the screen, the resulting change in the balance should also be shown to the right.

In the same way there are 'laws' for representing continuity in time. In a movie, the representation of a continuing meeting between two partners can best be achieved by ensuring that the camera viewpoints do not cross the line that connects the location points of the two partners. As soon as this line is crossed, the audience will interpret this as a jump in time. This type of expertise helps the design of animated representations of processes and so on.

In general, artists are able to design attractive solutions, to develop a distinctive style for a line of products or for a company, and to relate the design to the professional status of the user. There are, however, tradeoffs to be made. For example, artistic design sometimes conflicts with ergonomics. When strolling through a consumer electronics shop you will find artistic variants of mobile phones, coffee machines, and audio systems where the designer seems to have paid a tribute to artistic shape and color, while making the device less intuitive and less easy to use, from the point of view of fitting the relevant buttons to the size of the human hand. A similar fate may befall a user interface of an information system.

Ergonomics is concerned with the relation between human characteristics and artifacts. Ergonomics develops methods and techniques to allow adaptation between humans and artifacts (whether physical tools, complex systems, organizations, or procedures). In classical ergonomics, the main concern is anthropometrics (statistics of human measures, including muscle power and attributes of human perception). During the past 25 years, cognitive ergonomics developed as a field that focuses mainly on characteristics of human information processing in interaction with information systems. Cognitive ergonomics is increasingly considered to be the core view for managing user interface design. A cognitive ergonomist is frequently found to be the leader of the design team as far as the virtual machine is concerned.

For beginning users, the human-computer conversation is often very embarrassing. The real beginner is a novice in using a specific computer program. He might even be a novice in computer use in general. Sometimes he is also relatively new to the domain of the primary task (the office work for which he will use the PC or the monitoring of the chemical process for which the computer console is the front end). In such a situation, problems quickly reach a level at which an expert is asked for help and the user tends to blame the program or the system for his failure to use the new facility.

There seems to be a straightforward remedy for this dilemma: start by educating the user in the task domain, next teach him everything about the facility, and only thereafter allow him access to the computer. This, however, is only a theoretical possibility. Users will insist on using the computer from the outset, if they intend ever to use it, and introducing a task domain without giving actual experience with the system that is designed for the task is bad education. So the cure must be found in another direction. The designer of the system must start from a detailed 'model of the user' and a 'model of the task'. If he knows that the user is a novice both on the task domain and on the system, he will have to include options for learning both these areas at the same time.

In general, the system designer will try to apply cognitive ergonomic knowledge and adapt the interface to the intended task rather than vice versa. The system should be made transparent (unobtrusive) as far as anything but the intended task is concerned. This should facilitate the user's double task: to delegate tasks to the system and to learn how to interact with the system. However, in many cases this cannot be accomplished completely in one direction and a solution has to be found by adapting the human user to the artifact, i.e. by teaching and training the user or by selecting users that are able to work with the artifacts. Adapting the user to the artifacts requires a strong motive, though. Constraints of available technology, economic aspects, and safety arguments may contribute to a decision in this direction. A mobile phone has only a few keys and a fairly small screen. Instead of designing an 'intuitive' airplane cockpit that would allow an average adult to fly without more than a brief series of lessons, analogous to driving a car, most airlines prefer to thoroughly select and train their pilots.

Cognitive ergonomics developed when information technology started to be applied by people whose expertise was not in the domains of computer science or computer programming. The first ideas in this field were elaborated more or less simultaneously in different parts of the world, and in communities that used different languages, which resulted in several schools with rather specific characteristics. Much of the early work in the US and Canada, for instance, is based on applying cognitive ergonomics to actual design problems. Also, success stories (such as the development of the Xerox Star) were, after the fact, interpreted in terms of ergonomic design concepts (Smith et al., 1982). Carroll (1990) describes this as 'the theory is in the artifact'. Conversely, European work in the field of cognitive ergonomics has concentrated on the development of models: models of computer users, models of human-computer interaction, models of task structures, and so on. By now, these differences are fading away, but a lot of important sources still require some understanding of their cultural background.

The model of human information processing is an example of an external model. We only briefly mention some notions that need to be understood in analyzing human-computer interaction. We focus on human perception, memory, and the processing of information in relation to the input and output of the human in interaction with an outside system. Figure 16.4 depicts this model. In textbooks on psychology, a figure such as this is often adorned with formulae that allow calculation of the speed of processing, the effect of learning, etc.

Figure 16.4. A model of human information processing

In modern cognitive psychology, perception (the input of human information processing) is considered to proceed through a number of phases:

The processing in the later phases is done less and less automatically. People are aware of gestalt formation and combination when any problem arises, for example because of irregularity or exceptional situations such as 'impossible' figures. Recognition leads to conscious perception.

The whole series of phases takes a fraction of a second. It takes more time when a problem occurs because of an unexpected or distorted stimulus. It takes less time when the type of stimulus is familiar. So we may train our computer users to perceive important signals quickly and we may design our signals for easy and quick detection and discrimination. Psychologists and ergonomists know when a signal is easy to detect, what color combinations are slow to be detected, and what sounds are easy to discriminate.

The output of human beings is movement. People make gestures, manipulate tools, speak, or use a combination of these. For computer use, manipulation of keys, mouse or touch-screen, and speaking into microphones are common examples of output. According to modern psychology, all those types of output are monitored by a central processing mechanism in the human. This central executive decides on the meaning of the output (say yes, move the mouse to a certain location, press the return key) but leaves the actual execution to motor processes that, in normal cases, are running 'unattended', i.e. the actual execution is not consciously controlled. Only in case of problems is attention needed. For example, if the location to be pointed to on the screen is in an awkward position, if a key is not functioning properly, or if the room is so noisy that the person cannot properly hear his own spoken command. So we should design for human movements and human measures. It pays to ask an ergonomist about the most ergonomic design of buttons and dials.

The central executive unit of human information processing is modeled as an instance that performs productions of the form if condition then action, where the condition in most cases relates to some perceived input or to some knowledge available from memory. The action is a command to the motor system, with attributes derived from working memory. The central executive unit has a very limited capacity. First of all, only a very small number of processes can be performed simultaneously. Secondly, the knowledge that is needed in testing the condition as well as the knowledge that is processed on behalf of the motor output has to be available in working memory. Most of the time, we may consider the limitations to result in the execution of one process at a time and, consequently, in causing competing processes to be scheduled for sequential execution based on perceived priority. For example, when a driver approaches a crossroads, the talk with his passenger will be temporarily interrupted and only resumed when the driving decisions have been made. The amount of available resources has to be taken into account when designing systems. For example, humans cannot cope with several error messages each of which requires an immediate decision, especially if each requires complex error diagnosis to be performed before reaction is feasible.

Working memory is another relevant concept in the model. Modern psychology presumes there is only one memory structure, long-term memory, that contains knowledge that is permanently stored. Any stimulus that reaches the central executive unit leads to the activation of an element in long-term memory. The activated elements together form the current working memory. The capacity of the set of activated elements is very limited. The average capacity of the human information processor is 5–9 elements. If new elements are activated, other elements lose their activation status and, hence, are no longer immediately available to the central executive. In other words, they are not in working memory any more.

Long-term memory is highly structured. One important type of relation concerns semantic relations between concepts, such as part-of, member-of, and specialization-generalization. In fact, each piece of knowledge can be considered a concept defined by its relation to other elements. Such a piece of knowledge is often called a chunk. It is assumed that working memory has a capacity of 5–9 chunks. An expert in some task domain is someone who has available well-chosen chunks in that domain, so that he is able to expand any chunk into relevant relations, but only when needed for making decisions and deriving an answer to a problem. If not needed, an expert will not expand the chunk that has been triggered by the recognition phase of perception or by the production based on a stimulus. For example, the sequence of digits '85884' could occupy five entries in working memory. However, if it is your mother's telephone number, it is encoded as such and occupies only one entry. When the number has to be dialed, this single entry is expanded to a series of digits again. Entries in working memory can thus be viewed as labels denoting some unit of information, such as a digit, your mother's telephone number, or the routine quicksort. In this way an expert can cope with a situation even with the restrictions on the capacity of working memory.

The structures in long-term memory are the basis for solving problems in a domain and for expertise. When working with a system, people develop a suitable knowledge structure for performing their tasks. If they are able to understand the system as much as they need (we defined this as the virtual machine in Section 16.2), they may develop a coherent and useful structure in long-term memory. As far as this structure can be considered a model of the system, we consider it to be the mental model of the system.

Mental models are structures in long-term memory. They consist of elements and relations between those elements. They represent relevant knowledge structures analogous to physical, organizational, and procedural structures in the world. These mental models become 'instantiated' when activated by an actual need, e.g. when one needs to make a decision related to an element of this knowledge. The activated mental model is, to a certain extent, run or executed in order to predict how the structure in the world that is represented by the mental model would behave in relation to the current situation and in reaction to the possible actions of the person. In the terminology introduced before, mental models are internal models.

When working with complex systems, where part of the relevant structure and processes of the system cannot be perceived by a human being or cannot be completely monitored, a mental model is needed to behave optimally in relation to the system. Hence, people develop mental models of such situations and systems. If the system is a computer system, there are four functions of using the system that require the activation of a mental model:

Mental models as developed by users of a system are always just models. They abstract from aspects the user considers not relevant and they have to be usable for a human information processor with his restricted resources and capacities. Consequently, we observe some general restrictions in the qualities of human mental models of computer systems. Norman (1983) has shown that mental models of systems of the complexity of a computer application have the following general characteristics:

Designers of user interfaces should understand the types of mental structures users tend to develop. There are techniques for acquiring information about an individual user's mental models, as well as about the generic mental structures of groups of users. Psychological techniques can be applied and, in the design of new types of system, it is worthwhile to apply some expert help in assessing the knowledge structures that may be needed for the system, as well as those that may be expected to be developed by users. If the knowledge needed differs from the mental models developed in actual use, there is a problem and designers should ask for expert help before the design results in an implementation that does not accord with the users' models.

A central part of user interface design is the stepwise-refined specification of the system as far as it is relevant for the user. This includes the knowledge the user needs in order to operate the system, the definition of the dialog between user and system, and the functionality that the system provides to the user. All that is specified in the design process is obviously also explicitly modeled, in order to make sure implementation does not result in a system that differs from the one intended. In cognitive ergonomics, all that is modeled about the system as far as relevant to its different sets of users is called the conceptual model of the system (Norman, 1983).

Formal design modeling techniques have been developed in order to communicate in design teams, to document design decisions, to be able to backtrack on specifications, and to calculate the effects of design specifications. Some techniques model the user's knowledge (so-called competence models), others focus on the interaction process (so-called process models), and others do both. Reisner's Psychological BNF (Reisner, 1981) is an example of a competence model. In this model, the set of valid user dialogs is defined using a context-free grammar. Process models may model time aspects of interaction, as in the Keystroke model (Card et al., 1983) which gives performance predictions of low-level user actions. Task Action Grammar (TAG) (Payne and Green, 1989) is an example of a combined model. It allows the calculation of indexes for learning (the time needed to acquire knowledge) and for ease of use (mental load, or the time needed for the user's part of executing a command).

Moran (1981) was one of the first to structure the conceptual model into components, somewhat akin to the Seeheim model. Even though, at that time, command dialogs were the only type of interactive user interface available to the general public, his Command Language Grammar (CLG) still provides a remarkably complete view of the types of design decision to be made during user interface design. Additionally, Moran was the first to state that a conceptual model can be looked upon from three different viewpoints:

Moran distinguishes six levels in the conceptual model, structured in three components. Each level details concepts from a higher level, from the specific point of view of the current level. The formalism that Moran proposes (the actual grammar) would nowadays be replaced by more sophisticated notations, but the architectural concepts show the relevance of analyzing design decisions from different viewpoints and at the same time investigating the relationships between these viewpoints:

Moran's CLG provides a fairly complete specification model for the user interface or UVM. The actual grammar representation is no longer relevant, but the layers and their relations are important, and the design models discussed in the next section cover most of them: task models relate to Moran's task level and the UVM specifications include the semantic level, the communication component, and parts of the spatial layout level.

Viewing design as a structure of interrelated activities, we need a process model. The model we use will be familiar to readers of this book: it is a cyclical process with phases devoted to analysis, specification, and evaluation. Figure 16.5 depicts this process model.

Figure 16.5. A process model for user interface design

Analysis: Since the system to be developed will feature in a task situation, we start with task analysis. We further structure this activity into the development of two models: task model 1, which models the current task situation, and task model 2, which models the task domain of the future situation, where the system to be developed will be used, including changes in the organization of people and work procedures. The relationship between task models 1 and 2 reflects the change in the structure and organization of the task world as caused by the implementation of the system to be developed. As such, the difference is relevant both for the client and the user.

The development of task model 2 from task model 1 uses knowledge of current inadequacies and problems concerning the existing task situation, needs for change as articulated by the clients, and insight into current technological developments. Section 16.6 discusses task analysis.

Specification: The specification of the system to be designed is based on task model 2. It has to be modeled in all details that are relevant to the users, including cooperation technology and user-relevant system structure and network characteristics. Differences between the specification of the new system (the user's virtual machine or UVM) and task model 2 must be considered explicitly and lead to design iteration. Specifying the UVM is elaborated in Section 16.7.

Evaluation: The specification of the new system incurs many design decisions that have to be considered in relation to the system's prospective use. For some design decisions, guidelines and standards might be used as checklists. In other situations, formal evaluation may be applied, using formal modeling tools that provide an indication of the complexity of use or learning effort required. For many design decisions, however, evaluation requires confronting the future user with relevant aspects of the intended system. Some kind of prototyping is a good way to confront the user with the solution proposed. A prototype allows experimentation with selected elements or aspects of the UVM. It enables imitation of (aspects of) the presentation interface, it enables the user to express himself in (fragments of) the interaction language, and it can be used to simulate aspects of the functionality, including organizational and structural characteristics of the intended task structure. We discuss some evaluation techniques in Section 16.8.

Figure 16.5 is similar to Figure 9.1. This is not surprising. The design of an interactive system as discussed in this chapter is very akin to the requirements engineering activity discussed in Chapter 9. The terminology is slightly different and reflects the user-centered stance taken in this chapter. For example, 'elicitation' sounds more passive than 'analysis'. 'Evaluation' entails more than 'validation'; it includes usability testing as well. Finally, we treat the user and the task domain as one entity from which requirements are elicited. In the approach advocated here, the user is observed within the task domain.

The main problem with the design activities discussed in the previous section is that different methods may provide conflicting viewpoints and goals. A psychological focus on individual users and their capacities tends to lead to Taylorism, neglecting the reality of a multitude of goals and methods in any task domain. On the other hand, sociological and ethnographical approaches towards groupware design tend to omit analysis of individual knowledge and needs. Still, both extremes provide unique contributions.

In order to design for people, we have to take into account both sides of the coin: the individual users and clients of the system, and the structure and organization of the group for which the system is intended. We need to know the individuals' knowledge and views on the task, on applying the technology, and the relation between using technology and task-relevant user characteristics (expertise, knowledge, and skills). With respect to the group, we need to know its structure and dynamics, the phenomenon of 'group knowledge' and work practice and culture. These aspects are needed in order to acquire insight into both existing and projected task situations where (new) cooperation technology is introduced. Both types of insight are also needed in relation to design decisions, for functionality and for the user interface. Consequently, in prototyping and field-testing, we need insight into the acceptance and use by individuals and the effect of the new design on group processes and complex task dynamics.

For example, in a traditional bank setting, the client and the bank employee are on different sides of a counter. The bank employee is probably using a computer, but the client cannot see the screen, and does not know what the clerk is doing. In a service-oriented bank setting, the clerk and client may be looking at the screen together. They are together searching for a solution to the client's question. This overturns the existing culture of the bank and an ethnographer may be asked to observe what this new setup brings about.

The general framework for our approach to user interface design is depicted in Figure 16.6. It is a refinement of Figure 16.5, emphasizing the specialties involved in carrying out different activities. Task model 1 is based on knowledge of single users (psychological variables, task-related variables, knowledge, and skills) and on complex phenomena in the task situation (roles, official and actual procedures, variation in strategies, and variation in the application of procedures). The integration of this insight in a model often does not provide a single (or a single best) decomposition of tasks and a unique structure of relationships between people, activities, and environments. The model often shows alternative ways to perform a certain task, role-specific and situation-specific methods and procedures, and a variety of alternative assignments of subtasks to people. For example, the joint problem-solving approach to the bank counter, sketched out above, cannot be applied to the drive-in counter of the bank. The drive-in counter requires a different approach and a different user interface.

From this, and because of client requirements, compromises often have to be made in defining task model 2, the new task situation for which the technology has to be designed. This process includes the interpretation of problems in the current task situation, negotiation with the client regarding his conditions, and the resources available for design (including both financial impacts and time constraints). Ultimately, decisions have to be made about complex aspects, such as re-arranging the balance of power and the possibilities for users in various roles to exercise control.

Figure 16.6. Structure of design team activities

Again, when detailed design decisions are being considered, early evaluation needs to include analytical methods (formal evaluation and cognitive walkthrough techniques) in combination with usability testing where users in different roles are studied both in the sense of traditional individual measures and in the sense of ethnographic interaction analysis.

Classical HCI features a variety of notions regarding task analysis. Task analysis can mean different activities:

Many HCI task analysis methods combine more than one of these activities and relate them to actual design stages. Others do not bother about the distinction. For example, goals, operators, methods, and selection rules (GOMS, see (Card et al., 1983)) can be applied for any or a combination of the above activities.

In many cases. the design of a new system is triggered by an existing task situation. Either the current way of performing tasks is not considered optimal, or the availability of new technology is expected to allow an improvement over current methods. A systematic analysis of the current situation may help formulate requirements and allow later evaluation of the design. In all cases where a current version of the task situation exists, it pays to model this. Task models of this type pretend to describe the situation as it can be found in real life, by asking or observing people who know the situation (see (Johnson, 1989)). Task model 1 is often considered to be generic, indicating the belief that different expert users have at their disposal basically the same task knowledge.

Many design methods in HCI that start with task modeling are structured in a number of phases. After describing a current situation (in task model 1), the method requires a re-design of the task structure in order to include technological solutions for problems and technological answers to requirements. Task model 2 is in general formulated and structured in the same way as task model 1. However, it is not considered a descriptive model of users' knowledge, though in some cases it may be applied as a prescriptive model of the knowledge an expert user of the new technology should possess.

A third type of modeling activity focuses on the technology to be designed. This may be considered part of task model 2. However, some HCI approaches distinguish specific design activities which focus on the technology (e.g. see (Tauber, 1990)). This part of the design activity is focused on a detailed description of the system as far as it is of direct relevance to the end user, i.e. the UVM. We separate the design of the UVM from the design of the new task situation as a whole, mainly because the UVM models the detailed solution in terms of technology, whereas task model 2 focuses on the task structure and work organization. In actual design, iteration is needed between the specification of these two models. This should be an explicit activity, making the implications of each obvious in its consequences for the other. Specifying the UVM is treated in more detail in Section 16.7.

HCI task models represent a restricted point of view. All HCI task modeling is rather narrowly focused, mainly considering individual people's tasks. Most HCI approaches are based on cognitive psychology. Johnson (1989) refers to knowledge structures in long-term memory. Tauber (1990) refers to 'knowledge of competent users'. HCI approaches focus on the knowledge of individuals who are knowledgeable or expert in the task domain, whether this domain already exists (task model 1) or still has to be re-structured by introducing new technology (task model 2 and the UVM).

As a consequence of their origin, HCI task models seldom provide an insight into complex organizational aspects, situational conditions for task performance, or complex relationships between tasks of individuals with different roles. Business processes and business goals (such as the service focus of a modern bank counter, which may be found in a business reengineering project) are seldom part of the knowledge of individual workers and, consequently, are seldom related to the goals and processes found in HCI task modeling.

Task analysis assumes there are tasks to analyze. Many current Web applications, though, are information-centric. The value of such systems is in the information they provide (Wikipedia, Amazon.com, and so on), and to a much lesser extent in the tasks they offer to the user. The key operation is searching. The developers seek to make searching simpler by organizing the information in a logical way, by providing navigation schemes, and so on (Nerurkar, 2001). The challenge for such applications is to induce the users to provide ever more information. This is another example of crowdsourcing, as already mentioned in Chapter 1.

CSCW work stresses the importance of situational aspects, group phenomena and organizational structure and procedures. Shapiro (1996) even goes so far as to state that HCI has failed in the case of task analysis for cooperative work situations, since generic individual knowledge of the total complex task domain does not exist. The CSCW literature strongly advocates ethnographic methods.

Ethnographers study a task domain (or community of practice) by becoming a participant observer, if possible with the status of an apprentice. The ethnographer observes the world 'through the eyes of the aboriginal' and at the same time is aware of his status as an outside observer whose final goal is to understand and describe for a certain purpose and a certain audience (in the case of CSCW, a design project). Ethnographers start their observation purposely without a conceptual framework regarding characteristics of task knowledge, but, instead, may choose to focus on activities, environments, people, or objects. The choice of focus is itself based on prior ethnographic observations, which illustrates the bootstrapping character of knowledge elicitation in ethno-methodology. Methods of data collection nowadays start with video recordings of relevant phenomena (the relevance of which, again, can only be inferred from prior observation) followed by systematic transaction analysis, where inter-observer agreement serves to improve the reliability of interpretation. Knowledge of individual workers in the task domain may be collected as far as it seems to be relevant, but it is in no sense a priori considered the main source and is never considered indicative of generic task knowledge.

The ethnographic approach is unique in its attention to all relevant phenomena in the task domain that cannot be verbalized explicitly by (all) experts (see (Nardi, 1995)). The approach attends to knowledge and intentions that are specific for some actors only, to conflicting goals, to cultural aspects that are not perceived by the actors in the culture, to temporal changes in beliefs, to situational factors that are triggers or conditions for strategies, and to non-physical objects such as messages, stories, signatures and symbols, of which the actors may not be aware while interacting.

Ethno-methodology covers the methods of collecting information that might serve as a basis for developing task model 1 (and no more than this since ethno-methodology only covers information on the current state of a task domain). However, the methodology for the collection of data and its structuring into a complete task domain description is often rather special and difficult to follow in detail. The general impression is that CSCW design methods skip the explicit construction of task models 1 and 2 and, after collecting sufficient information on the community of practice, immediately embark on specifying the UVM, based on deep knowledge of the current task situation that is not formalized. This may cause two types of problem. Firstly, the relationship between specifications for design and analysis of the current task world might depend more on intuition than on systematic design decisions. Secondly, skipping the development of task model 2 may lead to conservatism with respect to organizational and structural aspects of the work for which a system is to be (re)designed.

Collecting task knowledge to analyze the current situation of a complex system has to start by identifying the relevant knowledge sources. In this respect, we refer to a framework derived from (Jordan, 1996), see Figure 16.7. The two dimensions of this framework denote where the knowledge resides and how it can be communicated. For example, A stands for the explicit knowledge of an individual, while D stands for the implicit knowledge of a group.

Figure 16.7. Dimensions of knowledge for complex task domains

Jordan's framework has been applied in actual design processes for large industrial and government interactive systems. We may expand the two factors distinguished from dichotomies to continuous dimensions to obtain a two-dimensional framework for analyzing the relevant sources of knowledge in the context of use. This framework provides a map of knowledge sources that helps us to identify the different techniques that we might need in order to collect information and structure this information into a model of the task world.

To gather task knowledge in cell A, psychological methods may be used: interviews, questionnaires, think-aloud protocols, and (single-person-oriented) observations. For knowledge in cell B, observations of task behavior must be complemented by hermeneutic methods to interpret mental representations (see (Veer, 1990)). For the knowledge referred to in cell C, the obvious methods concern the study of artifacts such as documents and archives. In fact all these methods are to be found in classical HCI task analysis approaches and, for that matter, the requirements elicitation techniques discussed in Chapter 9.

The knowledge indicated in cell D is unique in that it requires ethnographic methods such as interaction analysis. Moreover, this knowledge may be in conflict with what can be learned from the other sources. First of all, explicit individual knowledge often turns out to be abstract with respect to observable behavior and to ignore the situation in which task behavior is exhibited. Secondly, explicit group knowledge such as expressed in official rules and time schedules is often in conflict with actual group behavior, and for good reasons. Official procedures do not always work in practice and the literal application of them is sometimes used as a political weapon in labor conflicts, or as a legal alternative to a strike. In all cases of discrepancy between sources of task knowledge, ethnographic methods will reveal unique and relevant additional information that has to be explicitly represented in task model 1.

The allocation of methods to knowledge sources should not be taken too strictly. The knowledge sources often cannot be located completely in single cells of Jordan's conceptual map. The main conclusion is that we need different methods in a complementary sense, as we need information from different knowledge sources.

Groupware Task Analysis (GTA) is an attempt to integrate the merits from the most important classical HCI approaches with the ethnographic methods applied for CSCW (see (Veer and van Welie, 2003)). GTA contains a collection of concepts and their relations (a conceptual framework) that allows analysis and representation of all relevant notions regarding human work and task situations as dealt with in the different theories.

The framework is intended to structure task models 1 and 2, and, hence, to guide the choice of techniques for information collection in the case of task model 1. For task model 2, design decisions have to be made, based on problems and conflicts that are present in task model 1 and the requirement specification.

Task models for complex situations are composed of different aspects. Each describes the task world from a different viewpoint and each relates to the others. The three viewpoints are:

The dialog in modern user interfaces is frequently a combination of several dialog styles, such as command language, menu choice, answering of questions generated by the interface, fill-in-the-blanks forms, and direct manipulation of interface objects. For an overview of the various styles, and options for using them in different situations depending on task and user characteristic, see (Mayhew, 1992) and (Shneiderman and Plaisant, 2004). Dialog styles may often be seen as implementations of different dialog metaphors:

It makes sense to relate the metaphor to the actual task domain. For example, a space can be specified as a desktop, or a virtual library, depending on whether the task domain concerns the management of documents or a search for objects.

In specifying the dialog further, the syntax of the interaction has to be specified in detail, including the sequence of user actions. For example, in both Windows and the Macintosh interface, the user has to indicate the object first and then the operation. The reverse is true in the UNIX command language. Also, the lexicon has to be specified. This includes deciding on the verbal labels for objects and operations, the iconic representations, the gestures (such as a cross or a series of connected up and down strokes to indicate rubbing out on a drawing pad), and sounds. The lexicon includes both the symbols that the user can use in communicating with the machine and the symbols the machine will output to the user.

There are various modeling techniques for specifying the dialog. An example dialog specification technique is User Action Notation (UAN, see (Hix and Hartson, 1993)) which combines the specification of functionality with dialog details. UAN is relatively easy to use, especially since the actual formalism may to a large extent be tailored to the designer's needs without losing the benefits of a formal model. UAN provides a representation of the specification of the UVM with separate columns to specify user actions, interface actions, interface states, and connections to underlying system events. Each of these columns is filled in with the amount of detail the designer needs at a certain moment. Later on, any item may be refined. For example, the designer may specify a user action enter pincode and later on specify a detailed interaction enter pincode where he elaborates details of inputting each digit, erasing a wrong keystroke, and what the interface should show on the screen at each point in time.

This aspect of the UVM contains the details of the interface that determine the perceptible aspects. The lexicon indicated in the previous section includes all interface elements. Their representation concerns their shape, color, contrast, pitch, loudness, size, etc. Representation also concerns all aspects of screen design, such as the size of windows, the speed of movement displayed, and the timbre of generated sounds. The representation aspect may need the assistance of artists or at least specialists who understand the laws of graphical representation, sound representation, and animation.

This part of design is the one for which no general formal representation models have been developed. Sketches, video clips, and verbal descriptions of what one intends to have represented are commonly used, and frequent communication between the designer and the implementor is needed. Artists may have very useful ideas but may propose very convincing solutions that change the essence of the intended specification.

During the early development of task model 2 there is not enough detail to develop a prototype. However, scenarios can be developed regarding the future task world, and it can be modeled with the help of formalisms. Both scenarios and formalisms offer opportunities to apply evaluation techniques.

In scenario-based evaluation, scenarios will be developed concerning those parts of task model 2 that concern a change in comparison to the current situation. In this phase of the design, it is worthwhile to represent not only the new use of technology, but also the situational aspects of this use and the organizational consequences. Developing a scenario means describing a process of using the intended system in an actual situation and organizational setting. The scenario may be described verbally, but a video representation is often used because that may show more relevant situational details, even though the technology may be represented in a way that reveals no details (for example, a laptop may be represented by a sheet of paper if the details of the screens have not yet been decided).

In order to evaluate a scenario, a 'claims analysis' can be performed. Apart from the designer and the constructor of the scenario, (future) users, representatives of the client, and other relevant stakeholders may participate in the claims analysis. It often makes sense not to choose only representatives who have a positive attitude towards the intended change but also to include people who are afraid of the future developments or who have a pronounced opinion on the possible negative effects of future implementation. For each aspect of the task delegation to the new system that is an explicit change from the current system, the participants of the claims analysis try to identify:

Another way to evaluate a scenario is to ask a group of stakeholders to act out the written scenario and videotape the performance, possibly collecting several takes where people change roles and where the non-believers, in particular, get a chance to show where things may go wrong. Analyses of this type will show not only the possible success of the envisioned changes but also the potential problems. The latter, in particular, are the basis for reconsidering decisions and for developing measures to counteract unwanted side-effects. The scenarios that are acted by stakeholders, in particular, often reveal possible changes in the design that may provide a breakthrough.

Formal evaluation techniques allows specific questions to be answered. For example, hierarchical task analysis (HTA) (Kirwan and Ainsworth, 1992) describes the task domain as a hierarchical structure of tasks and subtasks with a complete representation of the procedural structures of the decomposition. HTA formal evaluation may consider the length of a sequence of subtasks, given the relevant conditions. The same type of formalism allows an evaluation of possible modular procedures (similar subtrees that occur in different places and the aspects of consistency between their execution), which is indicative of the amount of learning involved for understanding the new task domain.

As soon as details of the UVM have been specified, other representations may be used for evaluation, even though it may still be worthwhile to analyze scenarios. At this stage in the design, scenarios are often elaborated and executed with the help of mock-up representations or simulations of the intended system, especially if hardware aspects in relation to the physical work conditions are expected to matter. The simulations concern the size, weight, and perceptible aspects of the intended UVM, even if the interactive aspects have not yet been specified. Many evaluation techniques from classical ergonomics may be applied as well (Corlett and Clark, 1995).

Formal evaluation will certainly play an important role for the UVM. Many formalisms have been developed with certain usability aspects explicitly in mind. For example, TAG allows us to measure ease of learning and use by indexing the complexity of rules and the number of features to be considered during each command to the machine; UAN representations allow systematic reasoning about dialog specification details.

Detailed specification of the UVM permits other evaluation techniques as well, in particular heuristic evaluation and cognitive walkthrough. In both cases, it is useful to employ experts in user interface design who have not been part of the team that developed the specification. Experienced designers know the criteria applied in these techniques and will have considered them during their decisions. Only somebody for whom the design is new can have an unbiased view concerning these criteria. A last type of evaluation technique, user testing and observation, requires future users to be involved and a working prototype. Obviously, a prototype may also be the basis for heuristic evaluation and a cognitive walkthrough.

Heuristic evaluation is based on some definition of usability. Usability is a complex of aspects such as ease of use, ease of learning, ease of recall after a period of not using a system (known as re-learnability), affection, help, likeability, etc. Approaches toward heuristic evaluation provide checklists of characteristics of the user interface or UVM that describe the different usability aspects. Such a checklist may also be applied as a guideline for making design decisions. Checklists exist in different forms, and often include a technique for calculating usability indexes. Each item may be checked when applicable and, additionally, each item that is diagnosed as non-optimal may give rise to design changes. Example items from such a checklist are (Shneiderman and Plaisant, 2004; Nielsen, 1993):

Items from such a checklist should be used with care, though. Design involves tradeoffs between conflicting goals. Consider for example the two function-key layouts in Figure 16.8. Interface designers might prefer the star as the best design. It is a symmetric design, consistent with directional indicators on a compass. Yet, studies have shown that the inverted 'T' is the most useful configuration. With the index finger on the cursor-left key and the ring finger on the cursor-right key, the middle finger can efficiently cover the cursor-up and cursor-down keys. Designers of computer games seem to have known this for quite a while.

Figure 16.8. Two possible cursor key arrangements

Cognitive walkthroughs focus solely on the cognitive aspects of the dialog. The technique can be applied early in the specification phase and it helps to detect failures that would otherwise make the system incomprehensible for users. Like heuristic evaluation, it requires only a small number of expert colleagues who are confronted with the specification of the dialog and the content of the representation. Screen design need not have finished yet, but the information representation (wording, icons) of the screen must be known. The technique requires a specification of scenarios of normal, faultless dialog examples. A scenario might for example read as follows: 'when checking in you have to put your credit card in the slot; the machine will ask you to enter your pin code; you type ...'. Based on a specification of this type, the start state is described to the evaluator, along with all information on the task as the user would know it, and the background of the user (education and systems experience). The evaluator is asked to answer a small set of questions about the next move. After these have been answered, the intended move is described with the resulting state of the interface, after which the evaluator is again asked the same set of questions.

An example of such a set of questions is:

Techniques such as this quickly expose any invalid expectations of user knowledge and understanding and any lack of relevant information at the interface. Additionally, they show inconsistencies in the interface information as well as inconsistencies in dialog conventions.

The proof of the pudding is in the eating. An evaluation should, at some point, be carried out with real users. As soon as a mock-up or simulation is available, users can be asked to perform tasks. We are then asking users to 'play a scenario' even if we do not mention this explicitly. As soon as details of the dialog have been established, a more interactive type of testing is possible.

Evaluation by the user is often based on a prototype implementation of the system. In early phases of detail design, the prototype will often not represent the total UVM. A single aspect of the task to be delegated, one instance of the dialog and representation with hardly any real functionality available, may be enough to detect problems early on. Several types of user testing may be done. Users may be provided with tasks or allowed to explore. Observations during the interaction, complemented with subsequent discussions with the user, may reveal problems and misunderstandings. In addition, user performance may be measured, for example, the time to complete a task or the frequency of errors. Users may be asked for their subjective understanding of the system; standardized measurement techniques are commercially available, focusing on subjective learnability, ease of use, and mental load.

ISO 9241 (1996) defines usability in terms of efficiency, effectiveness, and satisfaction. Usability evaluation of prototypes (and systems) is usually based on more specific definitions of usability characteristics, such as those defined in (Shneiderman and Plaisant, 2004; Nielsen, 1993). Figure 16.9 gives an overview of these usability characteristics. They have an almost one-to-one correspondence with the user interface quality factors as listed in the introduction to this chapter. For each of the usability characteristics, a number of (indirect) metrics exist. These metrics are gathered by observing users at work and by asking subjective questions.

Figure 16.9. Usability characteristics according to ISO 9241, Shneiderman and Plaisant (2004) and Nielsen (1993)