Lecture 2 Usability Process Brad Myers HumanComputer Interaction

Lecture 2: Usability Process Brad Myers Human-Computer Interaction in e. Commerce 1

How to organize development process "Usability is not a quality that can be spread out to cover a poor design like a thick layer of peanut butter. " p. 16. n Like Software Engineering, is a process for developing software to help insure high quality n Must plan for and support usability considerations throughout design 2

“Usability Engineering” n n n Issues in UE text focused on “conventional” software applications Appropriate, but not identical, for web applications “Engineering” n n Measurable, process-oriented Not just “art” 3

Steps 1. 2. 3. 4. 5. 6. Study the users and their tasks Study the competition Set usability goals Parallel Design Participatory Design Coordinating the Total Interface for Consistency n Include documentation, help, etc. 7. Guidelines and Heuristic Evaluation n Evaluate your interface according to the guidelines. 8. Make prototypes of the system early and quickly n Actually is faster to prototype first 9. Empirical testing 10. Iterative design 11. Collect feedback from field use 4

1. Know the User n Study the intended users and the use of the product n n Difficult because n n Best if developers go and interview them personally May want to hide the developers Reluctance of sales people Reluctance of users User Characteristics n n Work experience, education level, age, previous computer experience Time for learning, training Available hardware (monitor size, acceptance of plugins, cell-phones vs. desktop) Social context of use 5

Task analysis n n Extremely important What tasks the users will do? n Examples: n n n How much? http: //www. pchertz. com/2 to 1 vgasw. html Too little information: http: //www. oscar. com/pp_AB-9. asp Find the Sun converter (CV-130): http: //www. cableconn. com/products/auto_switch/2 port/cs 142. htm Involve users in this Important to include exceptions and error conditions 6

Components of Task Analysis n Preconditions: n n Goals: n n What needs to be true before this task can be accomplished What are the actions this task is supposed to accomplish? Might also be called “subtasks” Remember: don’t say how it will be done, just what Information needs n n n What does the user need to know or view to do this task? Includes what needs to be on the screen. Both: n n What does the system need to show? What does the user need to know? 7

Task Analysis, cont. n Build up scenarios (stories) of typical uses from the task analysis: n n n n Related to software engineering "use cases" Specific example of how a user might use the system. One scenario for each major class of users doing each kind of important task Will want to make those tasks efficient and easy What is important to optimize? Will significantly affect the design Try to include lots of exceptional cases Shows how the interface will be used 8

Task Analysis, cont. n Uses: n n Refine the interface Demonstrate to management, marketing, customers what your concept is Can replace much textual specification Example, company YYY menu structure based on functions rather than tasks => Inefficient for every task! 9

Results of task analysis: 1. Scenarios to be used during design 2. List of the things users want to accomplish (goals) 3. Information they will need to accomplish those goals 4. Steps to be performed and interdependencies 5. All the various outcomes and reports 6. Criteria to determine quality of results 7. Communication needs of users with other people 10

Example of Task Analysis n Task: n Preconditions: n Goals: n Information Needs: 11

Functional analysis n n What really needs to be done Not just the way users are doing it now n n May be a more efficient or more appropriate way to achieve same task Usually, companies are good at this n However, may include extra functions that are not useful 12

2. Competitive Analysis n n "Know the competition“ For usability and function Read trade-press reviews of products or web sites Visit competitor’s web sites n n Also, web sites for related products Importance of various features, issues n Pictures, navigation, search, prices, shipping, metaphors 13

3. Goal Setting n n What does it mean to be "easy to use"? Some proposed definitions: n n "I like it "I always do it that way“ "That is the way the xxx system does it“ "It is easy to implement“ 14

Much better Goals: n n n n Can be learned in less than 2 minutes User will perform 2 error-free purchases per session The error rate will be lower than 2 per 10 operations Tasks will be performed in 30% of the time it takes using the competitor’s system Users will have a high satisfaction with the system as measured by a survey. Explicit, specific, measurable metrics. Allows objective decision making. 15

Goals, cont. n n Tradeoffs, so have to pick relevant metrics Measures (Nielsen, chapter 2, pp. 26 -37): n n Learnability: Time to learn how to do specific tasks (at a specific proficiency) Efficiency: (Expert) Time to execute benchmark (typical) tasks. Throughput. Errors: Error rate per task. Time spent on errors. Error severity. Subjective satisfaction: Questionaire. 16

Goal Levels n Pick Levels for your system: n n Minimum acceptable level Desired (planned) level Theoretical best level Current level or competitor's level Best 0 Desired 1 Minimum Acceptable 2 Current 5 Errors 17

Financial impact analysis n n n Prove It! Demonstrates the importance of usability # users * their salary per hour * # hours on system = cost of system per hour Estimate savings of reduced training, error time, need for support staff, etc. Tells how much time to spend on usability Whole book on this topic (pre-WWW) n Randolph G. Bias and Deborah J. Mayhew, Cost. Justifying Usability, Boston: Academic Press, 1994. 18

4. Parallel Design n Different designers try out different designs in parallel Work independently Combine later 19

5. Participatory Design n Users involved in the design process through regular meetings Users are good at reacting to concrete designs and prototypes But users are not necessarily good designers 20

6. Consistency n n Most important characteristic of UI Requires oversight n n Not each department creating own section May require overall design document, vocabulary guide, style guide, templates, etc. 21

7. Use Guidelines and Heuristic Analysis n n n Designers evaluating the Interface Based on their experience Full lecture on this topic 22

8. Prototypes n n n Simulation of interface Quick and cheap to create (no “back end”) Can be “low fidelity” n n Paper prototypes Can be roughly drawn n Often better if not refined Answer important questions of tasks and navigation Can be used in studies n n Experimenter can “play the computer” Extremely useful and revealing 23

9. Empirical testing n n Critical to usable products Designers must watch users Web logs are not sufficient Not necessarily difficult or expensive n n n Often, a few user tests are sufficient Don’t necessarily need a fancy lab Lecture on this topic 24

10. Iterative design n Redesign interface based on evaluation New design may be worse or may break something Keep track of reasons for design decisions n n Called "Design Rationale" So don't need to keep revisiting the same decisions When future conditions suggest changing a decision will remember why made that way and what implications for change are. Instead of arguing about a design feature, figure out what information would tell you which way to go n Experiment, marketing data, etc. 25

11. Measure Real Use n n Follow-up after release For the next version From bug reports, trainers, initial experiences (for conventional applications) From web logs, reports, customer support 26