E PRESENTATION OVERVIEW

USABILITY • Why Engineering?

ENGINEERING • What is Usability?

Néstor J. Rodríguez • Usability Heuristics for User Interfaces Catedrático Asociado Departamento de Ingeniería • Eléctrica y Computadoras • Other Usability Assessment Methods

2

Your Best Guess is not Good Enough The User is Always Right

• It is not possible to design an optimal user • If users have problems with an aspect of the interface just by giving it your best try. interface is not because:

• Users have potential for unexpected ◆ they are stupid misinterpretations of interface elements. ◆ they did not try a little harder • Users have potential for performing their job in a different way than you imagine.

• Designers are not users Prescription: ➔ do not blame the users for usability problems

➔ be humble, acknowledge the need to modify Prescription: the original design to accommodate the ➔ understand the users and their tasks user’s problems

➔ validate the design with usability assessment methods 3 4

The User is not Always Right Usability Has an Economic Impact

• Users often do not know what is good for • Reduces training costs them. • Products with good usability sell better • Users have a very hard time predicting how • Users can do more productive work per they will interact with systems with which hour they have no experience.

• Users will often have divergent opinions when A Very Good Example: asked about details of design. Changing a screen from full to half full saved a telephone company 40 Prescription: million dollars per year. ➔ do not design user interfaces exclusively based on what the users say they would like

➔ usability test user’s preferences 5 6 USABILITY ATTRIBUTES Learnability

• The system should be easy to • Learnability learn

• Efficiency • Users should rapidly be able to • Memorability do some productive work with the system • Errors

• Satisfaction

7 8

Efficiency The Learning Curve

• The system should be efficient Usage Proficiency to use and Efficiency

• The user should eventually novice user expert achieve a high level of user productivity with the system

Time

9 10

Memorability Errors

• The system should be easy to • The system should have a low remember error rate

• Casual users should be able • Users should easily recover to use the system without from errors having to learn everything all over again • Catastrophic errors should not occur

11 12 Satisfaction USABILITY ASSESSMENT METHODS

• Heuristic Evaluation • The system should be pleasant to use • User Testing • The system should be one that the users like to use • Questionnaires and Interviews

13 14

HEURISTICS EVALUATION Jakob Nielsen’s Usability Heuristics

• Simple and Natural Dialogue • Based on well-known principles • Speak the User Language for • Minimize User Memory Load • Consistency • Detects usability problems before user testing • Feedback • Clearly Marked Exits • Does not provide solutions • Shortcuts • Good Error Messages • Discount usability assessment • Prevent Errors method • Help and Documentation 15 16

SIMPLE AND NATURAL DIALOGUE Mapping

• User interfaces should be simplified as Ö Is the mapping between computer concepts and much as possible user concepts as simple as possible?

Ö Is the navigation through the user interface • The ideal - present exactly the minimized? information the user needs (and no more) at exactly the right time and Ö Is the information provided exactly the place information the user needs (and no more) at exactly the time and place where it is needed? • User interfaces should match the users’ task in as natural a way as Ö Are the information objects and operations possible. accessed in a sequence that matches the way users will most effectively and productively do things?

• Minimize navigation through the interface 17 18 Graphic Design Colors

Ö Is the information that will be used Ö Does the interface looks like an angry together displayed close together or at fruit salad of wildly contrasting, highly least in the same screen? saturated colors?

Wisdom: Grouping could be achieved Ö Does the interface uses more than 7 with dividing lines, boxes, colors, etc. colors?

Ö Do the most important dialogue Ö Could the interface be used without elements stand out? colors?

Wisdom: Blinking should only be used Wisdom: Colors should be used to in extreme cases (it is distracting and categorize, differentiate and highlight. annoying).

19 20

Less is More SPEAK THE USERS’ LANGUAGE

Ö Is irrelevant information presented in the interface? • The terminology should be based on the users’ language Ö Is less important information left for auxiliary screens?

Ö Are too many choices provided?

Wisdom: Use training wheels approach - provide multiple nested levels of increased complexity (for novice users to expert users).

21 22

Verbal Language Graphical Language

Ö Is the terminology used based on the users' language (not on system oriented terms)? Ö Is there a good mapping between the computer display of information and Ö Are words in nonstandard meanings used? the user's conceptual model of the information ( the one million dollar Ö Are interaction messages stated from the users' question) perspective? Ö Are there restrictions on the names the users Wisdom: When using metaphors care assign to objects (i.e. limits on the number of should be taken to present the characters that can be specified)? metaphor as a simplified model of a more detailed conceptual model of the Wisdom: Use vote winning terms (words). system and not as a direct Wisdom: Allow for rich use of synonyms in representation of the system. interpreting command languages and in documentation indexes. 23 24 MINIMIZE THE USERS’ MEMORY LOAD Minimizing Memorizing

• Users should not be forced to Wisdom: In general, people have much easier remember information or codes to time at recognizing than recalling. interact with the computer Ö Are dialogue elements displayed to the users so that they can choose from them or edit • Users should be allow to choose them (menus, pallets, dialogue boxes, default values)? from items on a dialogue element ➔ menus Ö Are generic commands used? ➔ dialogue boxes options Wisdom: The system should be based on a small number of pervasive rules that apply ➔ palettes throughout the user interface (cut & paste, point & click, drag & drop, etc.) ➔ default values

25 26

CONSISTENCY Maintaining Consistency

• Users should not have to wonder Wisdom: Users feel more confident in whether different words, situations or using the system if they know that the actions mean the same thing same command or the same action will always have the same effect.

• The same information should be Ö Is the same information presented in presented in the same place on all the same location on all screens and screens and dialog boxes dialogue boxes? Is it formatted in the same way? • Follow the user interface standard Ö Is the interface standard being followed?

27 28

FEEDBACK Providing Good Feedback

Ö Does the system continuously inform • The system should the user about what it is doing and how continuously inform the user it is interpreting the user's input? about what it is doing Ö Is feedback expressed in abstract and general terms (like in command line interfaces)?

Wisdom: Feedback should restate and rephrase the user's input to indicate what is being done with it (i.e. when overwriting a file).

Ö Is feedback provided in case of a system 29 failure? 30 Feedback Persistence CLEARLY MARKED EXITS

Ö Is the degree of persistence of the • The system should provide the user feedback appropriate? an easy way out of as many situations as possible Ö Is feedback provided according to ➔ undo response time of operations? ➔ cancel Wisdom: ➔ ...

◆ No special feedback is needed for delays less than 1 second.

◆ Feedback for events lasting more than 10 seconds should have a high degree of persistence (use percent done indicators).

◆ Do not use percent done feedback for operations taking between 2 to 10 seconds. 31 32

Getting out of Undesired Situations SHORTCUTS

Ö Does the system provides the user an easy way • Provide features that allow experienced out of as many situations as possible (cancel, users to speed up interaction undo, etc.). ➔ function keys Ö Do the exit and undo mechanisms visible (not a ➔ special code or an obscure combination of double clicking keys)? ➔ repeat operation ➔ Wisdom: Users will make errors no matter what macros else is done to improve the interface, and one should therefore make it as easy as possible to recover from these errors.

Wisdom: In general, interfaces should show a high degree of responsiveness, to the extent that paying attention to the user new actions should get higher priority than finishing the user's old

actions (like stopping a printer). 33 34

Speeding up the Interaction GOOD ERROR MESSAGES

Ö Are users allowed to jump directly to • Error messages should: the desired location in large information spaces? Ö be phrase in clear language Ö Are users allowed to reuse their interaction history (i.e. list of Ö avoid obscure codes documents previously accessed)? Ö be precise

Wisdom: The following are shortcuts to Ö help the user solve the problem consider: • function keys • repeat last command Ö not intimidate the user • templates • repeat last operation Ö not blame the user • wizards • working groups • double clicking • history list Ö avoid abusive terms such as fatal, • type-ahead • list files by date • click-ahead • default values illegal, etc. 35 36 PREVENT ERRORS HELP AND DOCUMENTATION

• Avoid putting the user in error • Provide on-line help prone situations

Ö Are there mechanisms to prevent errors due to: • Provide useful manuals

➔ spelling names of objects or operations • Provide good task- ➔ case sensitive text oriented search and look ➔ operations with serious consequences up tools ➔ use of modes ➔ other situations

37 38

Good Help and Documentation USABILITY TESTING WITH USERS

Wisdom: • It is the most fundamental usability The fundamental truth about documentation is method that most users simply do not read the manuals.

The quality of help texts is far more important • It is irreplaceable than the mechanisms by which those texts are accessed. • It provides direct information about Ö Does the system provides documentation? how people use computers

Ö Does the system provides online help? • It detects interaction problems with Ö Is a "minimal manual" provided (one that only gives whatever information is absolutely the interface necessary in order for the users to get started using the system with common tasks)?

39 40

TESTING ASPECTS STAGES OF A TEST

• Test Goals • Preparation

• Test Plans • Introduction • Test Tasks • The test itself • Test Users • Debriefing • Ethical Aspects of Tests with Human Subjects

41 42 Test Plan Purpose

• Purpose • Describe in general • Test objectives terms the reason for • User profile conducting the test • Methodology • Task list • Test environment • Data to be collected • Results report

Based on Jeffrey Rubin’s Handbook of Usability Testing 43 44

Objectives User Profile

• Indicate what you want to • The users should be selected according to the accomplish with the test objectives of the test. ➔ computer experience Good examples: ➔ domain experience ➔ Compare the effectiveness of novice users vs. ➔ demographics expert users of interface A. ➔ Compare the user effectiveness and user • When testing an application the users should be satisfaction between version A and version B representative of the eventual users of the of an interface. application.

➔ Determine navigation problems of interface B. • The number of users needed for the test depends on: ➔ Determine if the users of interface D are able ➔ degree of confidence in the results required to use buttons Y and X, and if they ➔ the available resources to conduct the test understand their functionality. ➔ the availability of the type of users required

Bad example: • Most usability problems can be determine with four to eight users. ➔ Determine if a product is usable. 45 46

Methodology Test Design

Provide an overview of each facet of the • Between-Subjects Design - each test from the time the users arrive until module of the application is tested the time they leave. with a unique set of users • greeting the user • consent and background forms • Within-Subjects Design - each part of the test is done with the same group • orientation script of users • pretraining ➔ • test design transfer of learning effect • data to be collected ➔ the order of tasks need to be • post test questionnaires balanced out • debriefing

47 48 Task List Test Environment

• The tasks should satisfy the test objectives. • Indicate the environmental conditions that need to be set up • The task list should indicate: or simulated

➔ brief description of each task

➔ materials and machine states (screens) required • Indicate the equipment needed to conduct the test ➔ description of successful completion of each task

➔ minimum and maximum times for completing the tasks (optional)

• The first tasks should be easy to accomplish (hard ones should be last) 49 50

Data to be Collected Results Report

• Performance measures • Indicate how the collected ➔time to complete each task data will be presented ➔ number and percentage of tasks completed ➔ count of object selections ➔ count of error commission • Indicate how you intend to ➔ count of incorrect menu choices communicate the results ➔informal meeting • Preference measures

➔ease of learning ➔formal report ➔ ease of use overall ➔formal presentation ➔ usefulness of application ➔ how well the application matches expectations ➔ one prototype vs. another prototype 51 52

Orientation Tips for Conducting the Test

• Introduce yourself and any other observer. (Offer refreshments.) • Treat each new participant as an individual. • Explain why the users are here. • Be aware of the effect of your voice and body language. • Reaffirm the users that their participation will be remain anonymous. • Don’t make any comments to the participants about their performance on the test. • Describe the lab environment. • If the situation arises, indicate the participants that • Explain what is expected of the users. there is no right or wrong response. • Assure the participants that they are not being • Don’t rescue the participants when they struggle. tested. (Yet, don’t let them struggle for too long.) • Explain any unusual requirement such as “thinking • Assist the participant only as a last resort (especially aloud”. when frustration takes over). • Mention that it is OK to ask questions. • Avoid interruptions during the test. • Ask is the participants have any question before • Observers should be out of sight and silent. starting the test. • Take notes (disimuladamente) on interesting • Refer to any forms that need to be completed. 53 situations. Talk about them during debriefing. 54 What NOT to Say to Participants (J. Rubin) QUESTIONNAIRES AND INTERVIEWS

10. Saying, “Remember, we’re not testing you,” more than three times. 9. Are you familiar with the term “outlier”? • Indirect methods of evaluating usability of interfaces 8. No one’s ever done that before. 7. HA! HA! HA! • Can reveal what features of an 6. That’s impossible! I didn’t know it could go in interface the users like or upside down! dislike 5. Could we stop for awhile-watching you struggle like this is making me tired. • Method mostly used after user 4. I didn’t really mean you could press any button. testing 3. Yes, it’s very natural for observers to cry during a test. 2. Don’t feel bad, many people take 15 or 16 tries.

1. Are you sure you have used computers before? 55 56

Other Issues

• Conduct a Pilot Test

• After the test, let the users know about unmentioned things such as “Wizard-of Oz technique”.

57