Identifying Personas for Enterprise Applications

Before we begin, here’s some food for thought from UX researchers as context –

“There’s a group of personas that I’m developing for an enterprise project. The problem stems from the fact that we’ve got distinct sets of users, and it is difficult to limit their numbers.

We’ve got 10 archetypes, with the confusing part being that these 10 personas use parts of the same interface, but perform different jobs and have different goals.”

Developing Personas for Systems with Expansive Functionality

As UX professionals, we’re well aware of the importance of obtaining a shared vision of the design objectives and constraints with all the stakeholders, including the users as well.

Among the many challenges of conducting research for enterprise software design is the sheer number of stakeholders involved, along with their conflicting agendas. This is where the complexity of first manifests itself in a tangible manner.

Here’s a list of stakeholders that can commonly be encountered in an average enterprise setting –

1. The individual users which include admin assistants, accountants, call center reps, sales executives, field agents, among others who are responsible for the input of transactions into the system. Usually, they have little to no say in the selection/building process of the software they’d be using, and have very limited means of reporting of any usability issues they might be facing.

2. Functional managers tasked with performing specialized functions. These would be sales managers, finance managers, customer support heads, etc. It is crucial to consider their goals which help in devising a confluence of their workflows to create unified outputs for the organization. Just as individual users, these managers also have limited avenues of communication to report or discuss product enhancements. Also, their product development expertise can be basic, which necessitates a learning curve. If so, they tend to have a limited perspective, which may result in overlooking user needs.

3. Enterprise executives are higher up the organizational hierarchy, these typically include the software purchase decision-makers. They wield significant influence on the purchase process, backed by inputs from CIOs or CTOs. The glitch? These executives hardly, if ever, happen to be the actual users of the system.

Acknowledging the “Wickedness” in Enterprise Software Design

Jeff Conklin wrote about advocating a design approach to solve wicked problems.

– They’re complex problems sans a clear definition agreed upon among the various stakeholders
– Lack of a binary-like state of success for any given point in time
– Are unique enough to be deemed unsolvable by commonly known methods
– Require experimentation on many dimensions in order to make progress

Quite like enterprise software to most UX professionals.

So, what can be done?

What needs to be done is acknowledging that designing usable enterprise software is different. That by simply testing representative individual personas on usability does NOT garner the desired outcome.

Dealing with wicked problems doesn’t mean that one needs to come up with the most appropriate answer. Instead, it’s centered on involving the stakeholders within the process of understanding the length and breadth of the problem(s) at hand.

As Jakob Nielsen mentioned in his Alertbox newsletter column, there are three dimensions to cover:

– Individual users
– Groups of users
– The enterprise

Standard lab testing misses group- and enterprise-level usability issues, as well as the impact of test data versus real data in these studies. UX professionals working on enterprise systems need to explore means to overcome these problems.

Building “personas with a purpose”

The biggest advantage of using personas while designing enterprise products is that personas are role-based. There are several roles and characters to find in the enterprise context which map pretty well to personas.

Owing to the breadth and depth of enterprise complexity, researchers are often bogged down by questions such as, ‘How many personas would make for a decent number? Do I need a small set that sort of broadly describes everything or is a larger number absolutely necessary?’

A two-tiered approach can be a good starting point. In this case, the upper-level personas can be used to map the company’s presence and objectives within the sector along with the major functional roles. The lower-tiered personas can be created based on each functional area.

Always begin by focusing on how the personas will be ultimately used – this is crucial to decide what goes into them.

Begin by defining the right goals

Conducting any kind of research exercise without specific, predetermined goals is a futile endeavor. Therefore, it is important to assign 3-4 important goals to each persona to be able to derive the right data. Remember to acknowledge the fine line separating goals from tasks – with tasks being the efforts taken to accomplish goals. Here are 2 types of goals that help in making focused design decisions –

1. Experience goals reveal how the persona wants to feel when using a product. Not feeling confused or irritated or feeling satisfied or confident are examples of experience goals.

2. End goals focus on what the persona attains by using the product. End goals are usually centered on the results that the user gains from using the product. For example, a bank executive wants to put his office application to use for giving his client the most optimum rate of interest on a mortgage.

Move on to the right kind of research

Personas that are created using ethnographic methods are based on the assumption that an interviewee’s attitudes and behaviors are so habitual as to be subconscious. Interviews, when combined with contextual observation yields accurate data in a short span.

It may take several hour-long interviews to get to the point where responses start becoming predictable, which indicates the formation of patterns.

Spot the behavioral patterns

With the user interviews behind you, it’s time to list out the behavioral variables. This refers to listing ways in which interviewee behavior differed. In most cases, these variables can be represented as ranges with two ends. In an enterprise context, there could be variables regarding the steps taken to fulfill a task, degree of emotions experienced while doing so, etc. You could also encounter demographic variables like age or technical skills that may impact user behavior. However, keep in mind that behavioral variables are far more important to the design outcome than the demographic ones.

The next step involves mapping the interviewee against the appropriate set of variables and determine where he/she each appear relative to the other interviewees –  a process referred to as affinity mapping.

Assemble your personas around need-based patterns

Use the collected data to add details to each discovered pattern. These details should describe the potential usage environment, a typical workday or relevant time period, current frustrations, relevant relationships, and goals. Adding too many personal details can be distracting, however, a characteristic or two can help bring your persona to life. You must ensure that each detail of the persona is based on real data gathered to ensure that the design decisions are based on facts and not fantasy.

Also, consider the role of the non-user

Enterprise products like CRMs or ERPs are designed to be used by the company’s employees to serve their customers (who may not be users or be limited users of that software). Thus, a peripheral, albeit important persona to satisfy is that of the limited user or non-user. This character may have limited involvement in the day-to-day functionality of the application, but it may be so that the entire application be based on serving his needs. As an instance to substantiate this point, we’d worked on creating an efficient EHR tool for physicians which helped in their interactions with patients.

It doesn’t end here

As with most enterprise projects, barriers keep appearing as the design process moves forward. In this case, your job does not cease with the creation of accurate and relevant personas. When presented to stakeholders, this research may elicit the much-dreaded ‘so what?’ kind of responses. The design research team may be asked questions regarding how these personas are relevant. Stakeholders could also be already aware of similar data from previous research sprints.

Personas without scenarios are like characters with no plot. — Kim Goodwin

Personas, when presented out of context, hold little to no relevance. This is where the significance of contextual presentation arises. Here are 3 ways to go about it –

Individual personas covering user goals and motivations can be presented using Scenarios.

Tasks covering the company’s expectations can be presented via Interaction Diagrams.

Roles covering system requirements can be presented through Service Blueprints.

Every tool in a UX researcher’s arsenal has a specific purpose. As UX researchers, we may come across situations when personas aren’t the best tool to use, and look for alternatives – we will be posting more on that front in the days to come. It is primarily important to hunt for focal points of value and pursue those. The best research outcomes are the ones that are actionable and set a definitive design direction.

“By solving our own most difficult problems, we’re potentially creating immense value for everyone else.” – Jason Amunwa, Director of Products at Digital Telepathy

More Resources:

6 Signs Your Enterprise Application Needs a UX Audit

4 Factors That Determine the Usability of Your Healthcare App

User Testing for Enterprise Systems