1. Oct 231 Heuristic for websites Avoid orphan pages Avoid long pages that force scrolling Provide navigation support, such a site map that is always present Avoid narrow, deep, hierarchical menus Avoid non-standard link colours Provide consistent look and feel for navigation Avoid complex URLs Avoid long download times

2. Oct 232 Cognitive walkthroughs “Cognitive walkthroughs involve simulating a user’s problem-solving process at each step in the human-computer dialog, checking to see if the user’s goals and memory for actions can be assumed to lead to the next correct action” (Nielsen and Mack, 1994). Focus is on evaluating design for ease of learning

3. Oct 233 Cognitive walkthrough steps Characteristics of typical users are identified Designers and evaluators meet, walk through the action sequences for each task and try to answer the following questions: Will the correct action be evident to the user? Will the user notice that the correct action is available? Will the user know from the feedback whether they made a correct choice?

4. Usability Testing

5. Oct 235 Usability Testing is NOT... “What type of feedback did you gather from your usability participants?” “I showed my program to three different people and they all said it looked really, really good.”

6. Oct 236 Useful vs. Usable It doesn’t matter how useful a program could be if the interface is unusable. “Not even the most brilliantly conceived and ingenious computer system can do all that it was designed to do- or even a small part of what it was designed to do- unless the brilliance of its operation and purpose is matched by the cunning simplicity of its user interface. (Hicks and Essigner, 1991)

7. Oct 237 Usability Testing- Definition Usability testing is a method by which users of a product are asked to perform certain tasks in an effort to measure the product's ease-of-use, task time, and the user's perception of the experience. Usability test participants are encouraged to think aloud and voice their every opinion. Changes are made to the application or site based on the findings of the usability tests. Adopted from http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci214526,00.html

8. Oct 238 Why is Usability Testing Important? It is impossible to predict usability from appearance, just like it is impossible to judge a person’s personality on appearance. Casual “feel good” feedback is inadequate. Formal testing is often the only way problems are identified pre-release. Problems found once a product is released are usually not fixed unless they are really severe.

9. Oct 239 Why is Usability Testing Important? Users, designers, programmers have different models The designer’s intuition is not always correct Design standards and guidelines are not sufficient Usability testing leads to competitive advantages and reduced support costs

10. Oct 2310 The REAL components of Usability Relevance - is how well a system serves the users’ needs. Efficiency - states how efficiently the users can carry out their tasks using the system. Attitude - is the users’ subjective feelings towards the system. Learnability - is how easy the system is to learn initially and how well the users remember the skills over time http://www.affectus.se/artiklar/usabilityinsp/

11. Oct 2311 Measuring Relevance Number of good and bad features recalled by users Number of available commands not invoked by users Number of available commands invoked by users Number of times users need to work around a problem Percentage of task completed http://www.affectus.se/artiklar/usabilityinsp/

12. Oct 2312 Measuring Efficiency Time to complete a task Percentage of task completed Percentage of task completed per unit time (speed metric) Time spent in errors Number of commands used Frequency of help and documentation use Time spent using help or documentation http://www.affectus.se/artiklar/usabilityinsp/

13. Oct 2313 Measuring efficiency (cont.) Number of repetitions of failed commands Number of runs of successes and of failures Number of times interface misleads user Number of times user needs to work around a problem Number of times the help facilities solve the user’s problem http://www.affectus.se/artiklar/usabilityinsp/

14. Oct 2314 Measuring Attitude Percentage of favourable/unfavourable user comments Number of good and bad features recalled by users Number of users preferring the system Number of times user loses control over the system Number of times the user is disrupted from a work task Number of times user expresses frustration or satisfaction http://www.affectus.se/artiklar/usabilityinsp/

15. Oct 2315 Measuring Learnability Ratio of success to failures (over time) Time spent in errors Percentage or number of errors Number of commands used Frequency of help and documentation use Time spent using help or documentation Number of repetitions of failed commands Number of runs of successes and of failures http://www.affectus.se/artiklar/usabilityinsp/

16. Oct 2316 Measuring Learnability (cont.) Number of available commands not invoked by users Number of features or commands that can be remembered after a test Proportion of users using efficient strategies compared to those using less efficient strategies Number of logical errors made http://www.affectus.se/artiklar/usabilityinsp/

17. Oct 2317 Nielsen’s Usability Severity Ratings 0 - Not a usability problem at all 1 - Cosmetic problem only - need not be fixed unless extra time is available on project 2 - Minor usability problem - fixing this should be given low priority 3 - Major usability problem - important to fix, so should be given high priority 4 - Usability catastrophe - imperative to fix this before product can be released

18. Oct 2318 Usability Frequency Ratings 0 - Problem did not occur 1 - This problem occurs rarely- only once/under very unusual circumstances 2 - This problem occurs occasionally - under less commonly occurring conditions 3 - This problem occurs often during common tasks 4 - Problem occurs every time under all tested conditions

19. Oct 2319 Usability Labs (http://www.ulabs.com/images/lab.gif)

20. Oct 2320 Usability Labs - Dedicated Lab (http://www.sun.com/usability/)

21. Oct 2321 Low Fidelity Prototyping Hand sketches and scenarios (storyboards, scene by scene) where the focus is on the design, not on the interface mechanics. Usability testing can be conducted using hand sketches before any code has been written. Can be used early in the development process Fast to modify and iterate Can be used to define requirements

22. Oct 2322 What information to provide? Give a brief explanation that the participant’s involvement is to solicit user feedback. Any problems are the fault of the software. In real-world situations explain confidentiality agreement, liability legalities, and that participant is free to leave at any time (and still get paid). Provide instructions as to the user’s task but not explanations of the software.

23. Oct 2323 What to User Test? Conformance with a requirement Conformance with guidelines for good design Identification of design problems Ease of system learning Retention of learning over time Speed of task completion Error rates Subjective user satisfaction Galitz, W. O., (2002) The Essential Guide to User Interface Design, 2nd Edition, Wiley Computer Publishing, New York, NY.

24. Oct 2324 What questions to ask Depends on which phase of the development cycle- what can be changed? Conceptual model? Layout? Fonts? There should be a list of questions of the major design issues that is prepared in advance. There should be specific questions that the usability testing is designed to answer. Usability testing has specific objectives.

25. Oct 2325 The Goal of Usability Testing Usability testing should be designed to determine if the software is meeting the Qualitative Usability Goals Quantitative Usability Goals Adapted from Mayhew, Deborah J. (1999) The Usability Engineering Lifecycle

26. Oct 2326 Examples of qualitative goals The design must support users working in a high-interrupt environment, with lots of context information on screen to remind users where they are when they get distracted. The design must support very infrequent users of a very complex task. Thus, it must be self-explanatory, easy to learn and remember. Adapted from Mayhew, Deborah J. (1999) The Usability Engineering Lifecycle

27. Oct 2327 Examples of quantitative goals Experienced users (defined as users who have performed the task five times in a training session) should take no longer than 15 seconds on average to address an email. Novice users (defined as first-time users) should take no longer than three minutes to complete the registration input form. Adapted from Mayhew, Deborah J. (1999) The Usability Engineering Lifecycle

28. Oct 2328 When to ask questions? If you are worried about interrupting the task flow of your participant, then ask the question after the completion of the task. If you are more worried about the participant forgetting their current thought process than interrupting, then ask right away.

29. Oct 2329 Thinking Aloud Protocol During a usability test, instruct participants to verbalize their thoughts. Prompt participants by asking direct questions about the software, in order to understand their mental model of the system and the tasks, and where they have trouble in understanding and using the system.

30. Oct 2330 Co-discovery Method During a usability test, two participants perform tasks together while being observed. In order to increase the amount of communication to gain insight to their thought process, one participant is assigned the mouse and the other the keyboard. They are to help each other in the same manner as they would if they were working together to accomplish a common goal using the product.

31. Oct 2331 Usability Testing Sequence of Events 1. Know your Purpose. There should be specific questions which need answering. 2. Find Representative Users. This is a non- trivial task, whose difficulty is often overlooked in texts on usability. The quality of the participants make or break the success of the usability session. 3. Watch & Learn. Don’t lead the user to give the answers you want to hear. Be prepared to learn new things.

32. Oct 2332 Usability Testing Sequence of Events 4. Report the Data. The data collected and observations made must be communicated to the developers and to management. 5. Back to the Drawing Board. It is not enough just to test. Time must be put aside to correct the problems found. Adapted from http://keith.instone.org/howtotest/introduction.html

33. Oct 2333 How to choose user tasks Familiarize yourself with the facilities offered by a drawing tool Create list of tasks which a general user can (hopefully) finish in about an hour Make sure tasks are not too simple, nor too difficult.

34. Oct 2334 What data to collect Could the users complete the task? Did they need help? How much time did it take? (track time through testing) Stumbling blocks (problems/obstacles) Overall observations, commentary