Previous Table of Contents Next


5.1.5. User Environment Diagrams

The goal of User Environment Diagrams (UEDs) is to structure the services and objects of the system in a way that support the users’ tasks without imposing a strict task order. The structure is implementation independent, even if in reality the choice of platform and “look and feel” is often obvious or not under the control of the design team.

A focus area describes what system services and objects a user requires to solve a defined task. The services might be simple, possibly corresponding to a single function in the user interface, or to a complex set of functions, where there is a need to decompose functions into new focus areas with additional but less complex services and objects. An example from the case study can be found in Figure 7.3.


Figure 7.3  Turning an activity graph into a focus area.

The activity graphs are the starting point for identifying possible focus areas. Each activity in the graphs is a candidate for becoming a focus area. The team needs to be flexible and to keep an open mind when identifying candidates for the focus areas. There is not a one-to-one mapping between an activity in the activity graphs and a focus area in the user environment diagram. Several activities might be intimately connected and might need to be merged to form a focus area. On the other hand, an activity might be too complex for a single focus area and might need to be decomposed to identify relevant services and objects.

Some system services might already have been identified in the information matrix as services essential to the success of the system. These services are often described on a very general level and need to be analyzed to identify the extent to which they are already covered by the activity graphs. If they are vital, they should already be accounted for. If they are not present, the customer might have a very different view of what services the system should offer!

Another potential source of system services are scenarios describing the future work practice. The scenarios and the activity graphs reflect the same reality, but scenarios often offer more details and also include more of the potential difficulties and exceptions that the system must be able to accommodate. A simple and straightforward way of analyzing the scenarios is to search for verbs as candidate services and nouns as possible objects.

The process of finding possible user objects is tightly connected with identifying system services. A service usually operates on an object and, if a service is identified, the related object(s) are usually close by. The information objects in the activity graphs are often prime candidates for becoming objects or focus areas for managing the information objects (data entry, database management, etc.). Another source of information is the concept list, which defines the users’ meanings of all terms. It is used to identify potential objects and to ensure that services and objects have appropriate names.

In most cases it is easy to describe the flow between the focus areas. They might be identified from the connections in the activity graphs or be quite obvious, for example, when a focus area has been decomposed into subareas. The situation can get more complex if several focus areas use the same system services or even the same subareas. This is an indication that perhaps further investigation is needed, possibly resulting in restructuring of the focus areas. There is no rule that prohibits this multiple use of services, but our experience is that the resulting user interface often becomes more complex. Therefore, it is easier to resolve the matter during the conceptual design.

5.1.6. Conceptual Design in TSS 2000

The conceptual design of the case study was highly interactive, involving the entire usability team. The moderator selected a central activity from the activity graphs and led the discussion regarding services and objects that would be relevant to the user when performing the activity. The session began with the design team suggesting the services and objects to include in a focus area. The suggestions were written on colored notes and added to the focus area on the white-board. Whether or not the group found it easier to identify the services or objects first was dependent on the problem domain. In practice, it did not really matter because the two sets were interdependent. If a service was identified first, it was usually easy to identify related objects and vice versa.

All system services (yellow notes) and user objects (white notes) were organized on the white-board under a suitable title for the focus area. If a service was complex it was decomposed into subareas, each of which consisted of more detailed services and objects. The flow between the focus areas was indicated by arrows on the white-board.

Once a focus area or group of areas seemed to be stable (i.e., no additional services or objects could be found and no system service was judged to be overly complex), it was copied from the white-board to a flip-chart and then posted on a wall. The white-board allowed the freedom to quickly add or revise services, subareas and objects. Moving the information onto paper was a natural way to accomplish a sense of closure to the work process, giving the structure greater stability, but still allowing further comments or revisions. This process allowed us to maintain some structure in the design process and to avoid excessive debate on issues. The moderator determined when the level of detail was sufficient and when it was time to consider a new focus area.

When an activity graph had been fully analyzed and converted into a number of focus areas, the scenarios were used to verify that the service structure described by the UED was correct and complete. Since we lacked explicit user scenarios in the case study, we used the user profiles and the activity graphs to create hypothetical scenarios. When they are the basis for the focus areas, it may seem circular to test the diagrams using scenarios from the activity graphs. Surprisingly, the hypothetical scenarios revealed several problems and inconsistencies in the design and were an excellent substitute for real scenarios, given our situation.


Previous Table of Contents Next