1. Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture #13 Usability I

2. Fall 2005 2 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Announcements Optional EVRs for Extra Credits (Individual Work) – December 6th Optional EVRs for Extra Credits (Individual Work) – December 6th For the Business Unit For the Business Unit Cusumano / Yoffie: Internet Time Cusumano / Yoffie: Internet Time Lessig: Future of Ideas Lessig: Future of Ideas For the Engineering Unit For the Engineering Unit Simon: The Sciences of the Artificial Simon: The Sciences of the Artificial Hoffman & Weiss: Software Fundamentals (part II) Hoffman & Weiss: Software Fundamentals (part II) Petroski: Design Paradigms Petroski: Design Paradigms Vincenti: What Engineers Know Vincenti: What Engineers Know

3. Fall 2005 3 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Picture of the Day: A View of Oakland from Wean Hall

4. Fall 2005 4 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Today ’ s Plan Learning from experience of using Contextual Design & Problem Frames Learning from experience of using Contextual Design & Problem Frames Usability attributes Usability attributes Usability through prototyping Usability through prototyping Classes of prototyping tools Classes of prototyping tools The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

5. Fall 2005 5 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Is Software Engineering Really Different? Is engineering software different from engineering hardware, bridges, and buildings? Is engineering software different from engineering hardware, bridges, and buildings? No, of course not! No, of course not! Routine design, innovative design Routine design, innovative design Moving the work from innovative to routine Moving the work from innovative to routine Building up things like architectural styles, patterns, problem frames Building up things like architectural styles, patterns, problem frames Recognized types of problems Recognized types of problems Known characteristics Known characteristics Overconstrained problems -- tradeoffs Overconstrained problems -- tradeoffs Yes, of course! Yes, of course! Brooks: the software must conform! Brooks: the software must conform! Intimate relation with people, institutions, things Intimate relation with people, institutions, things Small details can make the difference between success and failure Small details can make the difference between success and failure

6. Fall 2005 6 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Party Plan Editor John & Lucy Party editor Party plan Correct editing a: PE! (PlanOperations) c: JL! (Commands) b: PP! (PlanStates) d: PP! (PlanEffects) a d b c

7. Fall 2005 7 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Frame Concern for Simple Workpieces

8. Fall 2005 8 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Contextual Design for Party Planning What does the party plan domain really consist of? What does the party plan domain really consist of? What kinds of editing will the users actually want to do? What kinds of editing will the users actually want to do? What are the shared phenomena? What are the shared phenomena? What other domains might be involved? e.g., What other domains might be involved? e.g., Suppose party planning is tied to political causes, or charitable contributions? Suppose party planning is tied to political causes, or charitable contributions? Suppose they want to have invitations generated by a particular print shop? Suppose they want to have invitations generated by a particular print shop? Suppose John and Lucy have different preferences? Suppose John and Lucy have different preferences?

9. Fall 2005 9 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Generate-and-Test Very general problem-solving strategy Very general problem-solving strategy If impossible to generate solution immediately: If impossible to generate solution immediately: Generate a space where solution must (or at least may) reside Generate a space where solution must (or at least may) reside CD: work models, consolidation, vision CD: work models, consolidation, vision PF: identifying frame, shared phenomena, etc. PF: identifying frame, shared phenomena, etc. Search Search CD: storyboards, UED CD: storyboards, UED PF: variants, composites PF: variants, composites Evaluate the possible solutions encountered Evaluate the possible solutions encountered CD: prototyping CD: prototyping PF: frame concerns PF: frame concerns How to do better... How to do better... Tune the generator Tune the generator Search more intelligently Search more intelligently Test more precisely and/or efficiently Test more precisely and/or efficiently

10. Fall 2005 10 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Today ’ s Plan Learning from experience of using Contextual Design & Problem Frames Learning from experience of using Contextual Design & Problem Frames Usability attributes Usability attributes Usability through prototyping Usability through prototyping Classes of prototyping tools Classes of prototyping tools

11. Fall 2005 11 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University The AIMS System …

12. Fall 2005 12 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Usability “ The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component ” “ The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component ” Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990. Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990. Usability and utility -- from user ’ s perspective Usability and utility -- from user ’ s perspective Utility: does it do the right things? Utility: does it do the right things? Usability: does it do these things right? Usability: does it do these things right?

13. Fall 2005 13 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Is Usability Important? Example: intranet usability, e.g., Example: intranet usability, e.g., Research a company policy Research a company policy Find a form Find a form Find information about a department or person Find information about a department or person Enter an expense report Enter an expense report Study performed user tests Study performed user tests Employees in 14 companies Employees in 14 companies Sixteen common tasks Sixteen common tasks Results Results Low usability intranets:$3,000/employee/year Low usability intranets:$3,000/employee/year Average usability:$2,000/employee/year Average usability:$2,000/employee/year High usability:$1,600/employee/year High usability:$1,600/employee/year

14. Fall 2005 14 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University What Is Usability? Usability Attributes Usability Attributes Learnability Learnability Efficiency Efficiency Memorability Memorability Errors Errors Satisfaction Satisfaction

15. Fall 2005 15 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Learnability Often the most important characteristic Often the most important characteristic How much investment in learning is a user willing to make? How much investment in learning is a user willing to make? If too hard to learn, other characteristics don ’ t matter If too hard to learn, other characteristics don ’ t matter Can readily be measured Can readily be measured Time to reach specified level of proficiency, e.g., Time to reach specified level of proficiency, e.g., Perform a bank transaction successfully Perform a bank transaction successfully Create, save, and print a document Create, save, and print a document For business professionals, most highly rated characteristics: For business professionals, most highly rated characteristics: Easy-to-understand error messages Easy-to-understand error messages Possible to do useful work before learning it all Possible to do useful work before learning it all Availability of undo Availability of undo Confirming question before execute risky command Confirming question before execute risky command

16. Fall 2005 16 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Systems Designed for Novice and Expert Users Experience with Software Productivity Designed for Novice Designed for Expert

17. Fall 2005 17 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Novice/Expert Tradeoffs Different interaction styles, e.g., menus versus function keys Different interaction styles, e.g., menus versus function keys More capability for experts, but may make “ simple ” tasks hard More capability for experts, but may make “ simple ” tasks hard e.g., MS Word versus FrameMaker e.g., MS Word versus FrameMaker May be possible to “ ride ” both curves, e.g., May be possible to “ ride ” both curves, e.g., Judicious use of “ accelerators ” Judicious use of “ accelerators ” Multiple interaction styles, such as “ wizard ” and manual configuration Multiple interaction styles, such as “ wizard ” and manual configuration

18. Fall 2005 18 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Efficiency of Use Expert ’ s performance at asymptote Expert ’ s performance at asymptote Most users plateau after learning “ enough ” Most users plateau after learning “ enough ” Often reflects suboptimal investment Often reflects suboptimal investment Measurement Measurement Define “ experienced ” users Define “ experienced ” users Self-report Self-report Some number of hours, weeks, months of use Some number of hours, weeks, months of use Observe for some number of hours, or until curve flattens Observe for some number of hours, or until curve flattens Measure time to complete typical set of tasks Measure time to complete typical set of tasks

19. Fall 2005 19 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Memorability Most important for casual, occasional users, e.g., Most important for casual, occasional users, e.g., Utility programs Utility programs Tax programs Tax programs Kerberos, KClient, etc. Kerberos, KClient, etc. Measurement Measurement Time for typical tasks with users who have been away from system for specified amount of time Time for typical tasks with users who have been away from system for specified amount of time This attribute measured less often than others This attribute measured less often than others

20. Fall 2005 20 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Few and Non-catastrophic Errors Action that does not accomplish user goal Action that does not accomplish user goal Vary widely in effects Vary widely in effects Trivial Trivial Annoying Annoying Create faulty product or destroy work Create faulty product or destroy work Measurement Measurement Number of errors while performing standard task Number of errors while performing standard task Should be no catastrophic errors Should be no catastrophic errors

21. Fall 2005 21 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Subjective Satisfaction 1 How “ pleasant ” it is to use the system How “ pleasant ” it is to use the system Extremely important for discretionary software Extremely important for discretionary software Measurement Measurement Interview -- rich but nonquantitative data Interview -- rich but nonquantitative data Likert Scales, e.g., Likert Scales, e.g., “ It was very easy to learn how to use this system. ” “ This system was very pleasant to use. ” “ Using this system was a very frustrating experience. ” Each statement is followed by 5 or 7 point agreement scale: Strongly Disagree DisagreeNeutralAgree Strongly Agree

22. Fall 2005 22 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Subjective Satisfaction 2 Measurement (ctd.) Measurement (ctd.) Semantic differential rating scales, e.g., Semantic differential rating scales, e.g., “ Please place a check in a position that best describes X ” Pleasing _ _ _ _ _ Irritating Pleasing _ _ _ _ _ Irritating Simple _ _ _ _ _ Complicated Simple _ _ _ _ _ Complicated Fast to use _ _ _ _ _ Slow to use Subjects tend to give slightly inflated ratings, e.g., 3.5, not 3.0, as average on 5-point scale Subjects tend to give slightly inflated ratings, e.g., 3.5, not 3.0, as average on 5-point scale Scales need to be pilot tested Scales need to be pilot tested

23. Fall 2005 23 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Today ’ s Plan Learning from experience of using Contextual Design & Problem Frames Learning from experience of using Contextual Design & Problem Frames Usability attributes Usability attributes Usability through prototyping Usability through prototyping Classes of prototyping tools Classes of prototyping tools

24. Fall 2005 24 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Prototyping Desirable properties Desirable properties Cheap to construct Cheap to construct Appear rough Appear rough Malleable enough to allow exploration of alternatives Malleable enough to allow exploration of alternatives Purposes Purposes Evaluate alternative approaches, e.g., Evaluate alternative approaches, e.g., GUI GUI Command line Command line Tune interface ideas, e.g., Tune interface ideas, e.g., Clusters of functions Clusters of functions Choose interaction mechanism, e.g., button or menu Choose interaction mechanism, e.g., button or menu Identify omissions Identify omissions

25. Fall 2005 25 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Prototype Interviews Purpose is to have the user simulate performing specific work with the prototype Purpose is to have the user simulate performing specific work with the prototype Information gained triggers a mini- iteration of the whole modeling- interpreting-design cycle Information gained triggers a mini- iteration of the whole modeling- interpreting-design cycle

26. Fall 2005 26 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Prototype Fidelity Low FidelityHigh Fidelity PaperFaçade Tools Interface Builders (plus components & scripting language)

27. Fall 2005 27 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Questions??