Three Common Problems in Enterprise System User Experience

Enterprise systems seem to be the last holdout against UX design. The feeling on the ground seems to be that if a user has to use a system then their experience when using that system is irrelevant. Frank Spillers, at Experience Dynamics, says that over 70% of enterprise projects fail because of a lack of user acceptance.

That’s a pretty substantial number and one that should, in any sane world, leave enterprise management teams running for help from UX teams. Yet, the assumption that none of this matters when usage is compulsory continues.

Sure, we have no doubt that it’s vital for enterprise systems to solve business problems. That’s the reason for investing in such systems. But without wide-scale adoption and acceptance within the business; how can a system solve a business problem? If people resist working on a system, fail to use a system properly, or (as in many cases) they try to “cheat the system” (by taking short cuts that “break” the process) – then there’s no value in the investment.

So what are the main challenges in delivering quality UX in the enterprise environment and what can be done about them?

The Belief that Complexity Equates to Low Levels of User Friendliness

Unfortunately, this particular problem tends to infect the whole of many enterprise environments. You can see it in their paperwork when reports tend to be several hundred pages long and are never read – despite the complexity they purport to capture. You can find it in management process where bits of paper are pushed in an endless chain around the office.

You can also find it in enterprise systems. The “complexity” of the process is never addressed. No though is put into finding a more effective way to execute the process for fear of treading on the toes of managers defending their silos. So the system mimics the “real world” and any user considerations are simply reduced to a few tweaks in the user interface.

Of course, solving this issue is relatively simple. System development is put on hold until the real world processes have been studied and simplified wherever possible. Systems should be built with these new, easier to use processes in mind.

The Belief that User Compliance Can be Forced Through Complex Systems

I’m a trainer and it always amazes me how often people think that you can force someone to do something they don’t want to do with more training. Systems engineers suffer from the same frustrations.

If your processes suck and there are onerous on the individual without any good reason for that burden – people are going to do whatever they can to avoid dealing with those processes. Training, systems, and even management are going to be beaten by the human desire to avoid painful and pointless exercises.

The more pointless the exercise, the more ingenious workarounds that people are likely to come up with. You can’t make people comply with stupidity no matter what controls you put in place.

Years ago, I was asked to fix a manager’s poor levels of productivity through training. A quick examination of his day led to a stunning conclusion. His poor performance was due to a refusal by the IT department to move his printer near to his desk. All of his work was on printed reports and he had to traverse the entire building to collect these reports. So, unsurprisingly, he was wasting half his day on walking to collect reports rather than doing the work.

Bad systems force users to do a lot of walking they don’t need to do. Again, attention to process design before implementing systems can help you avoid this kind of pain.

The Belief that the More Data We Have the More Information We Have

Yes, we live in the age of big data. And because of this, we are endlessly bombarded with requests to capture more and more data. After all, there must be opportunity in that data right? Wrong.

Data has to have a point before it adds value to an organization. Capturing data that you don’t need now just in case you might need it at some unspecified point in the future – leads to long winded and painful system processes.

When systems are designed the data they are designed to capture needs challenging. What’s its purpose? What does it enable us to do that we couldn’t do without it? If these questions don’t result in satisfactory answers – you probably don’t need the data.

Again, this should be a relatively simple problem to solve but it needs someone there to solve the issues before they become a global issue for the enterprise.

Enterprise System Development Projects Need a Head of UX

Given the huge failure rate of enterprise systems projects it’s time for the corporate world to recognize the importance of user experience.

Enterprise system investments run into the millions and yet, at this moment in time, they are rarely given the same level of attention as the products that those enterprises produce for their own customers. It’s amusing to hear those same enterprises refer to their employees as their “internal customers”. If that’s the case, why aren’t they treating them as such?

It’s the politics involved that makes this too difficult to change without a senior role dedicated to the user experience of the internal customer. The Head of UX needs enough authority to break down silos and question processes without being told; “It’s none of your business” or “We’ve always done it like that.”

Summary

UX failures are costing enterprise system projects millions of dollars a year. These problems should be relatively simple to fix. All it really requires is for enterprises to start considering the UX of their own systems in the same way that they consider the UX of the products that they sell. The first step in this process is to develop a UX role with the power and authority to truly represent users in system development projects.

Header Image: Author/Copyright holder: Blue Rooster. Copyright terms and licence: All rights reserved. Img