1. Task Analysis Methods Frank E. Ritter IST 331. 24 Oct 2017
Imagine making a list of tasks for this complex phone, a voting booth, or a GPS. The primary tasks are straight forward, but then you get caught in the details, and the user equally gets caught in the details. In these cases, the details matter: the breadth of tasks, the steps of each task, how to correct errors, how to stop tasks and how to start tasks.

2. Example HTA Login Login Choose objects Choose objects Pay Pay
Select login screen
Enter ID
Enter password
Choose objects
Browse listing
Select item
Pay
Choose pay screen
Select payment method
Enter payment method details
Plan: Task 1, then Taks 2 as many times as needed then Task 3.
Login
Select login screen
Enter ID
Enter password
Choose objects
Browse listing
Select item
Pay
Choose pay screen
Select payment method
Enter payment method details
Plan: Task 1, then Taks 2 as many times as needed then Task 3.
Here is an example Hierarchical task analysis. Done two ways. There are many more examples online and in the book.
It is like pizza. Slight variations, all good. The variations arise based on local tools, standards, use cases, types of tasks, and so on. Like pizza.

3. Example HTA Push the details as far as you Login
Select Login screen
Move mouse to “ID”
Click mouse
Enter ID
Type ID
Enter “CR”
Enter Password
1a.Move mouse to “Password” OR
1b.Type “TAB”
2.Type val-of(Password)
3.Type <CR>
2.Choose Objects
. . .
Push the details as far as you
need to, but not farther
If you get serious, you could measure typying speed and password length and then then password characters, and then digraphs and trigraphs. But, often a high level analysis is enough and more than has been seen. 3

4. Task Analysis Methods
Lots of methods for getting task analysis information
None completely satisfactory
How to get knowledge: Best solution is to employ a variety of methods
1. Questionnaires and Interviews
2. Observational studies/Contextual Inquiry
3. Examination of competing or similar products
4. Use unsolicited comments
You will find that these methods are micro-versions of the existing methods, and deserve a write up about who you talked to/what you talked to
How you got them to talk, what you found. You might find that some folks do it one way and another group do it another way, which would be an insight worth reporting.
On the coming slides, the knowledge elicitation and the knowledge representation are sometimes mixed together.

5. Cognitive Task Analysis
Focuses on what users already know
Concerned with accurate mapping between representation of user’s knowledge and that required by system
CTA used where operators are well trained
Pays attention to how tasks are performed along with noting the tasks
e.g. “how long users will take to perform the tasks” 5 5

6. GOMS and KLM Goals, Operators, Methods, and Selection rules
The analysis ends up looking like a type of program
Keystroke-level model
The analysis ends up looking more like a trace of a program
Both concerned more with details of how a small task is done
Both can be applied back-of-the-envelope, and also in greatly detailed way
Both make lots of suggestions, some applicable to higher level
Suggestions include: duplicate steps, irregular patterns, what to teach, reduction in command names, and so on
See book for furtehr examples and 6 6

7. GOMS and KLM Resources
Calculator (from
Worked examples chapter 11
See book for further examples and 7 7

8. Ways to find out about task and environment
Ways to find out about task and environment. There are at least 4 categories. This is a survey of them. You will not use all of them for sure. You should know about them for the future. I Questionnaires and interviews

9. Who to interview about task?
Identity?
In-house or specific customer is easy
Need several typical customers for broad product
Background of users
Skills of users
Work habits and preferences
Physical characteristics
Height? Depends on task
E.g., truck interiors, walkup and use kiosks, tablets 9 9

10. Talk to Them Find some real customers Talk to them Are they too busy?
Find out what they do
How would your system fit in
Are they too busy?
Buy their time
T-shirts, coffee mugs, etc.
This is really just a basic to find out the context. 10 10

11. Questionnaires & Interviews as a way to get TA information (1/6)
Talk to a number of representative users
Talk to key users
Plan interview
Preset questions to address issues identified in advance
Always provide flexibility for users to add to your plan
Provide mechanism for recording data easily
Present quantitative results
Use the TA as a summary
For example, take a photo of a cockpit, and ask what areas are used and when and for what.
Use of examples and use of mockups are helpful.

12. Questionnaires & Interviews (2/6)
Keep the number of questions low
Only questions with answers that you can’t get other ways - do your homework
Only questions that will have a direct impact on functional requirements
Avoid asking for everything
For example, if you ask which of these are the menu in word, you will get nonsense, people don’t remember it and it’s not designed to be used that way (I hope)

13. Questionnaires & Interviews (3/6)
When deciding to ask a question, always ask
Why is this question included?
How will I analyze results of this question?
Do I lose anything if I leave it out?
Do I have a better source for this information, e.g., can I find it by looking at logs?

14. Questionnaires & Interviews (4/6)
Ask clear questions
Can the user understand your question?
Ask questions that users can answer validly and reliably
Does the user store information in this way?
Does the user remember such information?
Will the user be inclined to answer your question truthfully?

15. Questionnaires & Interviews (5/6)
If you need the answer, but users can’t give it to you, use another technique
If a question won’t give the answer, look for the user leaving traces in the environment
Respect users time and intelligence
Always thank the user for the information

16. Questionnaires & Interviews (6/6)
Do not take comments personally
you shouldn’t have a personal stake
Goal is to make the system easy to use for your intended users

17. Ways to find out: 2 of 4 Observation Studies as a way to get TA information
Iterative

18. Observational Studies (1/6)
Describe and analyze current practice
Note organization of functionality
Note expectations and concerns of current users
Solicit suggestions from users
Collect quantitative data
How many?
How often?
How long?

19. Typical Observation Techniques (2/6)
Task process study
Detailed steps in tasks performed by users recorded (e.g., RUI, video)
Time geography study
Individual records times and changes in location of each individual throughout workday
Tools study
Types of tools used by individual recorded
Task application, time and duration of tool usage also recorded

20. Typical Observation Techniques (3/6)
Time diary
User log their use of time throughout day
Random recordings of time usage set off by beeper on watch
Communication diary
User log each communication and purpose of communication
Context Inquiry
Observer in context
Better for higher level than lower level TA

21. Master-Apprentice model (4/6)
Master–Apprentice model allows user to teach us what they do!
Master does the work and talks about it while working
Skill knowledge is usually tacit (can’t put it in books)
Studying many tasks, the designer can abstract away
Sometimes literal apprenticeship by analyst is best

22. Principles: interpretation (5/6)
Good facts are only the starting point
designs based on interpretations
Validate & rephrase
run interpretations by user and other stakeholder to see if you are right
share ideas to check your reasoning (walk the chain back)
people may be, should be uncomfortable until the phrasing is right
need to be committed to hearing what the user is really saying
Keep in mind descriptive vs. prescriptive results
Explain descriptive vs. perscriptive results

23. Be creative (6/6)
Ask novice to perform task under user’s direction and observe corrections
Change information in the environment to nonsense information and ask user to perform task [this will tell where they look for help]
Remove suspected misinformation from the environment and ask user to perform task - measure time differential

24. Ways to find out 3 of 4. Study Similar or Competing Products
Borrow and Steal

25. Study Similar or Competing Products (1/1)
Incorporate features you like
Don’t just do something because your competitor does
May not be anything similar
Borrow ideas from other areas
Run usability studies on competitors' products

26. Ways to find out 4 of 4. Unsolicited Comments
Users telling you what they want

27. Unsolicited User Comments (1/1)
Effective when updating an existing product
Keep track of frequency of comments
Information that is readily available
Internet comments
Suggestions fostered by offering incentives
User hotline conversations
Don’t believe everything users say
Confirm usefulness of suggestions with other techniques
Large variance in quality of these comments

28. Conclusion: Questions to Answer

29. The Task Analysis Questions (1/2)
Who is going to use the system?
What tasks do they now perform?
What tasks are desired?
How are the tasks learned?
Where are the tasks performed?
What’s the relationship between user & data?

30. The Task Analysis Questions (2/2)
Advanced questions: (for bonus points, particularly good designs)
What other tools does the user have?
How do users communicate with each other?
How often are the tasks performed?
What are the time constraints on the tasks?
What happens when things go wrong?

31. Best intensions can still produce bad results
Caveats
Best intensions can still produce bad results

32. Caveats of User-Centered Design Techniques
Users are not always right
cannot anticipate new technology accurately
your job is to build system users will want
not system users say they want
be very careful about this (you are outsider)
if you can’t get users interested in your hot idea, you’re probably missing something
Or are too soon
Or, a host of other reasons

33. Summary Best solution is to employ a variety of methods
1. Questionnaires and Interviews
2. Observational studies
3. Examination of competing, or similar products
4. Unstructured user input
Next lecture: more on other methods