How to Discover User Personas

In a recent blog, How to make IAM Projects Successful, it was suggested that identifying the type of users or user personas was imperative to give every identity project (and even any IT in general) the best chance of being successful.

However, what it didn’t do was to go into detail about how to find those personas. So is it one of those ideas that’s great in theory, but practically impossible, or is it one of those where you need to pay experts or consultants lots of money that may ultimately not bring any return.

Spoiler alert, the answer is no. The only skill that is required is inquisitiveness and the ability to focus on some details.

Firstly, a bit of background

Unified Modelling Language

Unified Modelling Language (UML was developed in the early 1990s as a modeling language that was intended to provide a standard way to visualise the design of a system. In the 1990s most companies had to develop their own software as there was very little off-the-shelf programs.

Many methodologies were about at the time, but the visual nature of UML made it stickier with developers than some of the others.

To say that most people have not heard of UML is true, but what is true is that most people have heard of Use Cases. Use Cases has become part of modern vernacular even to people not in IT. Use Cases were developed as part of UML.

Take a look at this image (this is actual UML), in most projects the focus will be on the box and the ovals inside the box. Technical terms for these are System Boundary and Use Case.

The box and oval represent the functionality of the system, in this case the IAM product.

The stick men, represent Actors. An actor is “a type of role played by an entity that interacts with the subject, but which is external to the subject.” Sounds complicated, but essentially, It’s a type of user or a non-human identity. In other words, a user persona.

Distinguishing Between User Personas

The diagram shows different stick people or different personas. It may seem obvious they are different from the context of the diagram, but what exactly differentiates between the different personas.

A persona is a collection of users that have a different attribute from other personas that will cause a different interaction or journey within the system.

Simply put, the idea is to find differences between groups of users that may cause something different to happen. What that difference is, does not matter. It’s the project itself that will decide if the difference matters.

The advice to any organisation is to find the personas generically, irrespective of the project.

Finding the personas with a project in mind can often skew the results and ultimately the requirements. This is because the functionality of an IAM project is often well known and being humans, (yes this is written by a human), we want to make life easy for ourselves and therefore will not necessarily take a step back to consider the fringe use cases.

For example, with MFA, an assumption is often made that everyone has access to a mobile phone and therefore everyone can use a phone-based authentication. Almost definitely there will be users who do not have or cannot use a mobile phone.

The Process

The process of finding the personas is a very simple one.

Firstly, find someone really annoying in your organisation. That someone who questions every decision, that person who examines every detail, you know the type. It doesn’t even have to be an IT person, just someone inquisitive.

Once the person has been assigned, draw up a list of questions to start with and to whom the questions should be asked. Arrange those meetings.

During the conversation, the idea is to find the different groups and the exceptions to the established groups. Simply make note of the groups and their attributes.

The process is iterative. Each meeting will likely throw up more questions than answers, with more type of users to consider. This is where the inquisitive person plays an important role. They should be looking and asking about users that might not belong. For example, “What’s the differences between our offices?”, “Do we have staff not in the HR system?”, “Do we have staff that don’t have a corporate laptop?” and “What about contractors?”

Initial Questions to Ask?

This does depend on the organisation, and there is no right or wrong answer to the initial list. The list of questions should be viewed as an ice breaker, a way to get the conversation flowing.

An example of good questions to start with

• What are the employment types? (e.g Full time, third party contractor, direct contractor, zero hours, maternity cover)
• What offices do we have and what are the differences between those offices?
• What are the working hours for staff?
• What geographic countries are staff in?
• What equipment do people use (e.g Corporate laptop, corporate phone, personal computer, personal phone, windows, linux, mac)
• Are all staff in the HR system?
• What privilege users do we have?
• How do we manage third party suppliers?
• Who are the high value users? (e.g Owners, Directors, Board)
• Do we have users with access to sensitive data?
• Users with different physical and neurological needs?
• Are there group of users that need to adhere to any regulations (e.g PCI, GDPR, ISO)?

As you can see, the list is wide-ranging and may appear somewhat random. Some may question what have some of these go to do with Identity. The point is that from these questions a many groups will be formed, but equally there will be many more that need to be discussed. The discovery questions for the additional groups can be added to this list to make it more meaningful for your organisation.

As to the question of are these relevant, the answer is an unwavering yes. Each one of these questions will discover different personas that will impact any IAM Project. (More on this later).

How Many Personas are there in an average organisation?

There is no real answer to this, as it does depend on so many factors. Examining the starting list of questions, there are a lot of possible combinations.

As a rough guide, an average organisation will have around 70 to 100 personas. Industries such as health-care, education and retail can be greater than this.

The number is not important it’s the quality of the differences identified that will make the this and subsequent projects successful.

Are different job roles different personas?

The identity industry for a long time has talked about Role Based Access Control (RBAC), and so the temptation can be to think that every job role is a different persona.

Personas tend to lean towards an Attribute Based Access Control (ABAC) methodology, as the personas are about listing users with different attributes. Job Role is obviously a different attribute and perhaps therefore can be considered a persona. Whilst this is true, when one examines the roles closely there may not be many differences between them and any differences may be because of other attributes such as office location.

One of the downsides of focusing on job role is that the number of personas can grow very quickly especially in large organisations, which can lead to a lot of noise and some important details can be missed.

The advice is to consider job roles after a few iterations of the discovery process. The early phases will naturally call out some important roles that need consideration (such as privilege and high-value users). This will help keep the number of personas down, but also help identify if job role really makes a difference. From experience, it is likely that other factors will play a bigger part.

Can a user belong to more than one persona?

This is more of a theoretical question and many people will have different ideas.

There is no reason why not and will certainly keep the number of personas down. However, the only caveat to this is that there may be a situation where a group with a combination of personas require special consideration.

The advice is if you are not considering the persona combinations at the discovery phase then it is imperative that is during the requirements and design phase of a project.

How to record Personas

Despite the graphical origins of Actors in UML, the best method is to create a list of the different personas with a brief description as to what causes the persona to be different.

For example,

New York Office Users

New York office users require an ACME key card to enter the building. 

New York office has a data centre and is open 24 hours per day, seven days per week.

London, Paris and Frankfurt Offices

Users use a keypad to enter the building.

Offices are open Monday to Friday 8am to 6pm. Permission has to be sought to be in office after those hours.

How to Use Personas

Once the list of personas has been obtained it is then a matter of using them during the requirements and design phases of a project.

Most of the personas will not influence the project over and above standard functionality. Reading through the list of personas should force some decision on whether, how and even if, to handle those types of users. What it will do though, is force every user and use cases to be considered.

Consider the office personas listed above and for an Access Management project

• ACME key card – can it be used for MFA?
• Data Centre – unlikely mobile phone can be used in the data centre itself.
• Remote Access to Data Centre – should be to New York employees only. Need to setup special authorisation process to allow non-New York staff access.
• London, Paris and Frankfurt offices – Conditional access policy can be applied to limit access during working hours

Very simplistic considerations yes, but already it’s possible to show how personas can drive requirements and design in a project. Without it would Data Centre users be forced to use a phone-based authentication which goes against company policy of not using phones in a data centre? Would security be less secure without a conditional access policy to control access in other offices?

Summary

In a recent blog, How to make IAM Projects Successful, it was suggested that identifying the type of users or user personas was imperative to give every identity project (and even any IT in general) the best chance of being successful.

Identifying user personas is a simple iterative process in which questions are asked to find differences between groups of users that may cause a different user experience or cause special handling. What that difference is, does not matter and is the importance is only decided upon once applied to a project.

The process is started by identifying someone annoying who can ask a lot of questions and spot potential differences. An initial set of 10 or so questions is all that is needed to kick start the process. The process itself will drive conversation and more personas will be identified as time goes by.

There is no such thing as an average number of personas for an organisation, and many factors such as organisational structure, age of company, geographic locations and even type of industry can be a big factor. A good number to expect is around 50 to 70. The number is not important it’s the quality of the differences identified that will make the this and subsequent projects successful.

Recording the personas is a matter of recording the differences between the various groups and can easily be done in a short document. Applying the personas to a project is a case of reading through the list of personas and deciding what effect they will have.

Using personas will lead to a project design that has considered all the users and their use cases for a project and ultimately it will give a greater chance of success.

Disclaimer

The author can draw match-stick men as good as any AI, but apart from that is no match.