Previous | Table of Contents | Next |
Where the Object came from... | Validity | Comments |
---|---|---|
Overall User Task Analysis report (e.g., UTA) | Highest | Object has meaning and is of importance to most users |
Specific user task analysis interview (e.g., UTA Cindy Lee) | High | Object is in the language of users and is of important to at least a subset of users |
Previous release of software (e.g., 3.0) | Medium | Caution required Replication from previous releases is generally desirable if there have been no customer complaints |
Team member (e.g., Kevin) | Low | No direct link to users; a team member felt it was a required object |
Other software (e.g., CodeBrowser 6.1) | Object derived (stolen?, liberated?) from other software | |
Be sure to test these objects and parts of the interface with users | ||
We followed a rule that no object should end up in the user interface that was not among the user objects defined. If an object did appear in the interface that was not on the User Object Wall, then we would review the situation: Either the object would have to be added to the wall or else it would be removed from the interface. This helped us to ensure that we recognized where an object came from and why it was in our interface. If an object was added to the User Object Wall during prototyping, it was to be accompanied by the name of the team member who added it, and/or the name and version of the software product from which the idea came.
While it is necessary that all objects used in a prototype appear on the User Object Wall, it is not necessary, nor expected, that all user objects from the back wall will be used in the prototyped system. Some user objects (and user requests) will simply fall outside the scope of the application being designed. It is possible that we could be producing excellent, user-approved prototypes based on even a small portion of the assembled user objects. However, if it seems that too many user objects are not being used (particularly if they are objects of high validity), it might be a cause to rethink the interface.3
3It could also just mean that the scope of your task analysis was particularly broad.
2.3.2. Organizing the Objects
We took advantage of the space available to us by organizing user objects on the wall, representing hierarchies and interrelations between the objects. This organization helped us to recognize some major categorical divisions and to structure the interface accordingly.
The following piece of text shows an example of raw user task analysis interview data and the user objects (italicized) that were parsed from it. Figure 10.2 shows one potential organization of these objects on the wall.
Rebecca Mahony is now working to understand 6 new modules of code. She relies heavily on her buddy as a resource, since he originally developed some of this code. But the code has evolved and now the original few modules interact with many others. Rebecca often has to contact the group heads who own these modules, because the module and procedure headers (which are supposed to describe them) are so out of date. Otherwise, she is stuck reading sections upon sections of code. The code library lists the names of group heads. Rebecca would really like to see parameters into and out of a procedure, as well as the structure and flow of data that is accessed by procedures. Neither of these is provided in the text-based cross-reference tool she currently uses.
Figure 10.2 Organization of objects on the user object wall.
Categorization of user objects was largely a process of trial-and-error. An object might start off in one position and be moved to another position as more objects were put up on the wall and new categories emerged. This was a bottom-up process. We would organize objects to represent hierarchical relationships between them, only to begin to see some lateral/horizontal relationships across the subhierarchies. We would rearrange branches of the tree, so that these related items would be closer, but this would often have the effect of moving other relationships further apart. In the end, we just aimed for the best fit possible. Eventually, all the objects were organized in a hierarchical fashion, capturing relationships both vertically and horizontally. The techniques we used are not far removed from the Affinity Diagram method described by Cohen (1988) and taught by Holtzblatt and Jones (1992).
Lets take the objects module and procedure (both objects represented in our users software code) from Figure 10.2 as an example. On the User Object Wall, we would place the word module above the word procedure to represent the relationship between them (i.e., module encompasses procedure). This is an example of what I call a vertical affinity (or vertical hierarchy, to be more specific). This is not a deterministic process. For instance, the word code library, instead of showing up underneath tools (as it did in Figure 10.2), could as easily have appeared above module in the hierarchy.
Once vertical affinities had been mapped out, we tried to add horizontal affinities. In Figure 10.2, for example, I have intentionally placed the word data next to procedure. I could have instead put the data branch on the other side of the resources branch. However, the data branch seems more closely related to the module branch than resources would. For this reason, I chose the horizontal position I did to capture the horizontal affinity.
Previous | Table of Contents | Next |