Minggu, 18 Januari 2009
Task Analysis
Analyzing and describing how people do their jobs/work
-> Go to their environment
Examine users’ tasks to better understand what they need from interface and how they will use it
Components
Three key components to include in discussing how people work
Activities
Artifacts
Relations
Don’t just focus on computer system artifacts and interactions
Study related processes and objects in the environment that people may use and involve
Example: office env---papers, whiteboards, etc.
Task Analysis Focus
Focus on observable behaviors
What are the practices, methods, steps, objects, …, used?
Observe users, what they do, less so how they do it
Not on internal cognitive state of user
Input & Output
Gather data:
Documentation
Interviews
Observation
Surveys/questionnaires
Automatic data recording/tracking
Represent Data:
Lists, outlines, matrices
Narratives
Hierarchies & Networks
Flow charts
Data to be Gathered
Information about users
Description of environment
Where the tasks will be performed
Major goals of the job
What will result in a successful end state?
User preferences & needs
Before they even start: coffee, pen, notebook, log sheets…
Data to be Gathered …
Tasks & Subtasks:
Physical
Cognitive
Communication
Conditions under which these tasks are done
Results/outcomes of tasks
Requirements to perform task:
Information
Communication with others
Equipment
Data Gathering Tools: Docs
Documentation
Often contains description of how the tasks should be done (rather than how they are currently being done)
Standards
Manuals
Histories
Best Practices
Domain Expert Description
Expert describes how process should work, how tasks should be done
“Knowledge-based” discovery
DGT: Interviews
Interviews:
Structured
Efficient
Require training
Unstructured
Inefficient
No training
Semi-structured
Good balance
Often appropriate
Semi-structured Interviews
Predetermine data of interest
Plan for effective question types
How do you perform task x?
Why do you perform task x?
Under what conditions do you perform task x?
What do you do before you perfom…?
What information do you need to…?
Who do you need to communicate with to…?
What do you use to…?
What happens after you…?
What is the result or consequence of…?
What is the result or consequence of NOT…?
See: Gordon & Gill, 1992; Graesser, Lang, & Elofson, 1987
DGT: Observation
Observation
In situ, watch users do what they do
Record with videotape
To watch later, or again
Take lots of notes, sketches
May require coding the video later
Focus on specific task-relevant behaviors in notes, but later convert to abstract subtasks
DGT: Questions
Questions & Answers
Questionnaires
Exploratory vs. confirmatory
Open-ended vs. categorical (exhaustive)
What do you need to perform..? (list)
Which of the following is most important to perform…? (select)
If you ask it, use it. If you won’t/can’t use it, don’t ask it.
DGT: Think-aloud
Questions & Answers, cont’d…
Think-aloud protocol
Person talks about what they are doing, while they are doing it (or just before or after)
Observer can ask probe questions
Why did you just do that?
Note: Probe questions affect performance, as does thinking aloud.
DGT: Logging
Automatic tracking
Keystroke/mouse click monitoring
Timers
Logs
Physical location/movement trackers
Cell phones
Aware Home
Representing Data: Outlines
Lists, outlines, matrices
Use expanding/collapsing outline tool
Add detail progressively
Know in advance how much detail is enough
Can add linked outlines for specific subtasks
Good for sequential tasks
Does not support parallel tasks well
Does not support branching well
Example, next slide
Task Outline
Using a lawnmower to cut grass
Step 1. Examine lawn
Make sure grass is dry
Look for objects laying in the grass
Step 2. Inspect lawnmower
Check components for tightness
Check that grass bag handle is securely fastened to the grass bag support
Make sure grass bag connector is securely fastened to bag adaptor
Make sure that deck cover is in place
Check for any loose parts (such as oil caps)
Check to make sure blade is attached securely
Check engine oil level
Remove oil fill cap and dipstick
Wipe dipstick
Replace dipstick completely in lawnmower
Remove dipstick
Check that oil is past the level line on dipstick
…
RD: Narratives
Narratives
Describe tasks in sentences
Often expanded version of list or outline
More effective for communicating general idea of task
Not effective for details
Not effective for branching tasks
Not effective for parallel tasks
RD: Hierarchies
Hierarchical Task Analysis (HTA)
Graphical notation & decomposition of tasks
Tasks as sets of actions
Tasks organized into plans
Clusters of subtasks with a preferred order and prerequisite conditions
Example Task Clusters
Fixed sequence
Optional tasks
Waiting events
Cycles
Time-sharing
Discretionary
RD: Networks
Network / Entity-Relationship Diagrams
Objects/people with links to related objects
Stress relationship between objects and actions
Links described functionally and in terms of strength
Task: Develop design for final project
objects - pens, paper, drawing tools, etc.
actors - Mary, Bob, Sally
composite objects - the “team”
Methodology
Often list attributes, actions of objects
RD: Flow Charts
Flow Chart of Task Steps
Combines Entity-relationship (network) with sequential flow, branching, parallel tasks.
Includes actions, decisions, logic, by all elements of the system
Abstracted
Mature, well-known, good tools
Flow Chart
Summary of Task Analysis
Determine the data you need
Gather it using various appropriate methods and techniques
Represent the tasks and subtasks, plus other related information
Use this data to improve design
Note: Be efficient!
-> Go to their environment
Examine users’ tasks to better understand what they need from interface and how they will use it
Components
Three key components to include in discussing how people work
Activities
Artifacts
Relations
Don’t just focus on computer system artifacts and interactions
Study related processes and objects in the environment that people may use and involve
Example: office env---papers, whiteboards, etc.
Task Analysis Focus
Focus on observable behaviors
What are the practices, methods, steps, objects, …, used?
Observe users, what they do, less so how they do it
Not on internal cognitive state of user
Input & Output
Gather data:
Documentation
Interviews
Observation
Surveys/questionnaires
Automatic data recording/tracking
Represent Data:
Lists, outlines, matrices
Narratives
Hierarchies & Networks
Flow charts
Data to be Gathered
Information about users
Description of environment
Where the tasks will be performed
Major goals of the job
What will result in a successful end state?
User preferences & needs
Before they even start: coffee, pen, notebook, log sheets…
Data to be Gathered …
Tasks & Subtasks:
Physical
Cognitive
Communication
Conditions under which these tasks are done
Results/outcomes of tasks
Requirements to perform task:
Information
Communication with others
Equipment
Data Gathering Tools: Docs
Documentation
Often contains description of how the tasks should be done (rather than how they are currently being done)
Standards
Manuals
Histories
Best Practices
Domain Expert Description
Expert describes how process should work, how tasks should be done
“Knowledge-based” discovery
DGT: Interviews
Interviews:
Structured
Efficient
Require training
Unstructured
Inefficient
No training
Semi-structured
Good balance
Often appropriate
Semi-structured Interviews
Predetermine data of interest
Plan for effective question types
How do you perform task x?
Why do you perform task x?
Under what conditions do you perform task x?
What do you do before you perfom…?
What information do you need to…?
Who do you need to communicate with to…?
What do you use to…?
What happens after you…?
What is the result or consequence of…?
What is the result or consequence of NOT…?
See: Gordon & Gill, 1992; Graesser, Lang, & Elofson, 1987
DGT: Observation
Observation
In situ, watch users do what they do
Record with videotape
To watch later, or again
Take lots of notes, sketches
May require coding the video later
Focus on specific task-relevant behaviors in notes, but later convert to abstract subtasks
DGT: Questions
Questions & Answers
Questionnaires
Exploratory vs. confirmatory
Open-ended vs. categorical (exhaustive)
What do you need to perform..? (list)
Which of the following is most important to perform…? (select)
If you ask it, use it. If you won’t/can’t use it, don’t ask it.
DGT: Think-aloud
Questions & Answers, cont’d…
Think-aloud protocol
Person talks about what they are doing, while they are doing it (or just before or after)
Observer can ask probe questions
Why did you just do that?
Note: Probe questions affect performance, as does thinking aloud.
DGT: Logging
Automatic tracking
Keystroke/mouse click monitoring
Timers
Logs
Physical location/movement trackers
Cell phones
Aware Home
Representing Data: Outlines
Lists, outlines, matrices
Use expanding/collapsing outline tool
Add detail progressively
Know in advance how much detail is enough
Can add linked outlines for specific subtasks
Good for sequential tasks
Does not support parallel tasks well
Does not support branching well
Example, next slide
Task Outline
Using a lawnmower to cut grass
Step 1. Examine lawn
Make sure grass is dry
Look for objects laying in the grass
Step 2. Inspect lawnmower
Check components for tightness
Check that grass bag handle is securely fastened to the grass bag support
Make sure grass bag connector is securely fastened to bag adaptor
Make sure that deck cover is in place
Check for any loose parts (such as oil caps)
Check to make sure blade is attached securely
Check engine oil level
Remove oil fill cap and dipstick
Wipe dipstick
Replace dipstick completely in lawnmower
Remove dipstick
Check that oil is past the level line on dipstick
…
RD: Narratives
Narratives
Describe tasks in sentences
Often expanded version of list or outline
More effective for communicating general idea of task
Not effective for details
Not effective for branching tasks
Not effective for parallel tasks
RD: Hierarchies
Hierarchical Task Analysis (HTA)
Graphical notation & decomposition of tasks
Tasks as sets of actions
Tasks organized into plans
Clusters of subtasks with a preferred order and prerequisite conditions
Example Task Clusters
Fixed sequence
Optional tasks
Waiting events
Cycles
Time-sharing
Discretionary
RD: Networks
Network / Entity-Relationship Diagrams
Objects/people with links to related objects
Stress relationship between objects and actions
Links described functionally and in terms of strength
Task: Develop design for final project
objects - pens, paper, drawing tools, etc.
actors - Mary, Bob, Sally
composite objects - the “team”
Methodology
Often list attributes, actions of objects
RD: Flow Charts
Flow Chart of Task Steps
Combines Entity-relationship (network) with sequential flow, branching, parallel tasks.
Includes actions, decisions, logic, by all elements of the system
Abstracted
Mature, well-known, good tools
Flow Chart
Summary of Task Analysis
Determine the data you need
Gather it using various appropriate methods and techniques
Represent the tasks and subtasks, plus other related information
Use this data to improve design
Note: Be efficient!
Design of Everyday Things
Agenda
Discuss Norman’s views on HCI & design
Discussion
What did you take away from DOET book
Daily Challenges
How many of you can use all the functionality in your
VCR
Digital watch
Copy machine
Stereo system
Plumbing fixtures
Fun Examples
Leitz slide projector
To move forward, short press
To move backward, long press
What happens when you get frustrated?
Fun Examples
Fun Examples
Changing Ringer Volume
Press “Program”
Press “6”
Set volume
Low - Press “1”
Medium - Press “2”
High - Press “3”
Press “Program”
Important Concepts
Affordances
Visibility
Conceptual models
Mapping
Feedback
Constraints
Visual Affordances
Perceived and actual fundamental properties of an object that determine how it could be used
Chair is for sitting
Ball is for throwing
Button is for pushing
Yikes!
Mantra
Complex things may need explanation, but simple things should not
If a simple thing requires instructions and pictures, it is likely a failed design
Designing for People
Norman’s 2 main principles
Provide a good conceptual model
Make things visible
Conceptual Models
People build their own systems of how things work
Example - car
Designer can help user foster an appropriate conceptual model
Appearance, instructions, behavior...
Visibility
When functionality is hidden, problems in use occur
Occurs when number of functions is greater than number of controls
When capabilities are visible, it does not require memory of how to use
Remind person how to use something
Simple Example
Simple Example
Bathroom faucets
Two functions
Hot/cold
Pressure
Bathroom Faucets 1
Bathroom Faucets 2
Bathroom Faucets 3
Two Important Principles
Mapping
Feedback
Mapping
What does this means
Relationship between two objects, here, between control and action/result
Good:
Car, various driving controls
Mercedes Benz seat adjustment example
Bad
Car stereo - Knob for front/back speakers
Stove
Yikes!
Why Not Design Better
Stove
Speakers
Feedback
Let someone know what just occurred
Can be sound that’s made
Can be change in physical state
Constraints
Limitations on what can be done
Physical - keys
Semantic - menu graying
Cultural - Colors
Logical - When all above don’t apply
Individual Differences
Whom do you design for?
Everyone? Impossible
Average? Excluding half audience
95%? Still may miss a lot
Can’t accommodate everyone
Individual Differences
Designers are not representative of the user population for whom they are designing
Don’t expect users to think or act like you
People vary in both physical attributes and mental/cognitive attributes
Example
Why Design is Hard
Number of things to control has increased dramatically
Displays are more virtual/artificial
Marketplace pressure
Adding operations cheaper (computers)
Adding controls expensive (real estate, cost)
Errors are becoming increasingly serious
Try and Try Again
Norman thinks that it often takes 5 or 6 tries to get something “right”
Simply may not have that luxury in a competitive business environment
Discuss Norman’s views on HCI & design
Discussion
What did you take away from DOET book
Daily Challenges
How many of you can use all the functionality in your
VCR
Digital watch
Copy machine
Stereo system
Plumbing fixtures
Fun Examples
Leitz slide projector
To move forward, short press
To move backward, long press
What happens when you get frustrated?
Fun Examples
Fun Examples
Changing Ringer Volume
Press “Program”
Press “6”
Set volume
Low - Press “1”
Medium - Press “2”
High - Press “3”
Press “Program”
Important Concepts
Affordances
Visibility
Conceptual models
Mapping
Feedback
Constraints
Visual Affordances
Perceived and actual fundamental properties of an object that determine how it could be used
Chair is for sitting
Ball is for throwing
Button is for pushing
Yikes!
Mantra
Complex things may need explanation, but simple things should not
If a simple thing requires instructions and pictures, it is likely a failed design
Designing for People
Norman’s 2 main principles
Provide a good conceptual model
Make things visible
Conceptual Models
People build their own systems of how things work
Example - car
Designer can help user foster an appropriate conceptual model
Appearance, instructions, behavior...
Visibility
When functionality is hidden, problems in use occur
Occurs when number of functions is greater than number of controls
When capabilities are visible, it does not require memory of how to use
Remind person how to use something
Simple Example
Simple Example
Bathroom faucets
Two functions
Hot/cold
Pressure
Bathroom Faucets 1
Bathroom Faucets 2
Bathroom Faucets 3
Two Important Principles
Mapping
Feedback
Mapping
What does this means
Relationship between two objects, here, between control and action/result
Good:
Car, various driving controls
Mercedes Benz seat adjustment example
Bad
Car stereo - Knob for front/back speakers
Stove
Yikes!
Why Not Design Better
Stove
Speakers
Feedback
Let someone know what just occurred
Can be sound that’s made
Can be change in physical state
Constraints
Limitations on what can be done
Physical - keys
Semantic - menu graying
Cultural - Colors
Logical - When all above don’t apply
Individual Differences
Whom do you design for?
Everyone? Impossible
Average? Excluding half audience
95%? Still may miss a lot
Can’t accommodate everyone
Individual Differences
Designers are not representative of the user population for whom they are designing
Don’t expect users to think or act like you
People vary in both physical attributes and mental/cognitive attributes
Example
Why Design is Hard
Number of things to control has increased dramatically
Displays are more virtual/artificial
Marketplace pressure
Adding operations cheaper (computers)
Adding controls expensive (real estate, cost)
Errors are becoming increasingly serious
Try and Try Again
Norman thinks that it often takes 5 or 6 tries to get something “right”
Simply may not have that luxury in a competitive business environment
Sabtu, 17 Januari 2009
Langganan:
Postingan (Atom)