Task Descriptions

Task descriptions are a means for designers to delineate and understand the tasks that users perform.  Task descriptions are written by the designers and can be shared with the client to insure that designers understand the tasks well. Task descriptions can also be shared with the programmers to help design the software.

Purposes of Task Description:

• Delineate and analyze tasks
• Share with clients, to validate design
• Share with programmers as requirements

Because of the many uses of task descriptions, the descriptions can have many forms, varying from informal descriptions of typical scenarios  to formal step by step descriptions. We’ll introduce three types of task descriptions: Scenarios, Use Cases and Hierarchically Task Analysis.

Scenarios

Carrol (Usability Engineering, 2000) describes scenarios as informal narrative descriptions. Scenarios describe activities as they are performed by humans, in the language of the people performing the task. For example assume that your project is developing a GPS system that help users find there destination. Two scenarios you might write:

Scenario: Joe and Alice using written instructions

Alice is a passenger in the car that Joe is driving. Joe says to Alice, “I do not know where to go next?” Alice picks up the instructions and begins to read and ask Joe, “What street are we on?” Joe answers, “Uh? Oh it is highway 41.” Alice says, “The instructions say when you get to the Citgo station turn right up the hill.”

Scenario: Tom using a map

Tom is driving the car by himself. He feels lost and thinks, “Where do I turn next?” He grabs the map by the seat next to him and thinks, “What road am I on? Oh highway 41. Where do I turn next?” He stops the car on the side of the road and examines the map and thinks, “Let’s see, I am to turn right on Hill street.” He pulls the car back on the road and continues.

Notice that both scenarios do not describe the technology being developed; rather they describe how the tasks are performed currently. The scenarios delineate the stakeholders or actors, for example what kind of stakeholder is Alice? They describe the environment and circumstances, for example what is the difference between of circumstance of Joe and Tom. Most important, they invite thinking about improvements and solutions to any difficulties. Have the scenarios given you ideas about design for the GPS system? What are the trade-offs between the designs?

Carroll proposes several form of scenarios, used during different stages of scenarios based design:

• Problem Scenarios – above are examples, describe current practices or user goals
• Activity Scenarios – descriptions using a proposed system, generally there are no drawings
• Information Scenarios – elaborate on activity design introducing audio, visual and other presentations
• Interaction Scenarios – very detailed description of using the system

Note the scenarios become more and more explicit about using the propose system and developing the design. Several scenarios are written at each stage of the design. The scenarios should encourage discussion. Designers delineate claims and trade-offs.

Useful links for scenarios:

• http://ldt.stanford.edu/~gimiller/Scenario-Based/scenarioIndex2.htm
• http://en.wikipedia.org/wiki/Scenario_(computing)

Nominal Interaction Scenarios

Nominal interaction scenario combines Information and Interaction Scenarios. They describe the typical use of the app without errors. I propose using them early in small projects. They can give you quick and detailed view of the interaction that you can design against. The nominal interaction scenario can be extended to include the secondary stakeholders.

Example: Army App Nominal Interaction Scenario – Reconnaissance Mission

Because squads need to know the general location of reconnaissance and specific goals for the mission, the commander uploads missions’ locations and goals to web server. The field sergeant distributes the missions to his field soldiers.

The field soldier selects the Army App and views general instruction and mission goals. After reading, the soldier views the navigation screen in order to travel to their destination. In the proximity of the reconnaissance location, the smart phone gives an alert and displays the specific instructions for the reconnaissance, for example describing the exact location.

After reading the specific instructions, the solder presses the “new recon button.” The new recon view gives a list to perform:

• Photo incident
• Audio Record incident
• Select incident type
• Notes
• Save incident report

The solider selects the “photo incident” button and takes a photo. Saving the photo, the new recon view reappears. The smartphone saves the photo with GPS location and associates it with an incident id. The soldier presses “Select incident type”. The view displays different types of incidents to select:

• Civil disturbance
• Suspicious behavior
• Littering
• Theft
• etc.

The soldier selects the appropriate incident type and the smart phone saves the incident type, associates it with the incident id.

The soldier then select notes and a text input field is displayed with a keyboard. The soldier keys in text. The soldier presses “save” and the system saves the texts and associates it with the incident id.

The system displays the new recon view. The soldier selects the “save incident report” button. The system displays the navigation view. The soldier moves to the next recon location.

After visiting all the recon areas and repeating the process of documenting the incident, the soldier press the “return to base” button on the navigation screen and travels to the base.

At the base, the soldier uploads the incident base to the server. The commander reads the incident report and perhaps maps them.

The nominal interaction scenario attempts to give a detailed description of interacting with the system. Note that it describes more than the primary users interactions: the secondary user, the sergeant’s use is described; also it describes the use of the secondary stakeholder, commander.

The nominal interaction scenario gives only a vague description of the app’s views. Note it misses some specifics of the view. Where are the holes in the above description? What views are missing? Asking these questions lets your group progress with the design.

Use Case

Use cases are formal processes for describing the use of software. An actor is associated with a use case. Actors are abstract users of a system, typically having only a few defined goals. An actual user could play the role of several actors. For example in the MTU website the actors could be student, faculty, and administrator. A professor may be a faculty, an administrator and even a current student. The use case lists the sequence to perform a task. For example:

Finding a classroom:  Student

1. open web browser
2. point to MTU home page
3. select ‘current student’
4. find  and select ‘schedule of classes’
5. select ‘schedule of classes’
6. search for course
7. read line for course

Use cases diagram are used to briefly display interaction between actors and uses.

Use cases focus on the technology. They are good for refining the technology. For example how can the process for the classroom be streamed lined?  Use cases can also cause confusion in developing the metaphor. For example suppose that a professor wishes to find the classroom for a course that he is teaching. What must he do? Finally, use cases are not much help in conceiving new technology.

Tasks Analysis

Users have goals and break up the goals into tasks and finally into actions. It is important for designers to identify the users’ goals, but the process of achieving goals (tasks) should not be ignored. There may be more in the process of accomplishing the goals than the designer suspects. Also the designer can make the process better. After identify the goals and tasks, the designer can get a better understanding by performing the following analysis.

Workflow Analysis chronologically follows the job from person to person. For example, how are grades distributed at school?

Job Analysis follows a single individual through their daily job. For example what is the work day for a department secretary or a professor?

Task list is a detailed delineation of tasks. For the example what are the tasks to mail a letter,

• Address envelope
• Stamp envelope
• Insert letter in envelope
• Write letter
• Put letter in the mail box

The granularity of the list is a choice the designer must make, but 500 tasks maybe too many to manage, yet 10 tasks may not give enough information about the overall task.

Task sequence is the chronological order to perform the task. There maybe more than one order, for example how many possible orders for mailing the letter?

Nominal Interaction Diagram (NID)

The Nominal Interaction Diagram (NID) is chronological list of actions. It shows interactions (pair of actions) and the relationship between major stakeholders. There are columns for the important stakeholders: primary and secondary users, and secondary stakeholders. The system, in our case the app is a column in the NID. Entries describe the actions that the stakeholders perform. Arrows from the actions delineate the recipients of the actions. Actions are listed chronologically depicting error free interactions. It can follow the nominal use scenario.

Example: Army App NID

	Commander	Sergeant	Soldier	Army App	Server
1	uploads missions ———-	——————————	——————————	——————————-	->
2	distributes missions ——-	–>
3		Assigns missions ———-	–>
4			Open ———————–	–>
5			<–	Mission select view
6			Select mission ————-	–>
7				Request mission spec.——	->
8				<–	download mission spec.
9			<–	Display mission goals
10			Select Navigate ———–	–>
11			<–	Display Nav. view
12			Walk toward scene ——-	–>
13				Update Nav. view
14			Approach scene ———-	–>
15				Alert, display spec. info.
16			Read spec. info.
17			Select New Recon ——–	–>
18			<–	Display New Recon View
19			Select Photo ————–	–>
20			<–	Display image
21			Press Vol. Button ———	–>
22				Display photo view
23			Select Save —————-	–>
24				Store photo w/ id, gps
25			<–	Display New Recon View
26			Select “incident select” —	–>
26				Display incident spinner
28			Select incident type ——	–>
29				Store type w/ id
30			<–	Display new recon view
31			Select “notes” ————-	–>
32				Display text and keyboard
33			Key text ——————
34			<–	Display text
35			Select “save” ————–	–>
36				Store notes w/ id
37			<–	Display new recon view
38			Select “save” ————–	–>
39			<–	Display Nav. view
40			Repeat 12 -39
41			Finish recon
42			Select “return to base” —	–>
43			<–	Update Nav view
44			Walk towards base ——–	–>
45			<–	Update Nav view
46			Approach base ————	–>
47				Alert
48			<–	Update Nav view
49		<–	Return phone to Sergeant
50		Select “Upload reports” —	——————————	–>
51				Upload reports ————-	–>
52		<–	—————————–	Confirm upload
53	<–	Report recon complete
54	View incident reports  —	——————————	——————————	——————————-	–>
55	<–	——————————	——————————	——————————-	Display Map & reports

Numbering rows representing actions lets you delineate the specific actions. The NID can be used to anticipate errors.

Hierarchical Task Analysis (HTA)

A formal procedure for analyzing the activities or tasks is a Hierarchical Task Analysis (HTA). The procedure is to divide the goals and tasks into sub-tasks; the activities are grouped into major tasks and the tasks are subdivided into sub-tasks.  A simplified example for reporting the bill amount to a customer could be:

0: Report customer current bill
    1: Get billing listing
    2: Find customer bills
        2.1: Read bill
        2.2: Check name
              2.2.1: Check paid
              2.2.2:  Record amount
    3: Total amount
    4: Report amount

plan 0: do 1-4
plan 2: do 2.1 interleave with 2.2
plan 2.2: do 2.2.1 if not paid do 2.2.2

Included with the hierarchical listing are plans, which specify the task process.  Plans are associated with the higher level task.  A graphical display of a HTA resembles an organizational chart with plans appearing adjacent to vertical lines sub dividing the tasks.  The charts can get large or the lists long; even in this simple example task 1, get billing list, should be further subdivided.  The process can become involved and tedious.  Nevertheless the designers should list major tasks, and they will find themselves specifying the higher level task by listing sub tasks. Essentially the designers are reproducing the HTA structure.  Plans are hard to specify but they are useful for identifying important or work intensive tasks, alerting the designer to reconsider the task process. In the above example the designers should include functionality to automate plan 2 in the billing applications.

Simplified HTA

The simplified HTA shows the hierarchy with indentation, but does not number the tasks or sub tasks. Plans are not specified. The simplified HTA is not trying to model the user; rather it is trying to delineate the task associated with each view in the app.

Example: Army App Simplified HTA

Extending the hierarchy to more than three levels becomes difficult to read. A better structure is to the divide the views into upper and lower level views, as shown above. The indented sub-tasks below a view/task can represent buttons for tasks or navigation to new views. You can examine the views to determine if it is possible to navigate between views. Also, you can examine the views to determine to if all the activities are specified.

Other Method for Identify Goals and Tasks

Ethnography

Ethnography and visiting the work place is a popular way to learn about users and their goals.

Rosson and Carroll (in Usability Engineering) proposed that a description of the work place involves three dimensions:

• Activities of the work place including identifying the personnel.
• Artifacts of the work place such as information (used and created) and tools.
• Social context of the work place, identifies group organization and roles of individuals.

The three dimensions of the work place are good aspects of the work place to consider while learning the users’ work.

We can learn much about how a sculptor works by studying a sculptor’s tools.  The mass and size of the hammers reflects the material the artist is working on and the level of carving detail.  How the tools are arranged in a well organized shop is determined by the carving process or sculptor’s preferred techniques.  The material that the sculptor works in (i.e. stone, wood, plastic, etc.) not only determines the final sculpture but the process.  Naturally learning about the sculptor’s work we would be amiss not to identify the final product.  Sculptors producing figurative statures and tombstones have different concerns.  Identifying the artifacts (materials, tools, and sculptures in this example of the sculptor’s work) helps us learn the process.

The work place artifacts identified by the designers are frequently more abstract.  The artifacts may represent information, databases and applications in the computer. Nevertheless we should not ignore the physical artifacts; a dictionary on the desk should suggest that the user frequently references it for spell checking, definition or some other use.  The designer should identify the clues and ask the user about their use.

Random House: ethnography ~ a branch of anthropology dealing with the scientific description of individual cultures.

If possible, the designer should visit the work place to identify the users, activities, artifacts and social context of the work.  Rosson and Carroll recommend a technique used by ethnographers which involves the ethnographers personally in the tasks and customs of the tribe; the researcher speaks the local language and participates in the normal activities of the tribe.  Ethnographers’ goals are not only to acquire a deeper understanding of the culture but also the trust of the people.  Designers can benefit by using the same techniques, but the value of insights may be directly proportional to the amount of time spent.  Also if the designer identifies too strongly with the user, the designer may lose the perspective of an observer, which is also valuable.  A user frequently is too involved or habituated in the work to identify radical or subtle beneficial changes in the work place or process.  Nevertheless a user will always have ideas to improve the user’s work; these ideas are valuable if not to suggest a solution, then to indicate a problem in the work place.

Observing and Listening to Users

Asking users or workers how they perform their tasks frequently does not give the results that designers need. Users may not describe what the actually do or think, rather they describe what they want or think should happen. Observing user may not give sufficient insights to what users are thinking while they are working. There a few standard techniques for eliciting what users are thinking.

Think Aloud: The user keeps a running commentary of what they are thinking while they are performing a task. The designer records the user’s vocalizations. This may seem awkward for the user, but after practice they can become very proficient and forget that they are being recorded. Sometimes the designer may have to prompt the user to keep talking by saying, “What are you thinking?” Psychologists perform a very formal analysis, but designers only need to get ideas from the commentary.

Talk Right After: Sometimes the user can talk while perform the task. In these cases the designer and the user can meet right after performing the task, and the designer can request that the user explain what they were thinking. The design should ask questions that keep the user grounded in his thoughts while performing the task and not on speculating the cause or give excuses.  This is done by asking question like, “What were you actually thinking?”

Role Play: Sometimes used for tasks that occur infrequently and can not be immediately observed. The designer and the user can play roles, and the designer can ask questions during the role playing.

Cueing Recall with Video: An elaboration for Talk Right After is to use video recordings to help the user recall the event and what they were thinking.