Human Capabilities: Mental Models CS352

Announcements Notice upcoming due dates (web page). Where we are in PRICPE: Predispositions: Did this in Project Proposal. RI: Research (studying users), recently turned in. Hopefully led to Insights. CP: Concept and initial (very low-fi) Prototypes due soon (see schedule). Evaluate throughout, repeat iteratively!! HW 3 Design Jam Doodle Poll Due Sunday at midnight. Proj. 5: Concept and Prototype due Wednesday @midnight (Also in class)

Hints: Team Process Improvement List risks and what you’ll do if they materialize. Agree on a process for working out disagreements in direction. We should use a web interface! No, we should use portable bar-code readers! eg: votes? eg: try both quickly with user? eg: joint visits to office hours? Do a post-mortem after every hand-in or grade received What went right in our process? Data, not finger-pointing: “we got an A-”. What went wrong in our process? Data, not finger-pointing: “we had to pull an all-nighter because we started too late” What will we do differently from now on? Write it down and revisit next time. If you haven’t already… Have a plan for what you should do.

Mental Models = How to use the system (& how the system works). MENTAL: Users build these in their heads. Developed over time. Not always correct (and usually not complete). Thermostat example. Lightswitch example. Why do users build these? Rote mem is hard, explained-by memory easier. Mental model is an explanation. If user’s mental model is correct, will have an easier time using the system. To reason about the system Developed over time the more the system is used Usually not complete: Networking example Thermostat ex: more is more, not like a faucet (crosswalk, elevator) Light switch ex. Ideally matches conceptual model. Task efficiency and knowing what to do if it malfunctions (networking ex)

How to help user’s mental model be correct Remember Norman’s 2 Gulfs? Useful feedback in response to inputs (Evaluation). Ways of interacting with UI consistent with underlying workings (Eval+Exec). Context-sensitive devices for guidance (Execution). Activity: sketch a thermostat UI idea that does 1, 2, or 3. We can draw upon these gulfs to try to help understand how to help users from correct mental models. These are 3 suggestions Eval = What was the affect of what I did? Did I do it right? Eval + Exec = if thermostat was more transparent about what its doing/how it works. Exec = How do I do what I want to do? If thermo could detect the temp context (cold house) might give guidance in UI, giving us a better mental model.

How people do things: the 7 stages of an action Norman, at a conf in Italy. Speaker needed to show film, had trouble threading it into projector. Many people came up to help, none succeeded. Finally technical was called, who quickly threaded it correctly. Q: Why so hard? A: Structure of an action as relate to the Gulfs.

The 7 stages 1=goal. 2,3,4=execution. 5,6,7=evaluation.

The 7 stages (cont) 1 goal: “what” we want to do. Example. 2. execution intention (from what to how but top-level without details) 3. execution: sequence of actions. 4. execution: physically do them. 2. Thread through projector 3. Then decide order 4. Some places may be hard to reach

The 7 stages (cont.) 5. evaluation: perceiving (senses) what the world did in response (with our eyes, etc.) Example. 6. evaluation: interpreting (brain) the perception. 7. evaluation: comparison of interpretation with goal. 5. In some cases we can see. Its possible that when you close something the film may have moved. 6. Was it what we wanted to do? 7. Does it match up?

The 7 stages (cont.) Gulf of Execution. Gulf of Evaluation. How to get from 1 to 2, 2 to 3, or 3 to 4. Example. Gulf of Evaluation. How to get to 5 at all, 5 to 6, 6 to 7. The “what” How? What order? Then do! Everything look good? Is it what I wanted to do? Did it do what I wanted?

The 7 stages as design aids To find problems, apply these to any task in a UI: How easily can determine ... 1. My Goal 2. Exec: ...what relevant actions are possible? 3. Exec: ...map those actions to physical moves? 4. Exec: ...actually do the physical move? 5. Eval: ...what state the system is in? 6. Eval: ...what “that (feedback in UI)” means? 7. Eval: if system is in desired state? The 7 Stages that can be used as design aid. ... Determine the purpose of the device or feature. 2. Visibility 3. Affordance/Constraint(If projector had been designed to not be able to thread wrong) Intention maps to sequence of specific action. 4. Affordance 5. Feedback 6. Feedback

To find solutions Consider these remedies. Visibility: 2: Exec: ...what relevant actions are possible? Consider these remedies. Visibility: show what actions available (2). Good mappings revealing: relationships between actions and results (2), controls (causes) and effects (3), system state visible (5,6,7) Feedback every action provides immediate feedback of results (5,6,7) 3: Exec: ......map actions to physical moves? Remedies for problems revealed by the questions. 5: Eval: ...in what state? 6: Eval: …what feedback means? 7: Eval: …in desired state?

Hints: Team Process Improvement List risks and what you’ll do if they materialize. Agree on a process for working out disagreements in direction. We should use a web interface! No, we should use portable bar-code readers! eg: votes? eg: try both quickly with user? eg: joint visits to office hours? Do a post-mortem after every hand-in or grade received What went right in our process? Data, not finger-pointing: “we got an A-”. What went wrong in our process? Data, not finger-pointing: “we had to pull an all-nighter because we started too late” What will we do differently from now on? Write it down and revisit next time. Get together with your teams and discuss…