Lab 03 – Enacting a Task analysis
Task Analysis Lab
What are we doing in lab today?
In this lab, we will practice task analysis (TA), a commonly known method in Human–Computer Interaction (HCI). We’ve gone over task analysis during lecture, so we’ll skip the background here. Go back and take a look at FDUCS chapter 11 if you’re having difficulty remembering details. We will use these tasks analyses to develop GOMS models (in NGOMSL) using a tool called Cogulator.
Today’s work connects your first two labs and pulls the ideation and information structure into something that could be used for evaluations and identifying potential issues.
You will work in your group. Each group will:
- Determine two tasks within your potential project interface and information architecture to which task analyses will be applied
- Generate hierarchal TA (of your two tasks)
- Generate cognitive TA (of your two tasks)
- Generate NGOMSL models using the HTA and CTAs you developed
You should still focus on the course’s final project contexts: Health, Disaster/Emergency Management, Digital Archives, or Play. (And groups are the same as they will be for the rest of the semester.)
Get setup with Cogulator
Navigate to the Cogulator website and grab the version that best suits your platform if you don’t have it from previous activities.
01: Determining tasks
The first thing we need to do is determine some tasks that we’ll use for our TAs. Here, you likely want to consult work from your previous lab as we might assume that your projects information architecture (and related tasks) would be a good place to start. The point here is to stay grounded and within scope as we do a crude form of iterative development towards something that will look a lot like a final project.
Tasks:
1) Invidually identify two tasks from your interface and information architecture that we can use to develop task analyses. Make sure these can be reasonable broken down.
A reminder that we are focused on the human-computer interface, so you should make sure you pick something that is focused on the interface between a human and a computer!
These tasks should be able to broken down into at least 5 goals/subgoals (basically they should have some hierarchal complexity to them)
2) As a group come together and get a consensus of two tasks you will use as a group for this lab.
- Why did you pick those two (consensus) tasks - what are the salient feature/characteristics of those two tasks?
- How did complexity of the tasks weigh in your decision making?
What to report:
- Main body of the lab report: fill in your group consensus of 2 tasks chosen as well as why those two were chosen within your group. Make sure to answer any questions posed in the body of the report
- Appendix: Fill in all individual items that were used for consensus/group combination reported in the main document.
02: Hierarchal Task analysis
Now, lets do a hierarchal task analysis of the two tasks you selected via consensus in part 1.
Tasks:
1) Individually develop an HTA of your two tasks where you represent the task visually (e.g., similar to what is show in Fig. 11.2 in the FDUCS book). 2) As a group come together and develop consensus HTAs of your tasks based on discussion of individual versions
What to report:
- Main body of lab report:
- Final consensus HTAs.
- Salient things that were discussed as you came to your consensus. (Were there things that were similar individually? Were there big differences? etc.)
- Appendix: Individual HTAs that were used to develop the consensus HTAs.
03: Cognitive Task Analysis
Now, we will do a cognitive task analysis for our two tasks. In some ways, we might think of a GOMS model (which we’ll do in the next section) as a method for a CTA (and that’s because it is!), but for this section, we’ll use a different method to complete our CTA: talk-aloud protocol, which is often referred to as the more general think-aloud protocol (though Ritter et al would argue that the two are separate, as you’ll see in Chapter 13 of FDUCS).
Important - This method is more dependent on having an actual interface/prototype in front of you. So, you may have to use an existing interface as the example to accomplish your CTA. This will mean a divergence between the CTA and HTA. That’s ok, in this case, you’ll want to rely on your CTA for your GOMS model.
Tasks:
1) Groups of 2 (or full teams if a group of 3): Split up into groups of 2 and have one member do a talk-aloud as you work to accomplish the goals laid out in one of the HTAs. (Each group pick one of the consensus tasks to work on here)
What is a talk-aloud? The talk-aloud protocol is a way to get users to verbalize their thoughts as they accomplish tasks and behaviors. Basically this will give us a (good enough for our lab) view into the cognitive steps used as goals are being achieved to successfully accomplish a task. (See also the Nielsen group explanation of the think-aloud protocol which they treat as the more general class, which encompasses both talking during the task, live and after a user has completed the task, retrospectively)
2) As a group come together and discuss your results. Modifying where needed to develop a final CTA for both tasks.
- In what ways did the use of talk-aloud bring out thinking occuring during the task that you otherwise might have missed?
- What questions do you have about this process that you might want to answer through some self research for your projects?
What to report:
- Main body of lab report:
- Final consensus CTAs.
- Salient things or topics that came up when discussing your CTAs. (Were there things that were similar individually? Were there big differences? etc.)
- Answers to questions posed
- Appendix: All individual (paired talk-aloud) work.
04: GOMS with Cogulator
Lets use Cogulator!
Tasks:
1) Groups of 2 (or full teams if a group of 3): Split up into groups of 2 and use pair programming to create new GOMS models for both of the two tasks you’ve been using for your HTA and CTA.
What is pair programming? Pair Programming is a way to write software as a (paired) team. With paired programming, one person does the coding/typing at the computer while both folks talk and think aloud as they are developing the code. Communication is very important for pair programming as its a tool that can be used to increase understanding as you are developing code, improve processes, etc.
Make sure to use your HTA and CTAs to operationalize the tasks in this NGOMSL form. Use the Cogulator examples (e.g., CPM-GOMS, forgetting) as examples of ways you might include mental operations (and those mental operations will likely come out of the results from your talk-aloud)
2) As a group come together and discuss your results. Modifying where needed to ensure you have a good final set of GOMS models
- Were there any changes that had to be made as a result of talking within your whole group (if so, what were they and why were they needed?)
- Where did you find the usefulness of GOMS modeling being stretched for your particular tasks?
What to report:
- Main body of lab report: Salient things or topics that came up when discussing your GOMS models as a group.
- Were there any changes that had to be made as a result of talking within your whole group (if so, what were they and why were they needed?)
Appendix: Results from your GOMS model - Timing, Gant chart (with workload and processors being used), full (final) GOMS models.
- Please submit your final .goms files (consensus) models as well
What is a reasonable lab report length?
- 4–8 pages (excluding appendices).
- Make sure to include all requested items in appendices!
How is my lab graded?
| Graded item | Points |
|---|---|
| Introduction | 3 pts |
| Lab section 01 | 3 pts |
| Lab section 02 | 6 pts |
| Lab section 03 | 3 pts |
| Lab section 04 | 6 pts |
| Conclusion & Next steps | 3 pts |
| Appendix 01 | 3 pts |
| Appendix 02 | 3 pts |
| Appendix 03 | 3 pts |
| Appendix 04 | 3 pts |
Total points possible: 36 pts