Learn: human factors exam 1

what is human factors engineering

makes technology work for people

considers the cognitive, physical, and organizational influences on human behavior to improve human interaction with products and processes

three main goals to enhance with HF

safety

performance

satisfaction

high risk domains

optimize safety

performance and satisfaction less of a concern

workplace domain

prioritize performance

then safety and satisfaction

consumer products domain

prioritize satisfaction

then performance and safety

human factors cycle / system design process stages

understand: the users' needs, done pre-design or front-end analysis

create: a product or system, these can be prototypes or pre-production models

evaluate: how well the design meets users' needs (heuristic evaluation, usability testing, system evaluation)

what are the roots of HF engineering

aviation: the flying or operating of aircraft

focus started narrowly with human interaction with physical devices

ex: planes -- more power, more dials, less work for the pilot, more training involved

wide range of employment opportunities after WWII

- making sure products meet human needs at software and computer companies

- making safer, more ergonomic workplaces at large companies and manufacturers

- government agencies

- HF consulting and research firms

six HF design interventions

1. change the task: changes how a task is completed (process oriented, changing what operators do not device)

2. equipment design: changes particular physical equipment

3. environmental design: changes physical environment

4. training: enhancing appropriate knowledge and skills

5. selection: changes team/organization by picking those best for job

6. team and organizational design: changes how groups communicate and relate to each other

three importances of systems

interconnection

adaptation

enviornment

interconnection

complex systems have many interconnected elements so changing one might have a cascading effect

adaptation

often there is unanticipated consequences due to user's behavioral adaptations - designers need to account for adaptation as it emerges

environment

affordances: opportunities for action presented by the environment

signifiers: symbols or cues placed in the environment to highlight available affordances

why is intuition not enough

assumes you and your experiences are representative of all potential users

assumes you know exactly how your mind and body work

learned intution

deep familiarity that might lead a designer to overestimate their users' knowledge or experience using a product

fields closely related to HF

- engineering psychology: understand the human design as it relates to design

- cognitive engineering: focuses on the cognitive considerations particularly in context of safety of complex systems

- macroergonomics: addresses need to considers not just details of particular devices or processes but overall work system, takes broad systems perspective and considers the design of teams and organizations

- human systems integration: broader view considering how designs must consider how people interact with all systems to figure out who is qualified based on demographic trends and training requirements

- human computer interaction (HCI): focus on software not the physical/organizational environment

why is it important to include HF from the very beginning of projects

- once the design is completed it is too late

- puts design team at odds with each other because designer like their work so they can be resistant to necessary changes

- inserting late extends the completion time for the project

vee design process

- used for large, high risk systems (like new aircrafts or cars)

- begins broad and becomes more detailed

- sequential development is possible and verification/validation/documentation are critical

validation: are we building the correct thing?

verification: are we building it correctly?

plan-do-check-act cycle (design process)

- used to enhance work place efficiency and production quality

- plan: describe objectives

- do: product/prototype/process created

- check: assess

- act: (adjust) implementing intervention or developing new plan based on outcomes

scrum design process

- used with consumer software products

- iterative and incremental approach

- well suited for situations that demand high degree of innovation, like technology changing rapidly and potential applications emerge abruptly

integrating HF into design processes

- hybrid approach with different design processes is often necessary

- there is a tradeoff between speed and accuracy with HF methods (fit the design process to the project demands)

human centered design

- the process that ensures that the designs match the needs and capabilities of the people for whom they are intended

- identify important benefits of integrating elements of a device

- avoid unintended consequences

heuristic evaluation

- apply design principles and guidelines to a newly developed prototype

- discover how the design might violate human capabilities

- rapid, approximate, and no user is required

usability testing

- collect data on how end users respond to the system

- provides an understanding on how they will react to a design

- more detailed, precise, may take a lot longer

deployment and post release surveillance

- system may be developed in an operational environment as it matures

- not just testing the safety but also learning about the novel user experience and experimenting with pricing

front end analysis

- purpose is to understand users, their needs, and demands of the work situation

1. who are the users?

2. why do users need the product and what are their preferences?

3. what are the environmental conditions under which the product or system will be used?

4. what is the physical and organizational context of the users' activity?

5. what major functions must be fulfilled by a person, team, or machine?

6. when must tasks occur, in what order, and how long do they take?

direct observation / accident analysis

- used often but not always the best

- hawthorne effect: people may behave differently when watched

- accidents might be rare: hard to observe directly and can be analyzed afterwards

- "five whys" help identify the multiple causes of accidents

five whys

- traces back the causes of an event by asking "why" at least five times

- typically show multiple unsafe elements associated with training, procedures, controls, and displays that should be considered before rather than after an accident

time motion studies

- used to improve worker efficiency and establish employee productivity standards

- task is broken into steps

- the moments observed in order to detect redundant motion (can help save time and avoid repetitive motion injuries)

- precise time taken for each movement measured

contextual inquiry

- semi structured interview asking user about context of use

- standard questions, establish rapport, observe and question while they work in environment (adopting master-apprentice relationship)

task analysis

systematic way of describing human interaction with a system to understand how to match system demands to human capabilities

four steps:

1. define the purpose and identify the required data

2. collect task data

3. interpret task data

4. innovate from task data

typical reasons for task analysis

- redesigning processes

- identifying software and hardware design requirements

- identifying content of the human machine interface

- defining procedures, manuals, and training

- allocating functions across teammates and automation

- estimating system reliability

- evaluating staffing requirements

four categories of information collected in task analysis step 1

1. hierarchical relationships: what, why, and how tasks are performed - helps identify new ways of achieving goals

2. information flow: who performs the task, interactions between people and technology, focus on defining roles and their information needs

3. sequence and timing: when, in what order, and how long it takes to perform tasks

4. location and environmental context: where and under what physical and social conditions are tasks performed

task analysis step 2: collect task data

see through the eyes of users

-direct observation

- retrospective/prospective protocol analysis

- structured/unstructured interviews

- surveys/questionnaires

- automatic data recording

direct observation

- performed where the person normally accomplishes the task

- master/apprentice relationship to understand goals/strategies/decisions

- can be more helpful than interviews because their actions and statements might not match (omit critical detail, might try to avoid seeming incompetent)

interviews

- structured: standard set of questions that get important specific info from all interviewees

- unstructured: more flexible and can be adjusted on the fly according to the situation using probe questions

retrospective and prospective protocol analysis

addresses important limitation of direct observation, like disrupting ongoing activity or failing to capture rarely occurring situations

- retrospective: people describe past events

- prospective: people imagine how they would act in future situations

critical incident technique

type of unstructured interview that is useful for understanding how people respond to accident and near accident situations in high risk systems

focus groups

- type of unstructured interview

- 6 to 10 users

- mediated by a neutral facilitator familiar with the system

- less costly in terms of time to analyze

- can draw out more details when participants remind each other of aspects of interaction with the system that they would have omitted if interviewed alone

surveys and questionnaires

used after designers have obtained preliminary descriptions of activities or basic tasks - often used to affirm accuracy of information

automatic data recording

uses various technologies to automatically monitor behavior unobtrusively

(ex: accelerometers, GPS, vehicle installed data loggers, etc)

task analysis step 3: interpret task data

information collected must be organized, summarized, and analyzed

- task hierarchy

- task flow

- task sequence

task hierarchy

goal, task, subtask decomposition

goals are at the top and tasks at the bottom represent detailed actions needed to complete goals

prompts innovation by identifying different ways of achieving same overall task with different subtasks

task flow

- chart captures task flow data from one task to another and the decision points (diamonds) determine which task to follow next

- highlight decisions and the information required to make them

- indicate mandatory ordering of tasks

task sequence

- shown in sequence diagrams that show order and duration tasks for each object and person in the system, with leftmost being actor completing the task

- horizontal lines show communication, solid lines are synchronous actions, dashed lines are asynchronous actions

- highlight communication, particularly success of failure of a person's actions

task analysis step 4: innovate from data

- reveals the potential to help people by creating new systems or revising existing systems

- focus on task details needs to be placed in the broader user experience and then linked to design solutions

- user id/persona development

-scenarios/journeys/use cases

- environment/context analysis

- workload analysis

- safety and hazard analyses

- function allocation analysis

user id and persona development

- describe most important user populations for product or system and their characteristics

- describe any population characteristics that might be important to using target product/system

personas

- hypothetical potential users developed through observation and interviews

- humanize the context, background, and motivations of users

- use at least 3 to 4 different personae to represent diversity in population

scenarios

the situations persone find themselves in when they might use the system or product

two types

1. daily use scenarios: common sets of tasks that occur daily

2. necessary use scenarios: infrequent but critical sets of tasks

use cases

- move on to involve prototypes

- more focused on the functions of the product or system (not the persona like in scenarios)

environment and context analysis

- where the personae play out the different scenarios of the different tasks they might complete when using the product or system

consider

- type of enviornment

- ambient conditions

- accessibility

- dress code of enviornment

design heuristics

are design alternatives consistent with human capabilities

fit the task to the person!!!!

design heuristics: create useful innovation

address a need

solve a problem

design heuristics: attend to details

small changes can have a larger effect

design heuristics: simplify

remove irrelevant info without hiding important indicators/feedback

design heuristics: honest and understandable

focus on transparent, predictable, intuitive functions

design heuristics: provide flexibility

allow users to adjust, navigate, undo/redo, and adopt shortcuts

design heuristics: consisitency

be constant and use well established conventions when possible

design heuristics: anticipate needs

provide options when helpful and be mindful of default settings

design heuristics: minimize memory demands

making things seamless

design heuristics: consider adaptation

think holistically to anticipate how users might use product in unintended ways

design patterns

commonly use interface solutions

- help with consistency across commonly used devices

- should be assessed to see if the pattern is best for new designs

HF requirements

- document system objective: use to guide design process and should align with users' goals

- specify performance requirements and features

- keep design constraints in mind

paper prototypes

- useful early in the design process (low cost, low commitment, rapid iteration)

- can get good/honest feedback from user

wireframes

- low fidelity representatoin of a design that shows what, where, and how of the interface

- used to communicate with the design team

mockups

- higher fidelity representation focused on look and feel

- can be used for software and hardware

hi-fidelity prototype

- allows users to experience elements of the final design

supporting materials

- should be a part of the system specifications at the start of the front end analysis

- make supporting materials easy for users to read/understand/comply with

purpose of evaluation

- understand how to improve during early development stages

- diagnose problems with prototypes

- verify (assess how well a system meets design requirements, how competing iterations compare, or how well a system performs)

timing with types of evaluations

early on: focus on rapid diagnosis and turnaround

later: focus on thoroughness

evaluation methods that do not require data collection

- literature review

- heuristic evaluation

- cognitive walk through

literature review

meta analysis is a great first step because it combines results of past studies

(what you put in is what you get out - garbage in, garbage out)

heuristic evaluation

apply design heuristics to identify how to improve interface design

1. select applicable HF principles to system

2. inspect design to see where it violates principles

3. share results with design team

cognitive walkthrough

considers each task in system interaction and poses a series of questions:

- is it likely the user will perform the right action?

- does the user understand what tasks need to be performed?

- will the user notice that the next can be performed?

- will the person understand how to perform the task?

- is feedback sufficient/appropriate after completing the task?

evaluation methods that require data collection

- usability testing

- controlled experiments

usability testing

the degree to which the system is user friendly on multiple dimensions

- learnability (easy)

- efficiency (high productivity)

- memorability (re-acclimate)

- errors

- satisfaction

controlled experiments

manipulating at least one IV to see the effect on at least one DV and controlling for or holding constant other confounding variables

between subjects

2+ groups of participants get different treatments (requires more participants and individual differences become confounding variables)

within subjects

one group of participants get all the treatments (counterbalancing tasks becomes important due to fatigue and practice effects)

drawing conclusions

- correlation does not = causation

- type 1 error: seeing a difference that does not exist (false positive)

- type 2 error: claiming there is no difference when their is one (false negative)