heurisc)evaluaon )clab.iat.sfu.ca/432/wp-content/uploads/files/heuristicevaluation.pdf ·...

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