1. CS 575 Spring 2012 CSULA Bapa Rao Lecture 6

2. Agenda for today Review of previous meeting Student Comments Heuristic Evaluation Presentation Team reports Heuristic Evaluation Task Assignment In-class heuristic evaluations [time permitting] Alan Kaye video

3. Review of previous meeting App Ideas / Use Cases Team Finalization Each team should own one app idea they will pursue

4. Team Reports Red: Armando, Albert, Phu Orange: Phanti, Rain, Long Green: Ali, Behin Blue: Yin yin, Sina, Amir Pink: Raudel, Dinesh, Tony Purple: Gavik, Hardik, Mohammed Brown: Shweta, Sowmya Grey: Harshil, Haresh, Vishrut

5. Work assignment from the previous week (Revise & re-)write the high-level use case spec for your assigned app. – For some, this will be catch-up Goal is to have a paper prototype Point of view: – What experience do you want to provide for the user? – Relate to needfinding exercise results for validation Storyboard two alternative design ideas – Use web, library or bookstore resources along with Aziz’s guide/sketch – Generate paper storyboards & upload pics to your wiki page Discuss & Choose one of the ideas Make an Oz-style paper prototype of the chosen idea – (see HanMail) Make a video of use of paper prototype, upload & link Bring paper prototype to next class Refer: Assignment 3 in Stanford course link

6. Heuristic Evaluation Motivation Nielsen’s Usability heuristics Nielsen’s Severity Ratings How many evaluators? How to conduct a heuristic evaluation

7. Motivation Usability engineering is costly Heuristic Evaluation uses guidelines rather than hard criteria – “Discount User Testing” Most of the value for low investment http://www.useit.com/papers/guerrilla_hci.ht ml

8. The Scenario Concept (e.g., Wizard of Oz)

9. Cost-Benefit Analysis

10. Nielsen’s Usability Heuristics Visibility of System Status Match Between System and the real world User control and freedom Consistency and standards Error prevention Recognition rather than recall Flexibility and efficiency of use Aesthetic and minimalist design Help users recognize, diagnose, and recover from errors Help and documentation

11. Usability Heuristics Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. Recognition rather than recall Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. Flexibility and efficiency of use Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

12. Nielsen’s Severity Ratings Factors: – Frequency – Impact – Persistence 0: Not a problem 1: Cosmetic 2: Minor usability problem 3: Major usability problem 4: Usability catastrophe

13. Number of evaluators vs. problems found

14. How Many Evaluators? Cost-benefit Number of evaluators: 3-5

15. Not Every Evaluator Catches Every Problem

16. How Many Evaluators, contd. Taking the mean of 3 evaluations usually works

17. How to do Heuristic Testing Do “walkthroughs” first Each individual evaluator inspects the interface alone After, evaluators can communicate and findings can be aggregated Record: – Written reports from each evaluator or – Observer notes Observer can assist 1-2 hrs – Probably closer to 30 min for our app evaluator goes through the interface several times and inspects the various dialogue elements and compares them with a list of recognized usability principles (the heuristics). also allowed to consider any additional usability principles or results that come to mind that may be relevant for any specific dialogue element or category go through the interface at least twice – get a feel for the flow of the interaction and the general scope of the system – focus on specific interface elements while knowing how they fit into the larger whole. http://www.useit.com/papers/heuristic/heuristic_evaluation.html

18. Heuristic eval followup: Design Advice Debriefing Session – Evaluators – Observer – Design team Brainstorming mode – Address design problems – Identify positive aspects

19. Output from heuristic testing process a list of usability problems in the interface with references to those usability principles that were violated by the design in each case in the opinion of the evaluator. Not enough to say “I don’t like this” – Explain why with respect to heuristic criteria

20. In-class heuristic evaluation Pick a team to be the evaluators for a paper design

21. Assignment for the coming week Self-evaluation of your work from the previous week (storyboard / paper prototype) Start a journal on your personal page documenting the work you have personally done, and your personal thoughts & ideas – Back-fill with work you have already done – Include self-evaluation – For every activity done by your team, you should post documentation of your personal contribution and self-evaluation Not everyone has to do every task, but everyone has to do significant tasks in the team activity – This will, in part, determine your personal final grade I can’t grade you if I don’t know what you have done I will provide evaluation templates as appropriate

22. Assignment for the coming week (contd) Read the papers on Heuristic Evaluation posted on the wiki. Complete heuristic evaluation of your paper prototype and post your evaluation report on the team wiki page. – Be sure to include your personal (course-related) activity and contribution on your personal wiki page Do a debriefing and make needed design changes Post a self-evaluation of your heuristic evaluation. Put an implementation proposal and plan together – See the sample on wiki – You have 2 weeks to build the prototype so limit your scope accordingly starting May 18th + 1 week for testing – Identify platform – Decide what backend functions you will “fake” and how – Should be demo-able in class on June 9 th 2012 No coding till you finish heuristic evaluation step