Task Analysis: Techniques and Principles for Understanding User Behavior - Prof. Thomas Ho, Study notes of Computer Science

Download Task Analysis: Techniques and Principles for Understanding User Behavior - Prof. Thomas Ho and more Study notes Computer Science in PDF only on Docsity!

CS3205: Spring 2011

Task Analysis and

Techniques

Task Analysis

• (^) Same as requirements analysis?
  • (^) Focus on users, not on the proposed

system

• (^) “Earlier” than “traditional” req. analysis
• (^) But lots in common…

Functional Requirements

• (^) See Figure 10.1 -- a classic way of describing functional requirements

Goals vs. Tasks vs. Actions

• (^) Goal
  • (^) end result to be achieved
• (^) Task
  • (^) structured set of related activities

undertaken in a sequence

• (^) Action
  • (^) one step or action performed (part of a

task)

“Doing” Task Analysis

• (^) Different levels of granularity
  • (^) Recognize this.
  • (^) Use methods that can deal with this and capture various levels
• (^) A organizational level: interactions between

multiple people

• (^) Workflow analysis:
  • (^) Describing document/information flow between people
  • (^) Sequence, dependencies

“Doing” Task Analysis (2)

• (^) Specific techniques? Sure! Lots!
• (^) Do you want to:
  • (^) Describe the steps to complete a task?

(What is to be done)

• (^) Capture what knowledge or information

people need to complete a task? (More of

how a user does a task.)

Principles of Good Techniques

• (^) User-centered, not developer centered
  • (^) Say what the user wants to do, not how
  • (^) Avoid UI assumptions
  • (^) Be as specific as possible
    • (^) OK even desirable to talk in examples (see TCUID)
    • E.g. “Bob logs in and searches for backup software for Windows XP under $50”
  • (^) Start by focusing on tasks that meet user end goals (“complete jobs”) - Talk about “searching for items” first, rather than how to enter search criteria - (^) Interaction between activities/tasks are often problems
  • (^) Link users with tasks
    • (^) Use roles or personas

• (^) Task analysis methods should be user-centered
• (^) Many techniques, a well-known on in HCI is Hierarchical Task Analysis (HTA) - (^) But in CS305, others first….

Scenarios

• (^) Is this a formal term or just an informal one?
  • (^) Probably informal
  • In fact, think about how what book says about scenarios is like or unlike XP’s stories
• (^) By one definition, a scenario is:
  • (^) an informal narrative story
  • (^) simple, ‘natural’, personal
  • (^) not generalizable
• (^) Some use term Task Scenario
  • Narrative description of a specific thing done with a current system
  • (^) Like a concrete use-case. (Real, representative)
• (^) See example on next slide and examples in book

XP Stories

• (^) Read this one page! http://www.extremeprogramming.org/rules/userstories.html
• (^) Short description of system behavior
  • (^) From user point of view
  • (^) Written on one index card!
  • (^) Written by developer and customer together
• (^) Note that what the page says:
  • (^) Level of detail: enough to estimate time to implement (in terms of weeks)
  • (^) “Promises for Conversation” with user
  • (^) Focus on user needs
    • (^) Not on algorithms, UI, database details, technology, etc.

Examples of XP Stories

• (^) When a transaction causes a customer’s account to go into overdraft, transfer money from the overdraft protection account, if any.
• (^) Produce a statement for each account, showing transaction date, number, payee, and amount. A sample statement is attached – make the report look something like the sample.
• (^) When the GPS has contact with two or fewer satellites for more than 60 seconds, display the message “Poor satellite contact” and wait for confirmation by the user. If contact improves before confirmation, clear the message automatically.

Pros and Cons for Stories?

• (^) Pros?
  • (^) Simple
  • (^) Able to judge priority
  • (^) Understandable by users, from a user POV
  • (^) Doesn’t commit to design too early
  • (^) Support categories, organization
• (^) Cons?
  • (^) Will need detail. Where? When?
  • (^) Could be vague

Pros and Cons for Stories?

• (^) Note: the following list comes from class discussion
• (^) Pros:
  • Users involved.
  • (^) Fast, easy – low overhead.
  • (^) supports planning, iterative development, measuring progress
• (^) Cons:
  • (^) May not be technically enough to insure it comes out the way the user really wants
  • Do they show related behaviors? interactions?
  • (^) Need to talk to many/several stakeholders
  • (^) What if lots of index cards?!