Affinity Diagram - PowerPoint

Report as inappropriate Your report has been received

Shared by: HC120913193439

Tags

Stats

views:: 20
posted:: 9/13/2012
language:: English
pages:: 28

Public Domain

Document Sample

Human Factors in Design
 The human factors engineering process
 Research
 Human capabilities
 Human activities
 Modeling
 Human-system interaction
 Define requirements
 Information flows
 Actions
 Design
 Evaluation
 This is an iterative process
ISE 412 - 5 1
Tools of HF Design
 Design data:
 anthropometric data, design data compendiums,
standards, principles & guidelines, etc.
 e.g., Human Engineering Design Data Digest,
Department of Defense Human Factors Engineering
Technical Advisory Group (April 2000).
 Research methods
 Modeling
 Define Requirements
 Based on Models and engineering analysis methods
 Workload, safety, simulation, etc.
 Use to derive system requirements
ISE 412 - 5 2
Building Models
 Part 1: Models good for defining system and user
requirements
 Affinity diagrams
 Flow model
 Cultural model
 Sequence model
 Physical model
 Artifact model
 Source:
H. Beyer and K. Holtzblatt (1999), Contextual Design : A Customer-Centered
Approach to Systems Designs. San Francisco, CA: Morgan Kaufmann.
Note: for more details on the following example, you should visit the
InContext website at www.incent.com and choose the “Design Resources”
link at the top, then to “CDTools™,” then “CDTools™ Resources,” and finally
“Shopping Data Browser” on the left.
ISE 412 - 5 3
Affinity Diagram – a good starting point
 Use the Post-It notes to record insights and quotes
from your observations and interviews.
 One phrase or quote per note.
 Write big enough for all to see.
 Post the notes on the wall.
 “Walk the wall” and rearrange the notes into like
categories.
 When everyone is agreed on the categories, give
each category a meaningful name and summarize
the findings.
 Use the affinity diagram to generate design ideas,
identify requirements, and inform other models.
ISE 412 - 5 4
Affinity Diagrams – “Walk the Wall”
The net makes
the remote
present to me

Being exposed
to a big,
unknown set of
people is scary

I like being able I want to control I don’t want to
to look without
presenting who is in touch stick my neck
myself with me out

U2 229. Browsing
U3 325. Conscious U3 331. Afraid of
web doesn't require
decision about who what she’ll get back
you to present
to be in contact with if she posts here
yourself, like
over email—sense of email address to get
explaining yourself
power specific info
over the phone
D1 19. She checks D3 201. The rules U2 236. Has a sense
all her sources that about relating on the of ethics on the net -
will maintain her web are unclear- the won’t search for *.edu
confidentiality before address says you can email addresses, only
calling the company write, but then people uses to look up
directly don’t write back. particular names
U2 230. Sales
contacts require
gearing yourself up —
exhausting if you don’t
get through — email
doesn’t require that
ISE 412 - 5 5
Flow Model
 Draw the primary user of the system in the
center of the page.
 Use Post-It notes to add other users, people,
“roles,” and physical objects as needed to
define flows of work and information.
 Use annotated lines and arrows to indicate
flows of information or work.
 Indicate opportunities for “breakdowns” in
communications or work flow.
 Use the model to add to or refine
requirements, define key interactions, and
identify communication modes and methods.
ISE 412 - 5 6
Flow Model example

ISE 412 - 5 7
Cultural Model
 Draw a circle representing the primary user in
center.
 Draw overlapping and concentric circles
representing other entities that affect the primary
user.
 Draw arrows indicating influences, constraints,
and expectations.
 Identify individual and pervasive values that
affect how the user will approach the task.
 Use the model to define subtleties that should
affect system design.

ISE 412 - 5 8
An example of a Cultural Model
Corporation

User Department

User

System Manager
Group Equipment Vendor

System
Help
Line Manager
I
thought Coworker
you would
do it

Expert Support
Remote Operator
Problem Handling System
Agencies Management
ISE 412 - 5 9
Sequence Model
 Define specific steps the user goes through to
accomplish the task.
 Identify strategies and decision points.
 Identify breakdowns that make the task difficult
to complete.
 Where appropriate, identify options and
alternative strategies.
 Use the model to further define requirements,
identify design opportunities, and begin to define
potential interaction methods.
 (We’ll come back to this later …)
ISE 412 - 5 10
Physical Model
 Diagram in detail the physical space in which the
task is performed.
 Identify both “official” and “unofficial” designation
of locations.
 Identify paths taken through the space during task
performance.
 Define how users use the space to accomplish
the task.
 Identify breakdowns where the physical space
inhibits task performance.
 Use the model to develop system design
requirements and opportunities.
ISE 412 - 5 11
Physical Model

ISE 412 - 5 12
Artifact Model
 Draw or diagram the artifacts used to
accomplish the task.
 Specify the user’s intent in using the artifact.
 If necessary, identify variants of the artifacts.
 Identify potential breakdowns where the artifact
inhibits task performance.
 Use the model to define user requirements and
identify potential design directions.

ISE 412 - 5 13
Artifact Model

ISE 412 - 5 14
Building Models
 Part 2: Models good for defining interaction
 HTA
 GOMS
 OFM

 Process
 Step 1: develop an understanding of the user and task
(interviews, questionnaires, observation, etc.)
 Step 2: decide on a modeling framework
 Step 3: build the model
 Step 4: test/refine/modify
 (Step 5: Use the model to drive design, testing, etc.)

ISE 412 - 5 15
Making a PBJ sandwich: Hierarchical
Task Analysis (HTA)
1. Describe top-level goal:
 “0. Make a peanut butter and jelly sandwich.”
2. Develop a plan for achieving that goal (including “error
handling”):
 Plan 0: Do 1-5, in order. If some ingredient is missing, do 5.
 “1. Get plate and knife.
 2. Collect ingredients.
 3. Assemble sandwich.
 4. Eat and enjoy.
 5. Put ingredients away.”

ISE 412 - 5 16
Making a PBJ sandwich: Hierarchical
Task Analysis (HTA)
Plan 0: Do 1-5 in order;
0. Make a pbj
if some ingredient is missing, skip to 5.

1. Get plate & knife 2. Collect ingredients 3. Assemble sandwich 4. Eat & enjoy 5. Put everything away.

3. For each step in the plan, decide if more detail is required.
Continue until sufficient detail is defined.
e.g., for step 1 …
 Plan 1: Do 1-3; if no clean implements, do 4.
 1.1 Go to cabinet and retrieve 1 plate.

 1.2 Go to drawer and retrieve 1 knife.

 1.3 Take knife and plate to table.

 1.4 Wash knife/plate as necessary.

ISE 412 - 5 17
Your turn …
 Continue the HTA for:
 Plan 2

 Plan 3

 Plan 5

 Discuss – which parts of your plan need more
specification?

ISE 412 - 5 18
Making a PBJ sandwich: GOMS (Goals,
Operators, Methods, & Selection rules)
1. Describe top-level goal:
 “GOAL: Make a peanut butter and jelly sandwich.”
2. Describe a methods for achieving that goal (including
selection rules and alternatives):
 GOAL: Get plate and knife.
 GOAL: Collect ingredients.
 GOAL: Assemble sandwich.
 Eat and enjoy.
 GOAL: Put ingredients away.

ISE 412 - 5 19
Making a PBJ sandwich: GOMS
3. For each “GOAL” in the method, describe a more detailed
method.
e.g., • GOAL: Collect ingredients.
• • GOAL: Get bread.
• • GOAL: Get peanut butter.
• • GOAL: Get jelly.
• • • [Selection Rule:
Goto refrigerator
Goto pantry ]

ISE 412 - 5 20
Making a PBJ sandwich: GOMS
4. Continue until desired/necessary level of detail.

5. Use the (HTA or GOMS) model to:
 Design documentation.
 Predict performance.
 Evaluate device/task designs.
 Design.

ISE 412 - 5 21
Modeling more complex tasks: the
Operator Function Model (OFM)
 Hierarchical/Heterarchical task decomposition
 Activities are decomposed hierarchically (as in HTA and GOMS)
 Functions - highest-level activities (e.g., navigate, communicate, and
aviate are pilot functions)
 Subfunctions - activities required to accomplish functions
 Task - lower level (more specific) activities to accomplish functions
or subfunctions
 Actions - manual, cognitive, or perceptual
 Heterarchical structure accounts for concurrent activities, usually
defined at the same level.
 Operators may choose from among these activities or the activities
may result from system state(s).

ISE 412 - 5 22
OFM example: Chinese dinner party
Steps (from Mitchell, 1998):
1. “Prepare a high-level written description of the system
of interest …”

ISE 412 - 5 23
OFM example: Chinese dinner party
Steps (from Mitchell, 1998):
2. Identify the high-level activities the operator performs.

3. Define the heterarchy, specifying conditions for
transitioning, initiating, or terminating activities.

ISE 412 - 5 24
OFM example: Chinese dinner party
4. Define the hierarchy, including conditions that start or
end activities.
5. Validate the model. (Emphasis on direct observation,
mapping actions into the model, resolving
discrepancies.)
6. Refine the model as the system evolves.

ISE 412 - 5 25
Summary: User/Task Modeling
 What is a user/task model?
 Model - “a mathematical/physical system, obeying specific
rules and conditions, whose behavior is used to understand
a real (physical, biological, human-technical, etc.) system to
which it is analogous in certain respects.”(Bailey, 1989)
 A “good model” is one that adequately represents and can
be used to generate testable hypotheses about the
underlying system.
 User/task models - specifically focus on modeling the user’s
goals and objectives, as well as his/her understanding of the
task.

ISE 412 - 5 26
Summary: User/Task Modeling
 Dimensions of models …
 Conceptual ………………. Computational

 Descriptive ………………..Normative

 Levelsof specificity
 Device …..….. task ……... meta-cognitive

ISE 412 - 5 27
Using Models in System Design
Define
Research Model Design Evaluation
Req’ts.

 DESIGN IS AN ITERATIVE PROCESS!!
 A basis for defining requirements
 Identify information and action requirements, as well as
potential sources of difficulty for the operator/user (high
workload, ambiguities, etc.), task importance, who else is
involved, etc.
 The more detailed the model, the more useful for design
 A basis for test & evaluation
 Heuristic evaluation – does the system as designed support
the activity you modeled?
 Defining testing procedures, metrics, etc.
ISE 412 - 5 28