Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
heuris'c evalua'on
dr. carman neustaedter
Credits: Saul Greenberg 1
heuris'c evalua'on
follow design principles inspect interfaces for common errors
2
design principles
broad usability statements that guide design efforts. they are derived from common design problems across many systems.
3
heuris'c evalua'on
interface inspec@on method that is used to see if an interface complies with design principles
works with paper, med-‐fi prototypes, and working systems
4
method
3-‐5 inspectors usability engineers, end users, double experts inspect interface in isola@on compare notes aHerwards single evaluator catches ~35% of the usability problems five evaluators catch ~75%
5
assess severity
example: [0] not a problem [1] irrita@ng [2] minor [3] major [4] can’t complete task
6
heuris'c evalua'on
pros: minimalist approach catch many problems with a few guidelines guidelines are easily remembered and easily applied cheap and fast to do end users are not required
cons: high level principles doesn’t go aHer subtle@es can’t be treated as a simple checklist
7
1. simple and natural dialogue
use the user’s conceptual model match the user’s task sequence
8
why can’t I delete part of the image?
9
1. simple and natural dialogue
present exactly the informa@on the user needs less is more (less to learn, to get wrong, to distract) informa@on should appear in natural order group related informa@on remove or hide irrelevant or rarely needed informa@on remove modes simple naviga@on
10
modes
edit or new mode? why two modes?
11
27 different modes for a brush
12
modes
some@mes okay make sure user knows what mode they’re in
13
naviga'on
14
2. speak the user’s language
use terminology from user’s task
15
2. speak the user’s language
16
2. speak the user’s language
use meaningful icons use meaningful mnemonics
(memory aids) e.g., ALT FS to save in the menu bar
use meaningful abbrevia@ons
e.g., CTRL + S to save
17
3. minimize memory load
computers are good at remembering people are not… promote recogni@on over recall
what file was I working on?
18
3. minimize memory load
19
3. minimize memory load
give input format, example, and default
20
3. minimize memory load
now try and do what it says…
21
3. minimize memory load
how much did it cost to fly the previous day?
22
4. be consistent
consistent input syntax
consistent effects commands have same effect in different situa@ons e.g., copy, cut, paste is consistent in applica@ons
consistent language and graphics
23
4. be consistent
These are labels with a raised appearance.
Is it any surprise that people try and click on them?
24
5. provide feedback
con@nuously inform the user about what the system is doing how it is interpre@ng the user’s input user should always be aware of what is going on
cursors for short delays progress bars for long delays
25
5. provide feedback
response @me: how users perceive delay < 0.1s perceived as instantaneous 1 s flow of thought is uninterrupted,
delay is no@ced though 10 s limit for keeping user focused on
dialog > 10 s user will want to perform other tasks
while wai@ng
26
5. provide feedback
27
5. provide feedback
What did I select?
What mode am I in now?
How is the system
interpre@ng my ac@ons?
28
5. provide feedback
be as specific as possible, based on user’s input best within the context of the ac@on
29
6. provide clearly marked exits
offer an easy way out of situa@ons strategies: cancel bueon (for dialogs wai@ng for user input) universal undo (can get back to previous state) interrupt (especially for lengthy opera@ons) quit (for leaving the program at any @me) defaults (for restoring a property sheet)
30
6. provide clearly marked exits
31
7. provide shortcuts
let experienced users perform opera@ons quickly strategies: keyboard shortcuts, command comple@on context menus type-‐ahead (enter input before system is ready for it) history systems naviga@on jumps (go directly to window you want)
32
7. provide shortcuts
press alt key, get all keyboard shortcuts highlight text, get context menu
web history
33
8. deal with errors in a posi've way
people will make errors mistakes: conscious delibera@ons lead to error slips: unconscious behavior gets misdirected e.g., drive to store, end up at office usually due to inaeen@on arises from similar ac@ons
34
system responses for errors
warn warn people that an unusual situa@on is occurring when overused, becomes an irritant e.g., Windows 7 full screen: ‘are you sure you want to con@nue?’
40
system responses for errors
do nothing illegal ac@on just doesn’t do anything user must infer what happened e.g., enter leeer into a numeric-‐only field (key clicks ignored) e.g., put a file icon on top of another file icon (returns it to original posi@on)
self-‐correct system guesses legal ac@on and does it instead but leads to a problem of trust e.g., spelling corrector
41
system responses for errors
lets talk about it system ini@ates dialog with user to come up with solu@on to the problem compile error brings up offending line in source code teach me system asks user what the ac@on was supposed to have meant ac@on then becomes a legal one
42
provide meaningful messages
use the user’s language don’t make them feel stupid
Adobe's ImageReady AutoCAD Mechanical
Windows Notepad Microsoft's NT Operating System
43
9. provide help
help is not a replacement for bad design! simple systems walk up and use; minimal instruc@ons most other systems feature rich simple things should be simple learning path for advanced features
44
documenta'on
many users do not read manuals prefer to spend their @me pursuing their task
usually used when users are in a panic paper manuals unavailable in many businesses! online documenta@on beeer good search/lookup tools online help specific to current context
some@mes used for quick reference syntax of ac@ons, list of shortcuts…
45
types of help
tutorial and/or gekng started manuals short guides that people are likely to read when first obtaining their systems
encourages explora@on and gekng to know the system tries to get conceptual material across and essen@al syntax
on-‐line “tours”, exercises, and demos demonstrates very basic principles through working examples
46
types of help
searchable hypertext easy to navigate, but poten@ally too much informa@on
Helper quickly annoying
47
types of help
reminders keyboard shortcuts tool@ps and other context-‐sensi@ve help
48
types of help
wizards… walks user through a task dangerous if user gets stuck
49
that is it!
nine principles of design simple and natural dialog speak the user’s language minimize user’s memory load be consistent provide feedback provide clearly marked exits provide shortcuts deal with errors in a posi@ve manner provide help
50
evalua'ng heuris'c evalua'on
problems found by a single inspector problems found by mul@ple inspectors individuals vs. teams self guided or scenarios?
51
problems found by single inspector
average over six case studies 35% of all usability problems; 42% of the major problems 32% of the minor problems
not great, but finding some problems with one evaluator is much beeer than finding no problems with no evaluators!
52
problems found by single inspector
varies according to: difficulty of the interface and exper'se of inspectors
average problems found by: novice evaluators -‐ 22% (no usability exper@se) regular specialists -‐ 41% (exper@se in usability) double specialists -‐ 60% (exper@se in usability and domain)
tradeoff: novices poorer, but cheaper
53
problems found by single inspector
evaluators miss both easy and hard problems ‘best’ evaluators can miss easy problems ‘worse’ evaluators can discover hard problems
54
problems found by mul'ple evaluators
3-‐5 evaluators find 66-‐75% of usability problems different people find different usability problems only modest overlap between the sets of problems found
55
problems found by mul'ple evaluators
where is the best cost/benefit?
56
individuals vs. teams
nielsen recommends individual evaluators inspect the interface alone
why? evalua@on is not influenced by others independent and unbiased greater variability in the kinds of errors found no overhead required to organize group mee@ngs
57
self guided vs. scenario explora'on
self-‐guided open-‐ended explora@on not necessarily task-‐directed good for exploring diverse aspects of the interface, and to follow poten@al pioalls
scenarios step through the interface using representa@ve user tasks ensures problems iden@fied in relevant por@ons of the ui ensures that specific features of interest are evaluated but limits the scope of the evalua@on
58
example
perform a heuris@c evalua@on on the following interface. iden@fy where the interface meets heuris@cs and where it does not.
59
60