Achieving A Great User Experience For Enterprise Software
22 likes3,541 views
The document discusses challenges in improving user experience for enterprise software, highlighting the importance of understanding the users and their specific problems. It emphasizes the necessity of proper workflow analysis and usability testing before deploying applications, rather than solely relying on buyer input. Additionally, the text advises enterprise buyers to assess usability in their technology selection processes to avoid hidden costs associated with poor user experiences.
Achieving A Great User Experience For Enterprise Software
- 1. Paul Sherman Sherman Group User Experience
- 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
- 4. It’s HARD to change enterprise software applications! Why? 4
- 5. Big fat releases Big fat customers = multiple squeaky wheels Customization Embedded in customers’ workflows 5
- 6. 6
- 7. There are leverage points for improving the user experience of enterprise software. 7
- 8. Captive users… You have an opportunity to improve the user experience without immediately losing the user base. 8
- 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
- 11. If you’re going to improve your app, you have to know what you’re solving for! 11
- 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. 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. Learnability Sa3sfac3on Memorability Usability Error Preven3on Produc3vity Shneiderman, B. (1998). Designing the User Interface. Reading, MA: Addison Wesley Longman
- 15. Ask yourself: Do you *know* what the users’ problems really are? 15
- 16. A story about an expense reporting application… …built for the wrong context and wrong users. 16
- 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. 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. So, Vendor X made the application quick and efficient...with loads of accounting and finance terminology. 19
- 20. What do you think happened? 20
- 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. 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. Lots of expense report errors The books were screwed up Reduced productivity for majority of users Non-‐compliance Frustration 23
- 24. OK, we get it. Now give us some guidance! 24
- 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. 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. 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. 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. Vendors in the house? Discuss. 29
- 30. 30
- 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. 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. Where was the workflow analysis? The usability testing? 33
- 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. 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. 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. 4. Then assess the technology solutions for their goodness-‐of-‐fit to the context, tasks and workflow of the target users. 37
- 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. Enterprise buyers? Do you assess usability? 39
- 40. Paul Sherman Sherman Group User Experience www.shermanux.com paul@shermanux.com Twitter: pjsherman 40