Previous | Table of Contents | Next |
3.1. CONTEXT AND REQUIREMENTS ANALYSIS
The Context and Requirements (C & R) analysis includes interviewing the customer, who is seldom a user. A structure is followed that ensures that the systems effects on the enterprise (business, humanitarian, and organizational) and the systems qualities (information, technical, and what we call character) are clearly described. Often the customer has not realized that the system will affect peoples way of working. The customer has seldom defined the desired effects of the system, other than those related to automation, efficiency, or costs. Effects on business relations and individual values, work load, and stress are often unanticipated. The goal of the C & R analysis is to explore issues that might have been overlooked previously.
We use the term customer to refer to the person who is responsible for those in the organization who will use the system. Sometimes this person has transferred the responsibility to a project leader or to someone else in the organization, but still it is that person who is the recipient of our design work. Among the issues addressed by the C & R analysis are the following:
The C & R analysis can also include interviewing and observing users while they are conducting their work, following a structure that ensures the descriptions of:
The results of the interviews are described in a report delivered to the customer, the users, and the interaction designers. Distributing the report allows both the users and the customer to be involved in the design process and provides them an opportunity to react to any misunderstandings. C & R analysis, when interviewing and observing users, involves activities similar to those of Contextual Inquiry and Contextual Design (Holtzblatt and Beyer, 1993). Some differences are that in our C & R analysis:
3.2. DESIGN
3.2.1. THE DESIGN SPACE
The design space is created by the boundaries of the design (see Figure 6.4). These boundaries are the customer, the user, the material, and the context of use (situation). In addition, there are always some practical and political constraints. For us, building information systems for customers on a contract basis always means that the time and funds available for usability work are limited.
Figure 6.4 The design space.
3.2.1.1. Customer, the Organization
The customers intent is one limitation for the design space. The customer is, however, very seldom a single person. Furthermore, customers belong to an organization, and they share the organizations values and mentality. This is seldom something conscious or explicit and therefore something the customer usually cannot reflect upon without some assistance. Our experience shows that customers have great difficulty explaining their concerns and wishes. We have developed a technique to explore possibilities with them and to help them express these needs.
To us, the word customer also represents the business rules that exist in the organization. These business rules can easily be captured with information models of business objects. We create information models as soon as a decision is made to begin a system development project. LinnéData uses a declarative, object-oriented technique, which captures the enterprise objects and the rules assigned to them. However, the details in this model are used for the internal design. For the external design, the object classes and their structure are the most important because they specify the relevant business objects and their interactions.
3.2.1.2. User Values and Goals
The users have values, skills, goals, and particular experiences, all of which influence our design. The design should provide users with the capability to perform their tasks while promoting the appropriate effect (e.g., a system for care of elderly people should promote a feeling of seriousness and accuracy in the user).
For us, the term user also embodies the tasks or actions they would want to perform. Our experience shows that only rarely does a designer need to analyze the users work in detail. Instead, it is sufficient to capture the potential activities through interviews and observation, along with rules connected with the use of the system (e.g., sequential rules, rules of access). This provides sufficient background for designing the user interface. We seldom create detailed models of tasks. On the contrary, we suspect that detailed modeling could interfere with a designers being innovative. This arises because the external designer is trained to think in terms of such human characteristics as cognitive workload, stress, and learnability.
3.2.1.3. Material
Designers are limited by the materials with which they have to work. We have found that in many system development projects the material limitations are not explicit. By material we mean all hardware and operating system limitations as well as any functionality related to the internal structure of the system, such as performance, adaptability, security, and maintainability.
3.2.1.4. Context of Use (Situation)
The physical and psychological context in which the system will be used is very important. When the external designer considers situational issues (e.g., time of use, placement of users, frequency of use, personal integrity, and ethics) important design information is obtained.
Previous | Table of Contents | Next |