Enterprise Software Still Sucks

8 min readJun 21, 2015

Enterprise software isn’t user friendly. It’s often so bad that it costs you time and money, on top of an already hefty price tag.

Sure, ‘user friendly’ is one of the requirements, but no salesman will admit that their software isn’t. And you often can’t really put it through a ‘trial’ in advance, because it takes installation, configuration, training, customization, blah blah blah.

And why does it need so much configuration? Because not only do you have a huge list of requirements (lots of them irrelevant and unnecessary), but the other clients had their specific requirements too, and a consultant needs to ‘program’ the configuration to make it work according to yours.

The good thing is that they’ll throw in some unneeded features for free. This makes the software even more of a jungle to manoeuvre, but hey, no problem, surely they’ll arrange some training for you. And if that doesn’t work, just contact their outsourced support and talk to someone who doesn’t understand half of what you’re saying and vice versa.

Yes, this sounds a cynical, but it’s all true, Dilbert said so!

Hallway testing to the rescue!

“A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.”
Joel Spolsky, The Joel Test — 12 Steps to Better Code

It takes some guts to ask and explain, and people often (virtually always) find it weird. But in my experience, it’s the single best thing you can do to make your software better. (Actually, I’ve got some tips to take the edge off the experience, but that’s out of scope right now.)

So, that’s my proposition: Maybe the vendor can’t provide a ‘real’ trial installation, but surely they have an installation somewhere (what the developer is testing on if necessary) where you can have some of the future users perform basic tasks, and see how far they get without training/asking for help.

And if the vendor can’t facilitate these tests, it means they don’t even have a way to demo or test the software themselves. This is such a huge red flag that you should just forget about them. And if it’s not, they’re lying and errrm… you should just forget about them

Hallway testing has proven invaluable to me when trying to produce user-friendly software. It can also be applied to test third party software before committing.

By the way, “Don’t Make Me Think” by Steve Krug is a very entertaining, short and to-the-point book that you can read in one sitting and will benefit everyone somehow involved in developing (or acquiring) software. If you’ve read this far, it’s very likely that you will benefit from reading it.

Isn’t Hallway Testing only for occasional processes?

I know some might argue that hallway testing is only good for less used software/processes where no training is wanted.

Like a shopping cart checkout process, requesting a day off, or booking an appointment at the doctor’s office.

Some software might have a steep learning curve that pays off by saving you time later on. This software isn’t suited for hallway testing.

It’s still possible for a user interface to cater to new as well as experienced users. You should also be able to accomplish the core tasks in an intuitive way without having to jump through hoops.

Think about how much smoother user on-boarding would go if the software were easy to slide into from day one.

Some example Hallway Testing tasks

Let’s say you’re evaluating a CRM system — I think it would be safe to assume that a new user should be able to do the following:

add a contact
search for this contact
change the contact

And when evaluating a bookkeeping/invoicing system:

add a client
make an invoice for this new client
send the invoice through email

If you need training or a manual for such basic tasks, it’s safe to assume that there’s something wrong with the user interface. Don’t you agree?

Other things to keep in mind

Modern software should be able to talk to other software

Does it provide some kind of API (preferably a web service) to communicate with other software?

This is often overlooked.

If possible, get a programmer to take a look at the API: how difficult and complete is it? This doesn’t have to take long, you can get a good enough impression in about an hour tops.

A while ago I was exploring the possibility to have some of our software talk to one of our partner’s systems. This supposedly required custom development from the vendor, as there was no way to interface with this recently purchased software. And this in 2015.

Another vendor I talked to had an API but no documentation :-/

Responsiveness is a requirement

Responsiveness is just as hard to define as ‘user friendly’, but just as important. It’s absolutely crazy that a human has to wait ‘while the computer is thinking.’ Still, how often does it happen?

Slow, unresponsive software costs not only time, but also a lot of frustration. We all know, but too often ignore this. We often also don’t seem to have a choice but to live with it.

What about including these requirements:

The user should never have to wait for more than 2 seconds, except when generating a report or performing a search.
Report generation/searches should be able to run in the background.
95% of the user’s actions should give a response in less than 1 second.

Yes, these might be hard to measure, and they might be a bit strict… but it should open the conversation to what is feasible, and what is and isn’t acceptable for the users. Let that salesman sweat a bit!

I’ve seen a very responsive, snappy system grind to a halt when coping with a standard load. This could only be solved by throwing more and faster servers at the problem.

Later on, rather by accident, someone discovered the database had been totally misconfigured. If the ‘expert’ investigating the original issue had been a bit more competent, this would have saved a shitload of money. But alas.

Did you hunt on google for alternatives?

There are lots of SAAS providers for the craziest things. They often don’t come with a month-long sales process, a salesman that’ll have lunches with you, consultants to configure everything and trainers to get your users going.

They also lack the hefty price tag and often have a trial version you can try for free.

This software is often user friendly by default. It has to be — it needs to sell itself.

They might not meet some of your requirements or customize to your specs. But are all your requirements really necessary or rather nice-to-haves?

Lots of businesses don’t know how to find these, and there’s no salesman interested in a commission on a $149/month SAAS, or no consultants to assist you with the purchasing process.

Just search for ‘<your software> vs’ in google, and behold: a list of alternatives!

Of course, you could also search for ‘<your software> alternatives’, or ‘<your software> alternatives free trial’.

But I don’t want the data to leave the company!

Okay, there might be a bit of a stigma here because your data is stored in an external environment. How valid that is… that’s for you to decide. Just remember that lots of ‘Enterprise Software’ already has SAAS and thus the data isn’t stored on your own servers.

And in case this wasn’t clear: that’s usually an advantage. No servers to buy, maintain, backup and upgrade.

Also remember that all email interaction with your customers passes through the big bad outside world.

And your own servers might not even be installed in your own data center, or you might be planning on migrating them ‘to the cloud’ in the future. And then what’s the point of being paranoid about an SAAS storing your data?

Reconsider having it custom developed

…depending on the situation of course. Usually easier said than done. Sometimes not.

If I hear about the total cost of some software, and then see what a jungle it is to navigate, and how few features are actually used, I often think it would cost a fraction to get it custom developed — usually not the whole offering, but just the features that are actually used.

There are exceptions, and there’s rarely a gray zone. Considering my background in software development, I might be biased.

Don’t blindly believe references

“XXX and YYY are using it too”

“If it’s good enough for ZZZ, surely it’s good enough for us”

You wouldn’t believe how often I’ve heard these as the decisive factor, when they’re far less relevant than the need for a user-friendly interface.

I think references are often used as shortcuts for proper due diligence.

References are a basic sales technique. References of well-known organizations are priceless. Keep in mind that these might have had a far better proposition than you, just to get them on board. I’ve done this myself. A product/service without references is so much harder to sell.

You can ask for an actual person to contact at these companies (not sure if this is common practice, but does that matter?). It’s usually the decision-maker though, or at least someone who will only say positive things. Someone who won’t tell you they made a bad decision, or just doesn’t know because they don’t use the software and no one dares to tell them it sucks.

Unless they’re really, really dissatisfied. I had this happen recently. My conclusion was that the vendor didn’t have any happy customers at that time and thus hoped that dropping the reference’s well-known name would suffice… that I wouldn’t actually contact them.

To get a more objective view: try to find someone unconnected at that company (check LinkedIn) and ask for their inside scoop. I have done this on occasion, and gotten valuable info (assuming my source was trustworthy).

Remember: Always take references with a grain of salt!