18 Jan

5 reasons to not use personas for Enterprise software (and what to do instead)


Let me tell you a little secret.  Are you leaning in?  Ready?

OK, here goes:

“Enterprise software is not really made for the users.”

In fact, you may notice that it is called “Enterprise Software” and not “Consumer software”.  This is because the software is created for the primary benefit of the enterprise.  This results in several challenges for the UX practitioner.  One issue that first struck me when I first started working in enterprise software was how to handle personas.

It turns out that, while rigorous, data driven personas are a great design tool in many circumstances, particularly with consumer software, they are usually not the right choice in enterprise contexts.   Here is why:

1) Enterprise software has too many users

Enterprise software usually has many people along a workflow chain.  For example, an expense reporting system may have to serve:

  • the people submitting the expenses (frequent travelers, as well as the occasional submitter)
  •  the managers approving the expenses
  • the department head reviewing how their department is spending money
  • an administrator who defines the expense approval policies
  • business analyst who is analyzing the expenditures and looking for efficiencies.

If you were to do a proper persona project, you would talk to 6-8 people from each of those roles.  So for the system above, that would require 30-40 participants.  By the time you are done with that, the next release is already on the way, your company strategy has changed, and your group has been “re-orged” to a different department.

2) Large enterprises won’t let you talk to their employees

If you are selling software to large companies, you can rarely get inside the company to talk to the target users unless they are already a customer.  But they won’t be a customer unless you already have a product.  This creates a classic chicken and egg problem.  Sometimes you are lucky with amazing sales people who can get you infront of customers at the early stage, but that changes the dynamic of the conversation.  It is then a sales call, where you’re supposed to sound like the expert, not a research call where you sometimes need to feign ignorance in order to extract the information you need.

That means you usually resort to recruiting a few people from a variety of different organizations, which gives you an incomplete, fragmented picture

Furthermore, you are usually not allowed to pay participants incentives for research because of ethical restrictions on accepting gifts from vendors.  That means you can only talk to people if their manager OKs it – i.e. makes them do it.

If you manage to get into an organization to interview users, you are likely speaking with the “choosers” (the executive making the decisions) not the “users” (the people subjected to the software).  Often, the choosers don’t even personally know the users and you have to go down several levels in hierarchy and across departments to get in touch with them.

3) User roles can be highly specialized and difficult to recruit

Usually, the people that have the most influence over purchasing decisions are the most difficult to recruit.  Ever try recruiting CMOs of fortune 500 companies?  I have, and it’s a tough gig.  Not impossible, but very tough.

Some roles are just plain obscure and difficult to find.  Need someone to talk to you about buying music online?  Easy.  Need someone who reviews the legal text that goes on bank brochures?  Not easy.

4) Enterprise software is highly customized

If you are a vendor creating an expense reporting system, it is certain that whatever solution you build will be significantly customized by each of your customers.  Each company will have highly specific differences which significantly impact the user experience such as:

  • What happens when an expense is rejected and the employee wants to escalate the issue?
  • what happens if the approver is away on holiday?  who is allowed to define the new approver?
  • If they have international locations (which they always do), how are the different currencies and policies integrated?
  • How often do the policies regarding expenses change?  Who makes these changes and who has to approve them? How technical are they?
  • the market vertical.  Government verticals might have strict rules about public transparency for example, while the financial sector might have strict rules about security.


 5) You still end up with questionable value

Let’s say you and your crack team are extremely resourceful and efficient and managed to overcome all these barriers.  You can still end up with results that, while still useful, have limited value in practice, mostly because of the customization issue.  With all your fine research, you will still end up with customers that do things differently, which you will have to address if you want to win that meaty contract.  The value that you get from it won’t justify the effort you put in.

What to do instead

Don’t worry, all is not lost!  There are still ways to bring user centered approaches to the design of enterprise software.  I wrote a more detailed piece about this in UXBooth but in a nutshell:

  • Focus your energies on scenarios rather than personas.  They give you more bang for the buck than personas because they focus on the end-to-end experiences.  The user experience of enterprise systems often fails in between the cracks of organizational silos.  Scenarios help with that.
  • Use “user profiles” instead.  These would consist of roles and responsibilities that can find from job postings and other secondary research which is much less time consuming than a traditional interview-based persona project
  • If possible, talk to 1-2 people from each role to get some nuanced understanding and to get a sense of which types of things tend to vary from one customer to another.
  • To make sure you don’t paint yourself into a corner make a table of reach role and things that are likely to vary from organization to organization.  That way you can ensure that you build in the right kind of flexibility.


03 Jan

Why does enterprise software suck? (part two)

In my last post, I listed four reasons why enterprise software is so bad.

  1. The software is made for the “choosers”, not the “users”.
  2. There are a lot of different users, creating inherent complexity in the workflows.
  3. 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.
  4. 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.

  1. 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.
  2. 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.
  3. 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.
I listed only four reasons that enterprise software struggles to provide a good user experience but that only scratches the surface.  There are many more reasons. I could probably dedicate this entire blog to the problems.  Sometimes I marvel at the fact that enterprise software works at all, given the challenges they face.  In my view, the fact that it does speaks to the intelligence and dedication of the teams working on it in their suburban cubicles late into the night.