Chapter 5

Chapter 5: Making the business case for site visits


The main reason behind the visiting user site is to verify that our assumption about the user are correct. Through this chapter, authors explain the expected risitance that you will (as a designer) face with your company when you propose to visit customer site to learn more about them.

Common objections to task and task analysis:
We’re changing the process; why to bother and check the current process?
Even though you’re changing the process, you still want to learn about the environment and the current workflow and tasks. One way for the new process is to adopt the current workflow and tasks as the users are familiar with. This will provide a good transition for users to the new process rather than having a new process (or system) which is incompatible with the environment.  
This is totally new; nothing it out there to go and see!
Even if you’re proposing a new design, you still can learn from its older design. For example, if you’re designing a fax machine, you still want to learn about how people send messages.
Users all do it differently; how would you know who to watch?
In all cases variations between users are expected, cultural variations, shortcuts, workarounds, etc.
we’re just changing one part; you don’t need to go beyond that!
Even if the change is one a small part, you still want to study the other parts as they affect the whole user experience. Also, you can learn from other tasks that interact with the tasks affected in your new change (or part).
What can we learn from few users?
recommendation is to study small number of users, so small-scale user set is totally acceptable and beneficial.
Why not to use the information we already have?
Usually, we hear such question from market researchers, and business employees. Of course, we still need their data and studies, however their studies questions were focused to serve their purpose and do not answer what we really need.

Chapter 4

Chapter 4: Thinking about the users’ envirnoment

The importance of the user environment is that user’s do not perform their tasks in an isolated environment. In fact their environment affects how they work and perform tasks.

Important aspects about user environment:

1. Physical:
• Do your users work at home? or in adequate office space?
• Noisy environment?
• dirt, dusty, windy environment?
• enough lighting for users to perform task?
• temperature: very hot, or very cold, in which user will be affected by it?
• what is the user expected system response time?
• power? proper connection to a network or internet?
• user danger? e.g. ATM
2. Social:
3. Cultural: ethics, backgrounds, cities,... different interpretation for images came from different cultures!  

Chapter 3

chapter 3: Task Analysis

Chapter 3 discusses task analysis, and what are the important things to be done when analyzing user tasks. Please note that I use the letter p to refer to page numbers.

P52: What is task analysis? identifying and analysing user goals and tasks.
P53: This book use the term “procedural analysis” to describe the detailed level analysis of tasks; like dividing tasks into subtasks and decomposing them into steps and decisions.


Identify user goals:

• User goals are less likely to be changes!
• Understanding task analysis at the predesign stage
• talk to users, watch them do the work even if its not optimal way, talk to experts, observe errors and workarounds

Identify user goals → tasks → actions

User Goals:(a) user goals
(b) companies goals
Sometimes (a) and (b) match each other, but sometimes they do not!  Both can be addressed by improving the usability of the product. Goals are not necessary named user's and companies; example: buyer’s goals and seller’s goals; they carry the same idea but with different naming.

For every goal (p55) we need to:

• Relate goals to their tasks and then to their actions: figure (3-1). P56: lists the seven steps of relating goals to their tasks.
• How people react to achieve goals and perform tasks. (example at p57)
• Seeing how users choose tasks to meet their goals: users have options to choose what tasks they use to achieve their goals. (maybe several tasks with different ways can achieve the same goal)
• Seeing how users handle any problems
• Making sure to keep goals as a part of the task analysis

To perform task analysis, we should perform the following steps:

1. Workflow analysis: how work gets done when several people are involved (p61). A set of steps are formed for every process.
2. Job analysis: what a single individual does through the day, month, year. Understanding what every employee does in his/her daily would help to identify some design decisions that help in easing their work. Another important issue about tasks is to check their: frequently, critically, duration, difficulty.
3. Later, analyst should combine the workflow analysis with the job analysis results.
4. Task list (or task inventories): what tasks are performed by any user. Task list does not tell you how to achieve the task, it just tells you what will be achieved using the task.
5. Process analysis, task sequence: the order in which users do tasks.
6. Task hierarchies: what subtasks every task has (divided in chunks). Job → tasks → subtasks (example figure 3-11 p74).
7. Procedural analysis: what are the steps and decisions user take to accomplish a task (or subtask) (figure 3-12)

One more important thing about task analysis is to identify and understand the potential user types. User types and stages are as follows: 

• Novice, 
• Advanced beginner, 
• Competent performer, 
• and expert.

The tangled Web we wove: a taskonomy of WWW use

Paper: 
Michael D. Byrne, Bonnie E. John, Neil S. Wehrle, and David C. Crow. 1999. The tangled Web we wove: a taskonomy of WWW use. In Proceedings of the SIGCHI conference on Human factors in computing systems: the CHI is the limit (CHI '99). ACM, New York, NY, USA, 544-551.

Review:
Authors claim that little attention was given to analyize the user tasks while browsing the www (internet). Their goal was bring a more usable and effective user interface for internet users (who brows the www) from the tool side and from the usability of the web side.

Authors work was new in identifying and understanding user tasks while browsing the internet. Unlike the previous studies which focused on the user navigation patterns such as: click-studies. This provide an advantage of better understanding the user tasks and behavior when browsing the internet.

Experiment was conducted on 8 participants. They were asked to browse the internet as what they usually do in their daily routine. Each was asked to provide a verbal protocol that describe his/her browsing activity. Additionally, a video camera was recording protocols and users screens. The amount of analyzed data was between 15-74 minutes for every participants.

For the analysis purpose, they have constructed a taxonomy of user tasks when browsing the internet. This taxonomy was constructed using their previous work, and by observation of the first three users in the experiment. This taxonomy is hierarchal taxonomy of user tasks while browsing the internet. WWW tasks are as the following:

• Use Information
• Locate on Page
• Go To Page
• Provide Information
• Configure Browser
• React to Environment

Every task encapsulate sub task. They used those tasks to construct user tasks through the experiment. For example, a user wanted to download a college paper, his top-level goal was to use information (download) and the rest of sub-goals go as the following:
UseInfo(download)
    GoTo( bookmark)
    ProvideInfo(search criterion)
    Locate (related)
    GoTo(hyperLink)
    Locate(related)

In their results, they found that the six main tasks that they used to capture user tasks were useful and worked well in that matter. Also, they found that some tasks can be formed from other sub-goals. This lead them to the conclusion that their hierarchy was not strictly hierarchy (nearly flat).
In their discussion, they had two type of design implications: on browser design, and on page design. One interesting thing about webpage design was that its not necessary a bad design to have a webpage full of text (from their experiment). Another intuitive thing that they discussed was the need to optimize the page load time as most users spend good amount of time waiting for pages to load (I guess this is not a big issue now as it used to be at 1999).

In my opinion, they did a great job by constructing the main task hierarchy that form user goals when browsing the internet (figure 1). Another issue that I found that they use the time and the number of events as the main two factors to evaluate every user task. Time factor can be biased sometimes. Sometimes users needs some time to learn their way through website on their first visit. I think this issue should be addressed in the limitation of the study.

User, robot and automation evaluations in high-throughput biological screening processes

Paper:
Noa Segall, Rebecca S. Green, and David B. Kaber. 2006. User, robot and automation evaluations in high-throughput biological screening processes. In Proceedings of the 1st ACM SIGCHI/SIGART conference on Human-robot interaction (HRI '06). ACM, New York, NY, USA, 274-281.

Review:

This paper explains a task analysis that was done to high-throughput screening (HTS) system in the field of biological samples of life sciences. The analysis in this paper was done to an existed HTS system at the Center for Life Sciences Automation (CELISCA) in University of Rostock (Germany). This type of systems include potential human errors as human operator has to plan the procedure before the process. Those errors are costly, that's why authors have conducted this work. This paper has two goals: (a) minimize the human involvement to monitor the system errors involved (automation) , and indentifying the limitations of the current interface design to help in automating the heavy manual workload.

This work focuses on one part of the HTS process which is human-robot interaction (HRI) as its errors are costly. In HRI, there are 11 steps needed to be done by the operator (see table 1). Most of those steps are human. As a result of that, human errors can occur. Additionally, some chemical errors might happen.
In order to address the problem of the costly errors in the human-robot interaction (HRI) in the HTS process, authors used cognitive task analysis (CTA) to facilitate the operations of HTS. In this context, they applied goal-directed task analysis (GDTA) jointly with abstraction hierarchy (AH) modeling as a new integrated CTA approach (see section 4). GDTA were used to identify the current tasks and their workflow, while AH were used to automate those tasks on the user interface.

For the GDTA, authors used it to identify users’: major goals, subgoals, operational tasks, questions about decision making in task performance, and developing information requirements. They elicited the tasks using structured interviews with one domain expert at the university. Two examples of GDTAs can be found in figure 3, and 4. Later, they used the results of GDTA to generate the abstract hierarchy (AH). They gave one example of abstract hierarchy (AH) for the barcode device which is used in figure 3 for printing.
The recommendations of this study were to enhance the user interface by bringing more automation to the current  interface and therefore eliminate some of the potential human errors. One example of those recommendations is having a default labels for barcodes with the option of user defined barcodes.

What I liked about this paper is the combination of both techniques GDTA along with AH to serve the purpose of this study, however I would suggest to them a further investigation in validating their recommendations by experimenting them with HTS users. Another issue with this paper is that it has many acronyms which makes confusing to readers.

Chapter 2

Chapter 2 of the book kicks off by discussing the first step in the analysis which is the User Analysis. First, it discusses the importance of identifying who are the users, then forming the user profile team. Later, constructing user/task matrix. Finally, assumptions about users.

Users can be classified under the following categories:
(a) Primary: user who will actually use the system and interact with it.
(b) Secondary: user who will be affected by the system (directly or indirectly)
(c) Surrogate: users who replace the primary users on their vacations, and leaves.
All of the above categories are important to be considered when designing a user interface.

P31: forming user profile team.
P32: creating the initial user/task matrix.
P33: "write down your assumptions about user types (differences and similarities) and discuss them with the user profile team" . Also, think about how would you test to verify them!
P35-50: discusses what are the information we need to know about each user type? (a) How users define themselves: jobs, tasks, tools, and mental modes. (b) How users differ individually: mentally, physically, culturally, and motivational wise, (c) How users use products overtime, and what expertise level are they looking for?

As for the cultural issue, sometimes culture is not an issue and that depends on the system and its usage. Deciding if the culture would matter or not is usually done using the stage of use (Ch3).