Describing the UserUser Tasks

The heart of HCI practice is an understanding of how users go about doing work. After all, the purpose of the systems we build is to facilitate work that would otherwise be more difficult or sometimes even impossible to complete. For this reason, modeling tasks from the most abstract organizational process to the most fine-grained user action is at the heart of user modeling. Ultimately, to bind HCI practice to software engineering, we must be able to seamlessly trace downward from the finest-grain user actions to the system events that take place to support them.

Deriving Task Model Content

This topic does not address the HCI methods used to derive task model content. For a discussion of deriving the task model, see the Methods and Architecture topic. For this discussion we'll assume that a use case and scenario based method is used to derive an HCI task model. For the modeler, this implies that user interviews yield a first-pass description of user populations and user responsibilities. From that starting point, further user observation and interview must take place and be sufficiently detailed to author scenarios. Each scenario is a description of concrete interactions (typically) between a user and the system that describes, for one task, how each task is or might be completed. Ultimately, the modeler derives a model of the users' and organizations' tasks and a model of the domain in which these tasks operate.

Scenarios and the Domain Model

The classes Scenario, Task, Object, Entity, Event, and Action all participate in modeling scenarios. The reason for this modeling richness has to do with the information the modeler is deriving from each Scenario. Each Scenario can be thought of as an ordered list of narrative description of a procedure. But herein lies the advantage of use cases over other task-analytic approaches. In addition to this procedural description a scenario also describes the objects (instances of entities) that are manipulated in the course of the scenario. The procedural steps are really derived from a careful sequencing of Events requested against Objects. When complete, the Objects in the Scenario will each map to one Entity type. Similarly, events map to an Action type. As the modeler moves through the scenarios refining their procedural content, she must also keep the corresponding Entity and Action descriptions consistent.

This is an important point. The power of a use case based approach lies in this duality of representation. As scenarios are authored the modeler documents not only procedural content of a task, but the conceptual content—that is, the objects and actions—contained within the procedural steps. This conceptual content must be consistently used from one scenario to another. In UML, this consistency is attained by creating a class model of the domain. In the terms we've used in this topic the domain is represented by a class model of the entity types in the user's domain as well as the entity's attributes and relationships.

Granularity in the Task Decomposition

After some scenarios are authored, the task modeler begins to alternate between restructuring the task decomposition and adjusting the scenario content to match the new task boundaries. Part of the adjustment process is a careful matching of model granularity to task granularity in the world. The class diagram below shows a chain of whole-part relationships starting with Process, a type of task that is performed by organizations, down through User Responsibility an abstract type of task performed by users, and on down to Primary Tasks and Secondary Tasks which are tasks that can activitate Actions that effect entities (and which also have presentation associated with them, as we'll see on the next page). The levels of task granularity are defined by the following questions:

• Is the task performed by an Organization? If so, then the task is a Process.
• For tasks performed by User Populations, is the task abstract (a task that is not facilitated by a physical representation)? If so, the task is a User Responsibility.
• For concrete tasks (one that does benefit from a physical representation), is the task independent of context (is it an individual unit-of-work)? If so, the task is a Primary Task.
• Or is the concrete task dependent on another task? If so, the task is a Secondary Task.
• Is the task essentially without a goal (the goal is simply to complete the task which is a low-level operation or procedural step)? If so, the task is an Action.

What good are all of these fine task distinctions? These distinctions allow us to focus our efforts more effectively and to avoid missing important questions. For example, if a task is a:

• Process
  • Is this task the responsibility of an organization and not an individual?
  • What are the workflow implications as processes often involve multiple people in their completion?
  • Are the user tasks below this process necessary and sufficient for completion of this task?
  • How likely is the organizational goal to be satisfied given the user goals below it?
• User Responsibility
  • How rational is the user's goal relative to the organizational goals in any containing processes?
  • How rational are the set of user responsibilities each user population performs?
  • Are the concrete tasks below this user responsibility necessary and sufficient for completion of this task?
  • Is the goal of this user responsibility well served by the concrete tasks it composes?
• Primary Task
  • Is the meaning of this task independent of other tasks?
  • Does this task represent a single unit-of-work?
  • Does the visual representation associated with this task optimally facilitate task completion?
• Secondary Task
  • Is the meaning of this task dependent on the context in which it is performed?
  • Does the visual representation associated with this task optimally facilitate task completion?
• Action
  • Does the action have any significant goal associated with it?
  • Do all of the function points requested by the user/customer/marketing appear as instances of Action in the model?

Tasks and Presentation

Once the modeler has a stable task model she also has a first pass at presentation requirements. The task model can be considered stable when there is a slow rate of change relative to iterative revision. Once the model reaches this point, the modeler knows that each concrete task requires a unit of presentation to support it. What's more, the scenario content specifies the entities, attributes, and relationships that must be visible in that presentation. If care has been taken to record this information, the modeler also has enough of a description of the task to be able to derive a problem-solution optimized presentation. Modeling the pieces of this presentation will be the topic of the next page.

The figure below is a UML class diagram modeling tasks from organizational processes down to atomic user actions on the user interface.

Figure: a UML class diagram, over 650 pixels wide—click here to open it in a separate window.