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.