7 Reasons for UX #FAIL in Enterprise Software

It is nearly impossible to have a good UX consistently in an enterprise software.

That is a strong statement and I’d love to be proved wrong. I come from a background where I developed applications within an enterprise with a defined target audience. I also did software that was available publicly on the Internet. For more than 15 years now, I’ve seen all sides of the table by being both a developer and end user.

First, What works well for Non-Enterprise Software

When you create a software for general public consumption, following is what aids you:

1. Clarity of Thought. You and your team have planned it out and immersed yourself in it. You know what needs to be done and are focused towards the goal.
2. Passion. Not only the design & development team, but even stakeholders or subject matter experts are passionate about the software and what’s being built.
3. Authority. It is for the general public, and you have the authority to take decisions which you think are in the best interest of everyone.
4. Innovation. That’s the buzzword. You want to innovate and so does everyone else in your team.
5. Focus. Your focus is to create an Awesome User Experience, period.
6. Analytics. You measure the usage, and you know what’s working and what isn’t. That impacts the further development, and the evolution continues.

And thus you have a software which you are proud of, and you don’t hesitate to modify it because you know that incremental innovations would always enhance the user experience. Take any top rated app on the App Store, and you would know that this method is what made them successful: Build-Measure-Learn—Repeat

Enterprises? What a #FAIL

The same gleamy eyed UX expert, who built software for the masses and totally, totally inspired from the UX revolution happening around the globe, stumbles, and more often than not fails badly in an enterprise setup. The leading 7 causes are:

1. Target Audience. This is considered a blessing – you know your users in detail, which systems they have access to, and intelligently design your solution around them. Wrong. You have a fundamental flaw: The audience that you are looking at are deeply uninterested in what you are trying to build. You shouldn’t expect any excitement from them except the key people.
2. Burden Factor. Unlike an app that the users download from App Store with free will & interest, an enterprise software is forced upon them. How many of you would like to fill in your time sheets, or apply for leaves through a portal – every day?
3. Resistance. Legacy application being upgraded? There would be resistance, everywhere. Bad karma for you again.
4. Bottom Line. A good UX process not only requires significant time investment, but good money too. Not many organisations would want to invest in it as the immediate results are always intangible.
5. Authority & Stake Holders. If the stake holders do not believe in UX and its importance, then they’ll just sign it off. No approval, and no go-ahead. Also, despite a large user base, they are usually the ones who are the owners and speak for others – and thus it is imperative for them to believe in it.
6. Features First, UX Second. All that matters are the Features – measurable, tangible and objective; the UX is always subjective, and often confused with design and visualisation. The Target Audience also have their wishlist and thus the features reign supreme. This may not be a cause of concern when the software is built the first time – but future updates and iterations can twist it in a way that the UX focus would go for a toss.
7. Training Costs. Any new software deployment or a visual change is accompanied with a training across the organisation. It leads to reduced productivity, increase in complaints and overall costs – thus most prefer to avoid it.

It is often too late when the lack of good UX is realised. The people change, and their replacements want to maintain the status quo and thus nothing really changes. And eventually only features are added by the developers, and visual design done by the designers based on what seems appropriate to the stakeholders.

Tackling the UX in Enterprise Software

All is not lost, but I’d admit it is not easy. The Enterprise UX 2016 (http://enterpriseux.net/) aims to create a better and sustainable environment, and I wish them luck. However, following are my few cents.

1. Right People. It can make all the difference. Someone who can develop AND understands design AND understand interacting with customers and gauging their needs might be able to get it right.
2. Compromise for Flexibility. Assume that the UX might change in the future, and more features put in the system. Thus the UX shouldn’t always be the holy-grail, but rather flexible to incorporate future features.
3. Transition Plan. Create something like a ‘beta’ preview so that the early adopters can experiment and rollback to the stable version if it doesn’t meet the needs. All new users should be on the new interface, and the older ones slowly transitioned.
4. Luck. That you get the right Stakeholders who believe in UX. I’ve been lucky on many occasions, and that has helped significantly.
5. Complete Package. Always demonstrate the solution rendered well – including UX and design (and not just wireframes), and preferably with the right content. That creates much more impact, and can help out with getting the Stakeholders on board for UX.

Apparently, there are more who share the same sentiments. Uday Gajendar in his post Why I design enterprise UX, and you should too! is quite optimistic, and I guess that’s the way to be.

What has been your experience in creating an Enterprise Focused Software, and how much of a role has UX played in it?

Advertisement