Raising the Bar for the Enterprise Software User ExperienceIn December, The Wall Street Journal reported that Avon Products, Inc. had spent 4 years and $125 million with SAP on a major software project that was being terminated. Apparently, Avon discovered that “users -- the company’s sales force -- found the new system so burdensome and disruptive to their daily routine that many left Avon.” Avon paid dearly in money and time, as well as employees, for a poor user experience. In this case, that cost has been quantified.

For most people, the terrible software they’re forced to use as part of their job never gets this much attention. It’s not clear what went wrong for Avon, but they’re certainly not alone in facing a disconnect between what they bought and what their users wanted.

How does this happen? There are several potential points of failure:

Buyers aren't Users

The people who evaluate enterprise software and make the purchasing decision are rarely the people who will be using the system. Even if they know the users and want them to be successful, buyers don’t adequately represent users’ needs during the purchasing process, and are likely to prioritize cost or technical constraints over factors that will guarantee users a positive and productive experience.

Remedy: The purchasing process should include discussions about who will be using the software and what those users need to accomplish. Purchasers should disqualify vendors who are unable to engage with real users and explain how their software can be customized (if necessary) so that users can accomplish their goals, and how assessments can be conducted during the customization process to ensure the effort is successful. The purchasing team needs to consider not simply the resources required for that customization effort, but which tool is likely to reward that investment with the best user experience.

Implementers aren't Users Either

Once the software is purchased, an implementation team typically takes over to determine the schedule and details for deploying it. This implementation team doesn’t usually include users. And though there may be business analysts charged with understanding user requirements, the team prioritizes ease of implementation and maintenance over users’ needs. Consequently, sticking with an out-of-the-box implementation gets prioritized, because that will make upgrading later more straightforward.

Remedy: People identified as key users of the new system should be included on the implementation team to highlight the tasks that make them successful, and ensure those get prioritized. These key users should also validate that the design is appropriate for their needs as the work progresses to reduce the chance of surprises after rollout.