How did software that is so hard to use become so prolific in the B2B space?
Customer: I want this new button right there.
Developer: This menu is already quite cluttered with other features we've put here. Could we not add it to a new menu?
Customer: No, I spend like 95% of my day in this menu, so I want it right here.
Developer: This might be confusing to some of our other customers, though.
Customer: Yeah well they're not paying for it. Do you want my money or not?
The people who design/build enterprise software rarely eat their own cooking. Feedback cycles are infrequent and long or non-existent.
When you say clunky, inefficient and bizarre UX, you mean the user UX, which doesn't matter in enterprise. If it didn't save a VP or better yet the CEO of a large company mad time, make them more money, save them money or mitigate risk, it would not be there in the first place. Because systems like SAP are incredibly good at both doing that in complex use cases and making the case for it, they prevail.
Startups often try to go enterprise and say their UX is better. Notion may be great, but based on pricing it's creating <$10/user/month in enterprise value. There are products in specialized industries (e.g. Bloomberg in finance) that charge $2000/user/month. They serve the real customer, which is the VP or CEO who signs, very well.
Buying one person, or one team, a tool like Adobe CS doesn’t really change any processes so it’s easy. But dropping a new system in that changes a process and everything changes.
“Helen from risk wants a new fraud detection system” is effectively the same as “Helen wants to review all our fraud detection policies and if anything changes and subsequently goes wrong it won’t just be Helen that gets fired”. There’s a huge pressure on the software provider to make their system support whatever unique, crazy or arcane processes the risk team were previously using, and support all existing interfaces into and out of the risk team, because nobody wants to sign off on any changes. So enterprise software has to be crazy flexible. And flexibility makes for bad UX.
If the software relies on sales people who answer "Yes, absolutely!" to every question from prospects, you end up in a bad place.
Generally speaking, User != Purchaser. You push to include User in the loop and development process. Sometimes, you are not allowed, and sometimes the contract itself is signed contingent on this. It can get carder if you're not allowed to sollicit users' feedback, but are given carte blanche to develop: you're developing based on what you think will be right for the user. You will have hard conversations with the users at the end of the project when they receive the software and you're allowed to interact and "fix a few things here and there", at which point you'll try to cram in as much user feedback as possible to "make it right".
Now, if you're not building for a particular client and you are working on your product that's targeting the enterprise, there are other distribution methods where you design for the user who works for an enterprise so there's a "de facto" adoption, which then can lead to an enterprise software that is good.
A quick litmus test: if you are on a website and want to use the software, and there's a button that reads "Schedule Demo", or "Book Appointment with Sales", or "Contact Sales", chances are the software in question is the kind you don't like.
There's a lot of other problems. "Enterprise" software often comes from companies that aren't actually software companies, in the sense that they aren't run by the guy who wrote the first version of the product. They're run by non-tech people who hired some developers to build their idea. These people typically create large and bloated product and project management organisations that try to convert programmers into replaceable cog wheels that convert JIRA tickets into code commits. They often dream of out-sourcing their devs entirely and would love to do nothing but sit in the middle collecting fees without needing to write software. They certainly cannot judge the quality of the work produced, even by looking at the user interface. Maybe they have some vague feeling it could be better but they aren't going to dive into the detail and figure out why or how.
Developers know this and have minimal loyalty to the product or organisation, so whatever work is done is always minimal effort work. If the ticket can be marked as done they move onto the next one.
Successful consumer facing software firms are often quite different. They're run by someone who uses their own product, at least sometimes, and who probably made the first version so they care about the details and know what's possible. They hire developers who are NOT domain experts, on the assumption that if you need expert knowledge to use the app you're not making consumer software, so they hire people who have a proven track record of creating beautiful and easy to use UI. What the UI exactly does is not so important. They tend to trust developers more, in my experience, because they know a small performance or UI edge can be sufficient to differentiate them in the market.
On the other hand enterprise software implementations always include a business change element which involves lots of communication and training, especially for key users. Therefore there is less obligation for vendors to build intuitive solutions.
Enterprise users are already all there. Once a solution is choosen users are forced to use the software as is, no matter how bad or good it is. There is just no more incentives to make it better for corporate users. Think SAP, it make me think of this every time I see it.
If they will pay for button or feature right there... often there it goes.
If they like the layout or design of something they're familiar with...there it is.