Task Analysis Methods

IST 331. 20 Oct 2014

1

Example HTA• 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.

2

1.Login1.Select login screen2.Enter ID3.Enter password

2.Choose objects1.Browse listing2.Select item

3.Pay1.Choose pay screen2.Select payment method3.Enter payment method details

4. Plan: Task 1, then Taks 2 as many times as needed then Task 3.

Example HTA

3

1.Login1.Select Login screen

1. Move mouse to “ID”2. Click mouse

2.Enter ID1. Type ID2. Enter “CR”

3.Enter Password1a.Move mouse to “Password”OR1b.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

Task Analysis Methods:

• Lots of task analysis methods• 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

4

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

March 14th, 2011

GOMS and KLM

• Goals, Operators, Methods, and Selection rules– Like a program

• Keystroke-level model– Like a trace

• 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

6

7

Who?

• Identity?– In-house or specific customer is easy– Need several typical customers for broad product

• Background• Skills• Work habits and preferences• Physical characteristics

– Height?

March 14th, 2011

8

Talk to Them

• Find some real customers• Talk to them

– Find out what they do– How would your system fit in

• Are they too busy?– Buy their time

• T-shirts, coffee mugs, etc.

March 14th, 2011

1/4. Questionnaires and interviews

9

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

10

Questionnaires & Interviews (2/6)

• Keep the number of questions low– Only questions with answers that you can’t get

other ways– Only questions that will have a direct impact on

functional requirements– Avoid asking for everything

11

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?

12

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?

13

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

14

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

15

2/4. Observation Studies as a way to get TA information

Iterative

16

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?

17

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

18

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

19

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

20

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 will 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

21

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

• Remove suspected information from the environment and ask user to perform task - measure time differential

22

3/4. Study Similar or Competing Products

Barrow and Steal

23

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

24

4/4. Unsolicited Comments

Users telling you what they want

25

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

26

Conclusion:

Questions to Answer

27

The Task Analysis Questions (1/2)

1. Who is going to use the system?2. What tasks do they now perform?3. What tasks are desired?4. How are the tasks learned?5. Where are the tasks performed?6. What’s the relationship between user & data?

28

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?

29

Caveats

Best intensions can still produce bad results

30

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

31

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

32