Don't Assume: Usability in Enterprise Applications

Our organization has a thing we call "Enterprise Applications". It is used to describe applications that are used across the various business groups within the company, and it's also used to describe the people who work on those applications.

Many of the applications are third-party. There are big, BIG players in that space: for customer relationship management, finance, employee forms, HR functions, training records, procurement, and...you get the drift.

My understanding is that there are always efforts underway to unify and integrate the data that is behind all of these systems. I choose to think that's a good thing. Data is great. We all need data.

As a usability engineer, I am often conducting interviews with users of corporate systems to learn about their needs and behaviors. Without fail, when talking about the current process or system, one of these "enterprise" system comes up, and they ask me if I can make it work better. (I have found that some do not distinguish it from the system we are talking about--"IT is IT", which is a fair assessment, or they see our conversation as an opportunity to get a word in with someone who claims to understand usability--a "while we're on the subject..." sort of thing).

Over and over again, we roll out awful user interfaces that come out of the box with the software. We have the expectation that the manufacturer has a huge staff of user experience engineers and has done the research and design to make usable software.

In my informal inquiries into this, I've found that it's usually due to some combination of the following issues. The evaluators and implementers (usually IT people):

• thought it was usable out of the box
• relied on the hope the manufacturer has a huge staff of user experience engineers who did research and design to make usable software
• fixed a couple of things they saw, but did so without involving users
• felt usability work would add expense to the project
• obtained inadequate or incomplete usability services
• never even considered usability

The applications I use on a day to day basis in this arena seem to have been designed primarily for those who are in data-centric roles in the organization. Then some of the functions are stripped away so the average user can use it. Very little, if any, consideration for what they are trying to accomplish.

Here are some lessons I've learned:

1. When evaluating third-party software, include sufficient usability work.

• An heuristic evaluation by one or more "experts", but not enough to say you've done usability work. In the end, the users are the experts in whether or not it's usable.
  
• Well-formed usability engineering does not add to the long-term cost of a project. In fact, it can save money (on training and support costs, to name a couple) and increase employee satisfaction.

2. When implementing third-party software, ensure you have well-defined audiences and clear usage scenarios.

• That doesn't have to mean a 257-page document of every use case including alternates and dependencies.
• A data-centric user interface is great for the 20% of users who understand the data; the other 80% of task-centric users probably need a different interface to support their tasks.
• Knowing your audience and usage scenarios can help you design for effectiveness, as well as usability testing throughout the implementation process.

3. When rolling out third-party software, ensure that users have ample warning, training, reference and help available.

• Don't drop a specialized application on everyone's desktop and expect everyone to immediately understand it or "figure it out".
• Remember that different people have different learning styles, so a multi-pronged approach is good.
  
• Don't assume that the third-party software manufacturer has done good human-centered design. They may have designed a convenient way to manipulate their data, but they are not the experts in how your employees do their jobs.