Successfully reported this slideshow.

Achieving A Great User Experience For Enterprise Software



1 of 40
1 of 40

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Achieving A Great User Experience For Enterprise Software

  1. 1. Paul Sherman Sherman Group User Experience
  2. 2. 1.  The  enterprise  app  vendor’s  lament…   2.  And  the  silver  lining     3.  Know  thy  user…but  more  importantly,   know  thy  user’s  problems   4.  Buyers…how  to  push  on  your  vendors   2  
  3. 3. 3  
  4. 4.  It’s  HARD  to  change  enterprise   software  applications!   Why?   4  
  5. 5. Big  fat  releases   Big  fat  customers  =  multiple  squeaky   wheels   Customization   Embedded  in  customers’  workflows   5  
  6. 6. 6  
  7. 7. There  are  leverage  points  for  improving   the  user  experience  of  enterprise   software.   7  
  8. 8.  Captive  users…    You  have  an   opportunity  to   improve  the  user   experience  without   immediately  losing   the  user  base.   8  
  9. 9.  It’s  almost  always   about  workflow…    If  you  improve  the   workflow,  you   improve  the  user   experience.    And  you  make  your   customer  very,  very   happy.   9  
  10. 10. 10  
  11. 11. If  you’re  going  to  improve  your   app,  you  have  to  know  what   you’re  solving  for!   11  
  12. 12. Your  boss/VP/CEO:     “We  need  to  make  the  product  more  usable!”   You:     “In  what  particular  areas  are  users  having   trouble?”   Boss:     “It  just  needs  to  be  easier  to  use!”   12  
  13. 13.  Usability  means  different  things  in   different  contexts.  It’s  all  about  the   users’  needs  and  goals.     Do  you  need  to  solve  for…     Learnability?  Memorability?  Efficiency?     Error  prevention?   13  
  14. 14. Learnability   Sa3sfac3on   Memorability   Usability   Error  Preven3on   Produc3vity    Shneiderman,  B.  (1998).  Designing  the  User  Interface.  Reading,  MA:  Addison  Wesley  Longman  
  15. 15. Ask  yourself:     Do  you  *know*  what  the  users’   problems  really  are?   15  
  16. 16. A  story  about  an  expense  reporting   application…   …built  for  the  wrong  context  and  wrong   users.   16  
  17. 17.  Vendor  X  built  an  expense  reporting  app.    The  little  bit  of  research  they  did  was  flawed…    They  interviewed  executives,  execs’  admins,   and  finance/accounting  staff  to  determine  the   workflow  and  terminology.   17  
  18. 18.  Accounting/finance:      Thought  in  financial  terms.  Cost  centers,   allocations,  etc.    Execs:      Frequent  travelers.  Wanted  quick  and   efficient  expense  report  entry  for  their   admins.   18  
  19. 19.  So,  Vendor  X  made  the  application  quick   and  efficient...with  loads  of  accounting  and   finance  terminology.     19  
  20. 20. What  do  you  think  happened?   20  
  21. 21.  The  application  worked  great  for  exec   admins  and  accounting…    But  for  the  95%  of  users  who  weren’t  in   these  groups…it  sucked.   21  
  22. 22.  Most  users  (technical  staff  and  first-­‐line   managers)  traveled  1x  per  quarter  or  less.    They  forgot  how  to  use  the  app  between   trips.    And  the  finance  terminology  made  no   sense  to  them.   22  
  23. 23. Lots  of  expense  report  errors   The  books  were  screwed  up   Reduced  productivity  for  majority  of  users   Non-­‐compliance   Frustration   23  
  24. 24. OK,  we  get  it.     Now  give  us  some  guidance!   24  
  25. 25.  Always  discover  the  context  of  use!   Who’s  going  to  use  the  app  most  (and  least)   How  often   Why   What  else  they  do   ✔   ✖ 25  
  26. 26.  Don’t  just  take  the  buyer’s  word  for  it…   especially  if  it’s  the  IT/IS  group.     Sorry!  But  it’s  true.   26  
  27. 27. Before  you  redesign  anything,  identify  the   problems…   Is  it  navigation?  (“I  can’t  find  how  to…”)   Is  it  workflow?  (“This  takes  too  long.”)   Is  it  mental  model?  (“I  don’t  know  what   you’re  asking  me  to  do  or  why.”)   27  
  28. 28. Usability  test  it  before  releasing  it.   My  favorite  product  manager  referred  to   usability  testing  as  “decision  insurance.”   It’s  2009…do  I  really  need  to  say  this?   28  
  29. 29. Vendors  in  the  house?  Discuss.   29  
  30. 30. 30  
  31. 31.  Buyers!  Your  technology  selection  processes   are  incomplete.  You’re  not  assessing  the  user   experience  of  the  technology  you  buy.      You’re  incurring  huge  hidden  costs.      You’re  letting  enterprise  vendors  get  away   with  building  products  with  poor  usability.   31  
  32. 32.   The  enterprise  identifies  the  need  for  a  better,  more   scalable,  or  faster  process,  and  makes  the  business  case   for  deploying  a  new  application.     The  IT  org  sets  technical  and  feature  requirements…that   are  often  informed  by  vendors’  feature  lists.     Purchasing  solicits  vendors.     Purchasing  evaluates  vendors  on  the  basis  of  their   responses  and  generates  a  short  list  of  possible  vendors.     IT  brings  vendors’  systems  into  the  enterprise’s  test  labs   for  performance  and  technical  trials.     The  enterprise  selects  a  vendor.     IT  deploys  the  new  application.     Employees  freak  out  to  varying  degrees.   32  
  33. 33. Where  was  the  workflow  analysis?     The  usability  testing?   33  
  34. 34. 1.  Identify  and  describe  the  target  user   groups  that  currently  perform  the  task  or   process  the  software  will  automate.      Make  sure  you  know  their  characteristics,   motivations,  and  work  context.   34  
  35. 35. 2.  Model  and  describe  the  current  workflow   the  target  users  employ  to  accomplish   the  task  or  process.    Use  simple  methods  like  task  analysis  and   time-­‐on-­‐task  measurement.   35  
  36. 36. 3.  Discover  what  the  target  users  typically   do  before  and  after  the  task  being   automated.      This  will  give  you  an  understanding  of   whether  you  can  automate  the  task’s   precursors  and  antecedents  or  somehow   include  them  in  the  potential  solution.   36  
  37. 37. 4.  Then  assess  the  technology  solutions  for   their  goodness-­‐of-­‐fit  to  the  context,  tasks   and  workflow  of  the  target  users.   37  
  38. 38.  Feature  comparisons  and  demos  matter  a   whole  lot  less  than  actually  putting  real   users  on  the  application  and  having  them   perform  tasks.     38  
  39. 39. Enterprise  buyers?  Do  you  assess  usability?   39  
  40. 40.  Paul  Sherman    Sherman  Group  User  Experience    Twitter:  pjsherman   40