0% found this document useful (0 votes)
12 views38 pages

Lecture 8

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
12 views38 pages

Lecture 8

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 38

Human Computer Interaction

IE403

Dr. Manish Khare

Lecture – 8
A generalized Cognitive Model

 Learnability: Execution side


 Visibility & Feedback :
Evaluation side
 Efficiency: Measure of whole
cycle, speed of execution and
perception
 What I did Vs What just
happened Vs What is it I
am going to
see/experience?

Slide 2
GoEv Vs GoEx

The Gulf of Execution (GoEx) is


• the difference between the intentions of the users
and what the system allows them to do
• how well the system supports those actions

https://www.educative.io/edpresso/gulf-of-execution-and-gulf-of-evaluation

The Gulf of Evaluation (GoEv) is


• the level of difficulty in assessing the
state of a system
• how well the artifact supports the
discovery and interpretation of that
state

Slide 3
How designers can bridge the Gulf?

 Bridge gulf of execution by:


 Signifiers, constraints,
 mapping, conceptual model
 Bridge gulf of evaluation by:
 Feedback, conceptual model
 Help users answer these →
 questions
 7 questions; 7 stages

Slide 4
ATM Machine –Cognitive & Mental model

Slide 5
Learnable
I nterface
Smaller GoEx & GoEva

Easier to execute

Slide 6
Recognition Vs Recall

Recognition:
 remembering with the help of a
clue
 “using knowledge in or of the
world

Recall:
 Remembering with no help
 “using knowledge in the
head”
 How much do we remember?

Slide 7
Donald Norman’s model

 Seven stages
 user establishes the goal
 formulates intention
 specifies actions at interface
 executes action
 perceives system state
 interprets system state
 evaluates system state with respect to goal

 Norman’s model concentrates on user’s view of the interface

Slide 8
execution/evaluation loop

goal

execution evaluation
system
 user establishes the goal
 formulates intention
 specifies actions at interface
 executes action
 perceives system state
 interprets system state
 evaluates system state with respect to goal

Slide 9
execution/evaluation loop

goal

execution evaluation
system
 user establishes the goal
 formulates intention
 specifies actions at interface
 executes action
 perceives system state
 interprets system state
 evaluates system state with respect to goal

Slide 10
execution/evaluation loop

goal

execution evaluation
system
 user establishes the goal
 formulates intention
 specifies actions at interface
 executes action
 perceives system state
 interprets system state
 evaluates system state with respect to goal

Slide 11
execution/evaluation loop

goal

execution evaluation
system
 user establishes the goal
 formulates intention
 specifies actions at interface
 executes action
 perceives system state
 interprets system state
 evaluates system state with respect to goal

Slide 12
The process of design

scenarios
what is task analysis
wanted guidelines
principles
interviews analysis precise
ethnography specification
design
what is there
vs. dialogue implement
what is wanted notations and deploy
evaluation
prototype
heuristics architectures
documentation
help

Slide 13
Task Analysis

Slide 14
Recap

 Don Norman’s principles


 Conceptual Vs Mental Models
 Gulf of Evaluation Vs Gulf of Execution

Slide 15
Norman’s 7 stages of Actions

Questions GOAL EXECUTION EVALUATION

What do I want to
accomplish?
What are my alternatives?

What can I do now?


How do I do it?
What happened?
What does it mean?
Is it OK? Have I
accomplished my goal?

Slide 16
Making Coffee in a Brewer

Questions GOAL EXECUTION EVALUATION

What do I want to accomplish?

What are my alternatives?

What can I do now?


How do I do it?
What happened?
What does it mean?
Is it OK? Have I accomplished my
goal?

Slide 17
Task Analysis

How to go wrong doing/asking users to do a task(s)?

Slide 18
Task Analysis
Task Analysis is the study of the way people perform their jobs.
Aim is to determine:
o what they do
o what things they use
o what they must know

Slide 19
Example

For example, a person preparing an overhead projector for use would be seen
to carry out the following actions :
1. Plug in to main and switch on supply.
2. Locate on/off switch on projector
3. Discover which way to press the switch
4. Press the switch for power
5. Put on the slide and orientate correctly
6. Align the projector on the screen
7. Focus the slide

Slide 20
Example

Task: to clean the house


o get the vacuum cleaner out
o fix the appropriate attachments
o clean the rooms
o when the dust bag gets full, empty it
o put the vacuum cleaner and tools away
Must know about:
o vacuum cleaners, their attachments, dust bags,
o cupboards, rooms etc.

Slide 21
general method

observe

collect unstructured lists of words and actions

organize using notation or diagrams

Slide 22
Differences from other techniques
Systems analysis vs. Task analysis

system design - focus - the user

Cognitive models vs. Task analysis

internal mental state - focus - external actions

practiced `unit' task - focus - whole job

Slide 23
What is a Tasks?

«A task is a goal together with some ordered set of actions.»

Goal •A state of the application domain that a work system (user+technology) wishes to achieve
•Specified at particular levels of abstraction

•A structured set of activities required, used, or believed to be necessary by an agent (human,

Task machine) to achieve a goal using a particular technology


•The task is broken down into more and more detailed levels of description until it is defined in terms of
actions

Action
•An action is a task that has no problem solving associated with it and which does not include any
control structure
•Actions are ‘simple tasks’

Slide 24
What you learn with Task Analysis

What your users’ goals are; what they are trying to achieve
What users actually do to achieve those goals
What experiences (personal, social, and cultural) users bring to the tasks
How users are influenced by their physical environment
How users’ previous knowledge and experience influence:
o How they think about their work
o The workflow they follow to perform their tasks

Slide 25
Why is it useful?

Task analysis is the process of learning about ordinary users by observing


them in action to understand in detail how they perform their tasks and
achieve their intended goals.
Tasks analysis helps in
o Identifying the tasks that your website and applications must support
o Refining or re-defining your site’s navigation or search
o Website requirements gathering
o Developing your content strategy and site structure
o Wireframing and Prototyping
o Performing usability testing

10

Slide 26
Example

Tasks are used to plan for the layout


of the application window
Proximity and Boundaries reflect the
decomposition of tasks
Order of tasks is not mandatory

11

Slide 27
Where it fits

Documentation Observation Interviews

• Extract information
Task Analysis • Sort and classify
• Iterate and refine

Manuals and Requirements ans Detailed interface


Documentation systems design design
• Conceptual Manuals (from KBA) • Focus on system usage rather than • Taxonomies → menu layout
• Procedural (how-to) Manuals (from system features • Objects/actions → interface
HTA) • Suggests candidates for automation objects
• Unconvers user’s conceptual model • Task frequency → default choices

12

Slide 28
[Some] Techniques for Analysis
Task decomposition − Splitting tasks into sub-tasks and their ordering.
Knowledge-based techniques − Any information and instructions that users
need to know, and how that knowledge is organized
Entity-relationship-based analysis – identify actors, objects, relationships and
their actions
Ethnography − Observation of users’ behavior in the use context.
Protocol analysis − Observation and documentation of actions of the user.
This is achieved by authenticating the user’s thinking. The user is made to
think aloud so that the user’s mental logic can be understood.

13

Slide 29
Hierarchical Task Analysis

14

Slide 30
Hierarchical Task Analysis (HTA)

One possible method for Task Decomposition


Hierarchical Task Analysis is the procedure of disintegrating tasks into
subtasks that could be analyzed using the logical sequence for execution. This
would help in achieving the goal in the best possible way.

"A hierarchy is an organization of elements that, according


to prerequisite relationships, describes the path of
experiences a learner must take to achieve any single
behavior that appears higher in the hierarchy. (Seels &
Glasgow, 1990, p. 94)".

15

Slide 31
Example HTA: How to clean a house

A hierarchy of tasks and sub-tasks


o Indentation and numbering
denote the levels
A set of plans describing in what
order and under what conditions
subtasks are performed
o Plans are labeled by the task they
describe

16

Slide 32
Notes

Not all tasks are mandatory


o E.g., task 4 is needed only if the
bag is full.
The order or operations may be free
o E.g., the rooms may be cleaned in
any order
Could be further refined with
additional knowledge or context
o E.g.,

Slide 33
Expanding the hierarchy

Each task is de-composed in sub- Procedural task knowledge


tasks, iteratively and recursively elicitation techniques:
o Answer to the question: «what o Observation, re-enactment
subtasks must be accomplished in o Ask about procedures and
order to perform the main triggers (pre-conditions)
task?» o “What happens if X goes wrong?”
o The answer will come from direct o Sorting steps into appropriate
observation, expert opinion, orders
documentation, …

18

Slide 34
When is this process stopped?
o Depends on the intended usage
of the HTA (design vs
documentation vs
troubleshooting vs …)
o Expand only relevant tasks
o «Simple» tasks should be obvious
to the users, and they should not
contain hidden risks of failure
o Motor actions are the lowest
level (not always needed)

19

Slide 35
Example
Plan for the main
goal

Drawing hierarchy
relationships

Plan for a sub-


task
The line says «we stop
decomposition»

20

Slide 36
Tasks as explanation

Imagine asking the user the question:


o What are you doing now?
For the same action the answer may be:
o typing ctrl-B
o making a word bold o
emphasising a word o
editing a document o
writing a letter
o preparing a legal case

21

Slide 37
Refining the HTA

Checking matched actions


o Turn “off” without turning “on”?
Restructuring
o “Make pot” might be a meaningful
task and group related actions
Balancing complexity
o Is “pour tea” simpler than “make pot”?
Generalizing
o If we want to make one or more
cups?

22

Slide 38

You might also like