1. University of Connecticut MECHANICAL ENGINEERING “The design of everyday things” “The design of future things” D. Norman Design for the human factor

2. University of Connecticut MECHANICAL ENGINEERING The design of everyday things The designer has to couple psychology of people to the knowledge of how things work  Example: pitcher with handle and spout on same side Design for the human factor

3. University of Connecticut MECHANICAL ENGINEERING Fundamental Principles of Designing for People Provide good conceptual models Make things visible Make invisible things visible

4. University of Connecticut MECHANICAL ENGINEERING Provide Good Conceptual Models Mental model of the way objects work, events take place, or people behave Results from tendency to form an explanation of how things work Mental models are often constructed from fragmentary evidence Some faulty models lead to frustration in everyday life

5. University of Connecticut MECHANICAL ENGINEERING Provide Good Conceptual Models Examples -Room thermostat: in cold room, if in a hurry to get room warm quickly, will not heat up faster if you turn up thermostat to maximum. -Temperature control on a refrigerator & freezer

6. University of Connecticut MECHANICAL ENGINEERING Conceptual Models of Refrigerator Controls Model A: Image gained from controls and instructions

7. University of Connecticut MECHANICAL ENGINEERING Conceptual Models of Refrigerator Controls Model A: Image gained from controls and instructions Model B: Correct conceptual model Problem: Which compartment has the thermostat and where are the controllers?

8. University of Connecticut MECHANICAL ENGINEERING Make Things Visible - I Things work from their visible structure  affordances ("is for")  a chair affords ("is for") support and therefore affords sitting  affordances give clue to operation of things  plates >> for pushing,  knobs >> for turning,  slots >>for inserting things  when designers take advantage of affordances, no picture, label instruction is required.

9. University of Connecticut MECHANICAL ENGINEERING Make Things Visible - II Mappings: relation between 2 things, i.e. controls & their movements  steering wheel and direction  measurable parameters like amount and loudness  less clear for pitch, taste, color (no characteristic plausible relation) A bad mapping design (vertical set of switches: which switch controls which source)  similar to many airplane cockpits where many switches are close and look/feel the same

10. University of Connecticut MECHANICAL ENGINEERING How to Make Things Visible - III bolt click when closing door bolt door lock click when locked by fob "zzz" sound of zipper when working click of toaster when bread pops up whistle on tea pot Window versus UNIX MS Word versus LaTex: WYSWYG \frac{T_2}{T_e} = \left( \frac{p_e}{p_a} \right)^{-\frac{\gamma-1}{\gamma}}. versus

11. University of Connecticut MECHANICAL ENGINEERING Some things require action with no clue of result Example 1: digital watch with several push buttons  the more functions included, the more questions on operation Example 2: kitchen stove top with controls  arbitrary arrangement  natural mappings

12. University of Connecticut MECHANICAL ENGINEERING Arbitrary Arrangement Natural Mappings

13. University of Connecticut MECHANICAL ENGINEERING Some things require action with no clue of result Example 3: water faucet design  controls: temperature, volume  3 problems  (2) relate to mapping of intentions to actions –Which is hot / cold? –What increases / decreases (action) water flow?  (1) relates to problem of evaluation –How to determine if volume / temperature is correct?

14. University of Connecticut MECHANICAL ENGINEERING Some things require action with no clue of result Example 3: water faucet design [cont’d]  mapping  convention is hot on left, screw clockwise to tighten / shut off water –What if a lever is used [Moen design]?  are conventions universal? –vertical faucet arrays on wall? –Europe does not have the same conventions  asymmetricaly placed faucets for esthetics  2 separate spigots  evaluation is normally determined by direct feedback, i.e. trial and error

15. University of Connecticut MECHANICAL ENGINEERING The Designer Challenge Natural evolution of a design is normally used, but time factors frequently preclude this  Designers are not typical users  Designers clients are frequently not users  Designing for special people requirements  left-handedness  size / height of user  age / infirmity of the user

16. University of Connecticut MECHANICAL ENGINEERING Design for Zero Errors Design for avoiding misinterpretation, e.g. operators at 3-mile island plant made numerous errors and misdiagnoses, but each one was logical and understandable at the time Examples:  Adaptive cruise control  Korean Air Lines KAL007

17. University of Connecticut MECHANICAL ENGINEERING Design for Zero Errors Example: Adaptive automotive cruise control  system designed to sense proximity to cars in front and automatically slow down car.  System designed to sense no upstream cars and accelerate car to set speed  Consider the following scenario  Car driving with cruise control at set speed, say 65 mph.  Car runs into traffic and decelerates to 20 mph.  After a period of time, car makes right turn to exit highway.  System senses no traffic and accelerates vehicle to 65 mph.  What is the problem, if any?

18. University of Connecticut MECHANICAL ENGINEERING Design for Zero Errors Example: Korean Air Lines KAL007 shot down over Russia in 1983 after crew mis-programmed the flight path into the inertial navigation system (INS)  system could not be reprogrammed in flight [before GPS], needed to return to original airport to be reset.  3 previous KAL planes had done this over the last 6 months  KAL pilots warned next plane to return to base would be punished (social constraint)  real error is a design that can easily be set to the wrong settings  U.S had been flying reconnaissance flights near Soviet bases

19. University of Connecticut MECHANICAL ENGINEERING What should designers do? Understand the causes of error and design to minimize these causes Make it possible to reverse actions (undo them) or make it harder to cause basic error Make it easier to discover errors Change the attitude towards errors. Don't think of the user making errors, think of the action as an approximation of what is desired  Example 1: locking keys in a car  Example 2: leaving the light on in a car