Heuristic for websites

1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Usability Labs (http://www.ulabs.com/images/lab.gif)

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

21. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. How to choose user tasks • Familiarize yourself with the facilities offered by a drawing tool • Create list of tasks which a general usercan (hopefully) finish in about an hour • Make sure tasks are not too simple, nor too difficult.

34. 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