In my last post, I listed four reasons why enterprise software is so bad.
- The software is made for the “choosers”, not the “users”.
- There are a lot of different users, creating inherent complexity in the workflows.
- From the vendor’s perspective, the entire system is highly customized for each client so there is little incentive to make it perfect since it will all be changed anyway.
- Getting information from customers about what they need is really hard.
I talked about the first two reasons in my last post. In this article, I will talk about the last two reasons.
From the vendor’s perspective, the entire system is highly customized for each client so there is little incentive to make it perfect since it will all be changed anyway.
Let’s take an example. Say you are a software vendor selling payroll systems for large companies. Every payroll system has some basic similarities.
- You have employees with employee numbers.
- You have money in a bank account.
- At regular intervals, you pay them (we hope)
BUT. And this is BIG BUT. every company has important differences, and in large companies, these differences are a really big deal. For example, you might have to support things like:
- Some employees are on salary, some on commission, some on hourly rate, some through a third party contractor (by they way, can you integrate with that 3rd party system?) You need to be able to handle all of them.
- When hourly paid employees submit their hours by “end of day” Friday, how do you define “end of day” when your employees span pretty much every global time zone?
- Can you make the payroll system in five different languages please?
- What is the escalation protocol when a manager does not approve the submitted hours?
- Company X was acquired 3 months ago and you need to integrate with the old SAP system that they are still using.
- Every week the company has roughly 500 people leaving or starting. Some of them might be in roles that require them to approve other employee timesheets. You need to take that into consideration.
- Can you make it comply with our internal corporate branding?
You get the idea. Every company will have some combination of these issues, but no two companies will have the same combination.
So this is what a vendor typically does.
They sell a payroll system “template” with the understanding that the customer will change it. They will add some features, they will remove others, they will remove the vendor branding and look-and-feel and apply their own federal government style-guides and so on. They will poke it and prod it into submission to make it their own.
As a result, there is an inherent disincentive for the vendor to spend a lot of time on fine-tuning the user experience since it is going to be changed anyways. Furthermore, the system is often so brittle in the fundamental sense of “you can’t get that data from here to there” which means that some workflows that are essential from the user’s perspective are just impossible to do. Well, probably not impossible, just really expensive, which amounts to the same thing at the end of the day.
Unless you have an actual sale commitment, it is really really hard to talk to users to find out what they need.
I’m a user researcher. Talking to users is what I do. Yet, in the enterprise context, trying to talk to users is a road littered with more obstacles and false starts than a an episode of the Amazing Race.
For starters, a potential customer will not usually let you in their doors unless you already have some kind of relationship with them, but it is hard to have a relationship with them unless you already have a product that they might want.
Getting the right kinds of users is problematic as well. With consumer software, you can generally hold focus groups or in depth interviews with interested users, and offer compensation for their time. It is relatively easy to find people who want to buy shoes online, or who share photos with their friends and family, especially, if you offer them $50 for their time.
However, with enterprise systems, it can be challenging to put together a focus group of payroll managers, or CFOs. Not only are there fewer of those people around, you generally cannot offer compensation for participant’s time because that would create an ethical conflict if they end up purchasing a product from you (most companies, and especially the government, have strict rules about accepting gifts from vendors).
So typically, this means that you are talking to customers in a few different contexts, which are quite different from the standard UX practice of user interviews.
- A sales call. If you have managed to build a good relationship with an enterprise sales person, they may permit you to come with them on a sales call. In these situations however, you are usually meeting the “choosers”, not the “users” (see last post). And you have to walk a delicate line between sounding like an expert (so that they will buy from you), and learning what you need to know.
- An actual customer who just bought the product. In this scenario, the customer is willing to let you come in and talk to a whole bunch of employees so that your product can be customized for them. This is great, and most like the standard kinds of UX investigation techniques you read about in books. You can usually get to talk to real users in this situation, maybe even watch them use the software. On the down side, it doesn’t give you any insight into how things might work for OTHER customers, who will require other kinds of customization. If you follow this one customer too tightly, you risk creating a very brittle system.
- A customer service call. This tends to give you information about people who are having trouble installing the product or some basic interactions, but it rarely gives you insight into their tasks and overall workflows.